stop the alert(); - The HP Security Laboratory Blog -
The HP Security Laboratory Blog » stop the alert();
stop the alert();

For nearly a decade, those of us in web security have been doing a disservice to ourselves and, more importantly, our customers. Like Pavlov, we've trained people to respond to certain stimuli. Rather than a bell, we've relied heavily on the alert() dialog box to prove our point--that cross-site scripting is possible.

And why shouldn't we (assuming we're not doing hardcore pentesting where we really need to abuse it)? It's easy to exploit, it's easy to explain, and most importantly: it's in your face.

I'm not saying everyone does it but... everyone does it. We've all proven our point, at one time or another, to a skeptical business person or developer by sending the trivial-but-hard-to-ignore link containing a <script>alert('Vulnerable+to+XSS' )</script> variant. Don't deny it, you know you have.

So what's the end result of all this alert() training? "There was no popup, therefore it's a false positive."  I have heard this more times than I want to admit. When I hear this, I have to sit back and wonder where we went wrong. When did that (business security consultant|developer|manager) become a dog salivating for another alert? When did I let it happen?

At this point you of course have to prove it's somehow dangerous, which means taking time to make the alert work or some sexier attack. Did the developers clobber alert() for some reason (Facebook), or does it need a simple tweak? Who knows... the point is, it takes time. The guy that can fix it didn't just look the source and say "oh crap, the kitchen sink is making it through unfiltered" simply because he didn't get smacked in the face with an alert box.

So what do we do? Well, there's no going back in time... but consider using other examples when you can. Liberal use of the <blink> and <marquee> tags with a "business has closed due to pending litigation" message or a redirect to a competitor's website will often do just as well. Or maybe someone should make an injectable version of jsAscii that replaces all the images on a page (that would be pretty sweet).

So stop demonstrating XSS with alerts and stop being lazy. Mix it up a little and give some different examples--in the end it will make all of our lives easier, our sites more secure, and just may stop that infamous developer who thinks the fix is to filter out the word 'alert'...

Posted 08-31-2009 1:13 PM by Chris Sullo
Filed under: ,

Comments

Gilzow wrote re: stop the alert();
on 08-31-2009 5:34 PM

This is why I usually follow-up the alert with a complete site defacement, or if I'm in a good mood, adding a little rick-roll to their page.  After seeing their page compltely altered, they start to get the point.

Steve Lord wrote re: stop the alert();
on 08-31-2009 9:34 PM

I've been there all too many times. It's quite a leap of faith for some to view the issue (input validation) instead of the symptom (XSS, SQL Injection etc.) which is why I don't do alert boxes for the client anymore, especially considering how easy it is to use something like beef or metasploit's browser_autopwn.

Chris Sullo wrote re: stop the alert();
on 09-01-2009 1:30 AM

Thanks Steve... now we just need more people to do the same :)

Acidus wrote re: stop the alert();
on 09-01-2009 4:24 PM

I adopted some JavaScript code from Usaproxy, a cool 2006 paper on automated usability testing. Got to love papers entitled "Knowing the user's every move." It uses JavaScript to track everything, from keys to mouse movement to focus events and resizes.

fnuked.de/.../www2006-knowing-the-users-every-move--user-activity-tracking-for-website-usability-evaluation-and-implicit-interaction.pdf

jcran wrote re: stop the alert();
on 09-03-2009 3:13 AM

www.bindshell.net/.../beef so you send a link, and scan the internal network. then redirect to a malware pack. win.

Jim Manico wrote re: stop the alert();
on 09-03-2009 3:50 AM

Saying that XSS is an input validation issue, Mr Lord, is a dangerous falsehood that we should stop spreading. Application Security injection attacks like XSS are solved via syntactical encoding at the data use boundary. In the case of XSS, it's all about OUTPUT encoding in the proper HTML content. Please review http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet as a great explanation of this topic, in depth.

Phentoplocker wrote re: stop the alert();
on 09-08-2009 3:10 PM

Totally agree,

I recently discovered "alert" in the anti xss reg ex validator for a popular “commerce” package(for large companies) from a 3 lettered company which beginning with &#73 and ending with &#77.

Then vendor had no shame, when confronted, they removed the smoke and mirrors but it was obvious this was pure security theater attempting to pass covertly for a security control.

Having the security assessment tools continue trusting on seeing "alert" when facts are in hand that vendors are blowing  smoke up our “patukas”  by filtering for &#65&#76&#69&#82&#84 is fool hardy.

Strongly recommend rules be created to check for XSS without using “ALERT”. Alert was ok before the vendors started having the guile to filter alert out.

Chris Sullo wrote re: stop the alert();
on 09-17-2009 12:22 PM

My colleague Matt Wood suggests injecting Yahoo's pirate converter... which I think is a great idea, matey.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

Type the numbers and letters above:
Privacy Statement
Powered by Community Server (Non-Commercial Edition), by Telligent Systems