Carter Cole LinkedInCarters Twitter PageCarter Cole on Facebook Carter Coles RSS

Wednesday, January 20, 2010

The persistent XSS hole I found in

I like to dabble in security... xss holes are fast and easy. The first one i ever found was on the online editor Aviary when i was a beta tester... it was a small one. They had scrubbed html in every field (.net had done it for them) but they had forgotten to sanitize the input from the filename in their flash app and i got my tags in! woohoo XSS holes. I happen to be checking my Wells Fargo account and you can nickname your accounts... and i thought to my self. self i wonder if i could put some html in my account nickname and have it render... lets try it :)


We got tags

but i was dealing with a character limit... a common problem with cross site scripting attacks but no matter i decided to try for the long shot... i used chrome to change the max length of the text field to something i could really put some code in fully not expecting it to work and then boom i got an entire script tag with a javascript alert... and its persistent!

how i changed the max length of the text field:

the next morning i tried to find the correct people to call and got to the phishing department but not the real web guys... then i was really impressed... i got a call from their online fraud department they had detected that html was being posted from my account and I quickly offered up that it was me who was inserting the HTML and told them about the hole (this was months ago and im sure they fixed the hole by now so i dont think im hurting anything by posting this im sure i will know if they think otherwise) but anyways the cool part is that even though they weren't aware of the hole their system detected the XSS anyways... way cool and props to you security guys at wells fargo! i was asked not to try and attack the account portal anymore (so i wouldn't set off alarms again) and was thanked for letting them know about the hole... it was a small one but some javascript left by an attacker to send balance to remote server and then steal cookies (im sure stealing cookies wouldn't work but for the sake of this argument) if there was a large enough balance alert the attackers. also because it is a persistent attack and html doesn't render on the screen the script could sit there for a long time without the user ever knowing

so how do you protect the applications you write from XSS attacks? the answer is simple... its the same as protecting against SQL injection... sanitize all user input before anything is written to the screen. Strip html with regular expressions is always a good start and for god sakes please force character limits at the server side and dont expect the HTML maxlength="20" to do your job for you

below is my javascript alert with the cross site scripting hole in those guys do a great job and ive been a customer for like 7 years. Wells Fargo is awesome and i hope they dont make me take this down because it is a great example of this attack and they did catch it so there really wasn't that bad of a security problem...

id love to hear your questions / comments / concerns about this article, bother me on twitter im @cartercole and i love to answer any of your questions...

0 remarks:

Post a Comment

Link to this post if you found it usefull

The persistent XSS hole I found in