Cross-Site Scripting is harmless? Think again!
One of our main tasks at Compass Security is testing web applications for security issues. Thus, we can safely say that many current web applications are affected by this type of vulnerability, even though protecting against it is simple. For simplicity reasons, XSS is usually depicted as a popup window displaying simple text.
Such a popup would be induced by the following code:
The entire attack would look as follows, given that the parameter param is vulnerable. Assume that the following code is used by a web application without employing output encoding:
<input type="text" name="param" value="user_input">
Here, user_input is the non-output encoded data provided by the user.
Then, an attacker can exploit this by setting param to
which will lead to the following being sent to the user:
<input type=”text” name=”param” value=”“><script>alert(0)</script><!–“>
resulting in the above popup being displayed.
When discussing XSS with customers, one of the more common statements we hear is: “this issue is harmless; it only displays text in a popup window”. This is not true, however, since XSS is far more powerful than often suspected. It allows an attacker to take full control over the victim’s browser. The victim, in this case, is the user who visits the attacked website. Common attack vectors include the victim’s session cookie being stolen, if it is not protected by the so-called HttpOnly flag. Further, the affected website can be manipulated so that the user is redirected to a Phishing website, allowing the attacker to obtain the user’s credentials. Finally, if the victim’s browser is outdated and contains known vulnerabilities, these can directly be exploited via Cross-Site Scripting and, if successful, lead to the victim’s computer being compromised.
Among many different types of attack vectors, BeEF allows, e.g., displaying a password prompt to the user (in the user’s browser):
Simple! Just encode user-provided data before echoing it back to the user. An effective method is to use HTML entities:
“ is encoded as ",
< is encoded as <,
and so forth (for a detailed explanation, refer to https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet).
If you want to see this any many more typical web application vulnerabilities, try them out yourself, and learn how to defend against them, register for our next Web Application Security course:
The Web Application Security (Basic/Advanced) courses will introduce all major web application attack vectors via theory and hands-on challenges in our Hacking-Lab: