I was reading Mike Rothman’s warning about the dangerousness of TinyURL, the famous URL shortener. Mike’s right of course. Someone could easily disguise a malicious URL and get you to click on a link that you wouldn’t have otherwise because it would have looked obviously like an XSS attempt by nature of the visible HTML tags. If you did click on the link you’d be redirected (301) to the malicious XSS URL and your sessions cookies to just about any website would have gone bye-bye or worse.
What I think we’re all missing though is that by just deciding not to use TinyURL we’re really not solving the client-side (browser) problem. What about the many other identical services like doiop, notlong, and shorturl? We can’t possibly memorize the names of all of them and remember to not click on their links. The point is if someone really wanted to get you to click on a malicious XSS link they will, no doubt. All they’d have to do is disguise and redirect it off any ol’ unrecognizable domain they control and you’d never get a chance to spot the XSS payload before hand.
So, here’s my feature request for the browser vendors that I don’t expect to be implemented until n + 1 versions from now. n being the version currently in beta. So that roughly means Firefox 4 or Internet Explorer 9. The URL from any 3XX redirect should not be allowed to contain <> characters. Or perhaps something less restrictive, say maybe no HTML tags allowed. Would that break anything? Sure, its not a perfect solution, but we have NOTHING now. Anyone want to try this out first by making a browser add-on?
Well, there are some very cool services, such as..
www.x.se since you can have..
anyway, Mario Heiderich has h4k.in :P
Jeremiah, you really don't know NoScript?!
It does exactly what you suggested (sanitizing cross-site requests, redirects included) and much more...
Seconded -- noscript rocks.
That said, trying to do universal xss protection on redirects is hard, right? DOM injection requires no html, nor do attacks based on vulns like those introduced by using unsanitized PHP_SELF in urls. I suppose simply stripping < > would help some, but in the end it leaves too many vectors open, and might impact legitimate sites too.
The browser vendors could also offer an option to prompt on HTTP redirect, or prompt on HTTP redirect just for certain sites.
Isn't "trying to remove hostile characters from a string" one of our industry's classic persistent problems?
I still remember Hotmail's problems with trying to block the string "[script]" from being sent in an email, and how it took them forever plus a day to finally get it right.
(Oh, the irony! Blogger doesn't let me put <> tags around the "script" word above.)
Oh, as for tinyurl.com, you can set it up to always show you a preview of the URL you're heading to.
@giorgio, of course I know what NoScript is, I have it installed. However to expand on what Jordan said, some amount of NoScript functionality should also come by default in the web browser. Because if it does not, users are left unprotected, which is why I called for a browser feature.
@jordan, it would most likely leave a certain amount of vectors open. That I'm cool with as long as it takes out a lot of the existing ones without severely impacting the user experience. That part will have to be tested.
@dan. Your exactly right, its a lot like that, my point though is... what choice do we have? Something or nothing?
*) It's hard to get masses to switch from browser known for being swiss cheese, so expecting any noticeable number of people to use NoScript is just madness. It's nice and all, but if you plan anything internet-wide you should pretend it doesn't exist.
I may have a job opportunity for you based in NYC for a company in Europe/Paris seeking to launch in USA market. You seem capable.
Please contact me 646-307-8909 NYC
my email firstname.lastname@example.org
For me personally? You can't be serious.
Post a Comment