Note I said whitelist m8, that's to avoid any of the headaches you bring up ;) Only idiotic devs go with blacklists, because there's just an incredible amount of stuff you'd need to keep out... compared to the relatively small number you'd want to allow in.
You don't need to care or even know about all the malicious tags if you only go about whitelisting the ones you know are safe. For example, if you only want to allow stylistic tags like <strong> or <em> or <i>, you just whitelist those and scrape out any attributes (like onhover, and everything else you mention). MAGIC, completely secure without even giving a sh*t about h4x0r methods. Everything else would either be removed or escaped (perhaps with an additional system to notify staff when an attempt is made at using malicious tags).
That's essentially what a bbcode system does, it gives you a set of whitelisted HTML tags which are (usually) properly secured against user input. The only thing is my system removes the work of building and maintaining a middle man, as well as the resources used by a bbcode compiling system (however neglible it may be).
As for CSRF/XSS, that's the concern of your site's form input validation, not description stylings, regardless of whether you use raw HTML or a bbcode intermediary. You should definitely implement some nice regex to ensure things like image sources actually look like image sources, but at the end of the day if your page is insecure, anyone can setup a fake image-like link that redirects the browser to the insecure page. For example, both tbdev/torrentstrike have a hilarious little "bug" you might like. A person can setup a fake avatar.png file, which redirects the viewer to tracker.com/logout.php, so the viewer logs out every time they see the avatar
There are other more serious ones, but that's the only one I dare make public :P All are shit security on the developers part, none of which is involved in their html/bbcode jazz.
tl;dr: everything you mentioned is null and void, completely invalid based on what my suggestion actually was. I told the user what they need to do, but I don't know what their codebase is, or even what language their site is based on, so there's not much else I can do.
Also, I'd like to smack your face for considering cookie forgery, almost all modern browsers are completely secure against any cookie theft method (short of actually hacking into the browser, at which point any of your site-sec is useless anyway). Cookies are locked to domains, so unless the idiot is handing out cookies that work on a wide range of domains (ie *.randomfreehost.com), there is no theft. Of course, most tracker coders do seem to be idiots...
