<a>elements inline for link creation. Sounds pretty benign, doesn't it? Not so fast: Whereas HTML alternatives like BBCode don't allow inline event handling (e.g "onload" attribute), the raw HTML code that's being permitted here does.
What does this allow? Take a look at the below example:
<a href="http://example.com/" onload="while(true) { var w = window.open(); w.document.write(document.documentElement.outerHTML||document.documentElement.innerHTML); }">Lorem ipsum dolor sit amet</a>
By manipulating the onload attribute, it's possible to do all kinds of crazy stuff: everything from injecting script elements into the DOM at runtime (
onload="document.createElement('script'); ...") to actually assisting the spread of native-coded malware (embed element injection, iFrame injection), all while passing itself along on the server side as a rather harmless onload event to an anchor element.
In the above case, we have one of the most profound examples of a script-based denial of service attack: a fork bomb, only one that will actually fork the entire page it's injected into, not just itself.
For those of you who are familiar with UNIX-like operating systems (such as Linux), you may already know just how many processes a fork bomb can create at once, filling up your RAM, hogging your CPU, and quickly causing your computer to freeze. For those of you who aren't, one needs to look nowhere else than the ever-increasing number of browser windows/tabs that the above example creates on the client side to know just what kind of a denial of service attack this is.
So, next time one tries to think about using a loose security policy like this instead of, at the very least, blacklisting inline events in comment elements, you might want to think that through a little bit more. Because as we all know, the consequences of loose security morals can be VERY severe, and it can hide inside some of the subtlest of places.
