“You can’t compromise an application using XSS”

Before I open up this can of worms, I can tell you that both vendor and client have told me this.  I then try to explain to them how things are generally interwoven and connected to each other and how you CAN own an application through XSS if done in a correct manner.

With XSS, you usually end up owning the USER of the application and thus can build up on your attack.

“You cannot alter any data using XSS”

With a reflected XSS attack, yes, you cannot change any stored data on an application.  You can, however, change the User Interface significantly.  You can swap out an entire page using a reflected XSS attack to make a user think he is on another screen of the application.  Like the login page for example or injecting an iframe.  The only catch is that you have crafted this login page using HTML and JavaScript and have presented it to him as if it were part of the legitimate site.  The login form sends his password to a server you control, but nothing is altered on the application database to begin with.

In the above examples and all cases of XSS, one thing is common.  The scope of this vulnerability is confined to that of the application user.  You do not use XSS to attack the application directly.  You use it to attack the user and indirectly attack the application.  So an XSS is more comparable to a pseudo social-engineering attack where you are tricking the user into revealing his credentials (enter his password on a crafted password screen or stealing his cookie).

The easiest way I find to present an XSS vulnerability, even before I put it in a report, is to call all the project stakeholders into a room and demo it to them.  I tell them that I have some findings to share with them and would like a few minutes to show them a live demo.  I then load up the application page that they are all familiar with.  Open up my email client to a received message[1], click on the XSS laden link[2] and show them a perfectly legitimate login screen of their application.  I log in using credentials I was given and then continue to access one of the application’s functions as normal.

After a few seconds, I stop and tell them that I was just a victim of an XSS attack.  Then I move into the technical details.  I find this approach to be quite effective[3].  It raises awareness in a way that the client can relate to.  What they perceive to be a legitimate session turns out to be an attacker controlled phishing attack of sorts.

[1] I create this message and send it to myself to simulate a company employee receiving an email from another person.

[2] I sometimes obfuscate the link, but usually I use HTML mail to show them an underlined “Click Here” phrase when the actual link is a stager.  I send an include (hex encoded <script src> tag) to a remote JavaScript file that contains the code to render the fake login page.

[3] My setup includes a remote site under my control where I host the malicious, custom written JavaScript files.  I have a backend script to pick up the posted information and send me a neat little email containing the cookie (if any), username and password and some other relevant data.  If one of the executives has a connected laptop, I will invite him to try it himself.  In the early days, I would send the link out to all the application users first by spoofing an internal email.  Then, I’d compile a list of the users affected and share the information with the executives in the meeting.

I’ve had more positive responses using this approach than trying to put it in the report only to have several opinions thrown back from the client and the vendor that show a lack of knowledge on the subject.

XSS attacks are very common and can be used to great effect.  I am not alone when I say that XSS is very badly misunderstood and the threat that it poses is often ignored.  I think a hands-on approach of this nature, even though it takes more time and effort, is worthwhile in spreading the word.  Sometimes, you just have to spend the effort to demo your vulnerabilities to put things into context.  Your clients will appreciate it and remember it more than just reading a report.