That appears to be a legitimate bug, but thankfully a special-case bug in the standard tag library and not something general in the core parsing engine. The [img] tag's code correctly identifies that <a href=...>...</a> is not a valid image URL and correctly rejects it, but the tag forgets to safely-encode the rejected text. That's a simple omission, a one-line fix in the code, and I have already fixed the bug in the trunk in SVN and I will issue a security release (v1.4.2) within the hour that contains both the fix and suitable regression tests.
Congrats: You found the first legitimate security hole in NBBC, which is pretty good considering it's been out for eight months now.
That said, I wouldn't call this a *huge* hole; a huge hole would be, say, forgetting encoding everywhere in the library, or allowing PHP code injections. Whereas this is a one-line fix to code that was misbehaving in a special circumstance, and even unpatched, it (thankfully) wouldn't compromise the integrity of the server. It *would* allow for XSS attacks on things where end-users could post content for other end-users, so it's good to patch it, but an XSS injection and, say, an SQL injection are not really in the same category, y'know?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad I could help :) Thanks for putting out a fix so fast - I just checked back here today and saw the update because one of my users put an invalid image link and inadvertently caused the problem. Cheers, & love this library!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.. It seems to be possible to inject script in [img] tags. For example:
[img]<a href='#' onclick='alert("injection")'>click me</a>[/img]
Seems like a big hole?
That appears to be a legitimate bug, but thankfully a special-case bug in the standard tag library and not something general in the core parsing engine. The [img] tag's code correctly identifies that <a href=...>...</a> is not a valid image URL and correctly rejects it, but the tag forgets to safely-encode the rejected text. That's a simple omission, a one-line fix in the code, and I have already fixed the bug in the trunk in SVN and I will issue a security release (v1.4.2) within the hour that contains both the fix and suitable regression tests.
Congrats: You found the first legitimate security hole in NBBC, which is pretty good considering it's been out for eight months now.
That said, I wouldn't call this a *huge* hole; a huge hole would be, say, forgetting encoding everywhere in the library, or allowing PHP code injections. Whereas this is a one-line fix to code that was misbehaving in a special circumstance, and even unpatched, it (thankfully) wouldn't compromise the integrity of the server. It *would* allow for XSS attacks on things where end-users could post content for other end-users, so it's good to patch it, but an XSS injection and, say, an SQL injection are not really in the same category, y'know?
This bug is now fixed. Please download the latest version (v1.4.2).
Glad I could help :) Thanks for putting out a fix so fast - I just checked back here today and saw the update because one of my users put an invalid image link and inadvertently caused the problem. Cheers, & love this library!