In our previous article we covered the basics of cross-site scripting (XSS). In this post we are going to take a deeper dive into this vulnerability and investigate some of the more malicious payloads that could be used by an attacker. The common alert box which is typically used as a proof of concept does not do the severity of this vulnerability justice, as demonstrated with the below payloads.
Examples that are demonstrated in this post were performed on OWASP Broken Web Application Project, which provides a great playground to explore web vulnerabilities of all levels.
This can be achieved through multiple different methods. One way would be if credentials were cached in the browser.
Imagine you have logged into a site, clicked the ‘yes’ prompt out of habit to save your credentials and for ease of use later on. Let’s say this site also contained a reviews section, like the one below:
An attacker could use a payload like the one shown below to steal cached credentials:
As this was used in a stored XSS context, the credentials are automatically sent to the attacker upon the page being browsed to. Checking the logs on our attacking machine, we can see the user’s username and password!
The previously stated payload to capture cached credentials can also act as a username / password field. If a user were to fall prey to this and enter their credentials in the fields, the credentials would be sent to the attacker the same as before. Below shows what this payload would look like in practice:
Keylogging is another severe consequence which could be abused via cross site scripting, where an attacker could monitor everything you type on to a web page.
There are numerous keyloggers online and widely available on public code repositories such as GitHub which are all slightly different but achieve the same thing; all input from your keyboard being captured and sent to an attacker.
There are a few other prerequisites for this specific type of payload, but for now only the keylogging capability will be demonstrated.
The payload that will be being injected on our demo site is shown below:
When browsing to the page, it is not immediately obvious that keylogging is taking place to the user (aside from the username that was used to comment):
However, upon inspecting the source you can see the malicious script being referenced:
Now whenever a user visits this web page which has our malicious script injected, the script will be executed, resulting in any data that the user inputs being sent to our attacker-controlled site. Below shows an example of the data sent to the attacker’s web server:
All keystrokes are also logged in a file. The screenshot below shows some credentials that were captured!
An attacker could also take screenshots of your current page. Automated tools exist to make this easier and in this example we are going to use XSSHunter to automate it for us.
Again, this is not immediately obvious that anything has been executed (apart from the very obvious username I chose) – this would be completely invisible to the user upon initially visiting the web page:
However, in the background the script was called and executed. This resulted in the XSSHunter tool screenshotting the page for us to view:
In this instance, no sensitive data was captured. But can you imagine the impact if this was present within an online banking application?
This type of use for XSS could be equally as severe as the other consequences listed. Its been previously demonstrated that remote scripts can be referenced, which also means we can reference remote images and sites.
The below script is relatively simple as it just references a remote site:
Now whenever the page that had the payload is visited, the user will get directed to the site specified, in this case informer.io. Below shows the attack in action:
There are numerous other ways that defacement could be achieved and has happened to various companies and government sites in the past - this was just one example of how XSS could be used to do so.
Cross site scripting can be incredibly damaging to both the users of the site and the site owner. Only a small number of potential abuses of cross site scripting were covered, but it certainly demonstrates that there is more to cross site scripting than an alert box. When exploited in the wild by advanced persistent threats (APTs) more advanced payloads are used, making it even more difficult to detect, resulting in exploitation going undetected for months due to obfuscation techniques.
In the next addition to the cross-site scripting series, we will be covering what you can do to defend your site against these types of attacks.
Brandyn Murtagh, Security Consultant
Brandyn is a Security Consultant at Informer who recently attained his OSCP accreditation.
Learn why it's important to take a multi-layered approach to help prevent XSS attacks.Read Article >
In this post we are going to take a deeper dive into this vulnerability and investigate some of the more malicious payloads that could be usedRead Article >