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'...

Comments
| ‎08-31-2009 06: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.

| ‎08-31-2009 10: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 | ‎09-01-2009 02:30 AM

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

| ‎09-01-2009 05: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-eva...

| ‎09-03-2009 04:13 AM

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

| ‎09-03-2009 04: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 | ‎09-08-2009 04: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 | ‎09-17-2009 01:22 PM

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


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.