Following on from Anatomy of XSS (Yes I know it’s been a while!) It needs to be discussed as to what can be done once a vulnerability like this is found. This entry will discuss the evil-doers side of progress. Prevention and damage control will come later… Eventually.
So you’ve found your first XSS vulnerability then?
What happens next?
This is always going to be a touchy subject but generally what I have always done is try and get in touch with the company’s security / information / technical contact. Now; take this with a pinch of salt since most people don’t like being told that their customers could be at risk and you have just found a Point-of-Entry for attacking their customers. All eyes will fall upon you when something does happen!
(I must add that you can do more good with security code-reviews of open source projects but that’s something else entirely!)
Which is why I say I ‘generally’ use this approach! You have to see it from their point of view, many believe that keeping these things secret and not fixing them is the right way forward. These are the types that like to get lawyers involved - just steer clear entirely.
Basically some appreciate it and some really don’t, working out who is usually pretty clear.
####Disclaimer I’m not telling anyone to test XSS vulnerabilities on live sites. In fact I would totally recommend setting up XAMPP and testing it on a local site. You’ll learn so much more anyway!
From this point onwards we shall assume you’re testing on a website that you own or one that is running on your local machine (Google: XAMPP)
So you want to get something more than just an alert box? But first! A quick note on sessions!
A session is a can be described as a way of uniquely identifying a user during the course of their visit to the website in question. Since HTTP is a stateless protocol (Websites can’t tell who you are without some help - they are very forgetful), users need to be tracked using a session ID so that their content e.g. Shopping basket items, user login, etc. remain theirs.
Lets borrow someone else’s session: first we choose our attack vector.
Stored XSS: Target every legit user visiting that page(s)
Reflected XSS: Target a particular user, by asking that user to visit your special URL that you’ve created.
will give you the details of any any cookies already set.
Look at some cookies already set in Opera by opening up DragonFly (Right Click a site -> Inspect Element -> Console Tab) and writing
This information can be copied out of the browser and manually set in another, logging in as you without having to know a password. Sometimes known as sidejacking. Magic stuff.
Now you’ve got to start thinking about how to get that information to a different location…