Cross-site scripting (XSS) is a type of web application vulnerability that attacks a websites user rather than the server itself. XSS allows an attacker to impersonate a vulnerable user and conduct any activities or use any data that the user has access to.
The Open Web Application Security Project publishes the OWASP Top 10 report. It is a list of the most serious web application security concerns. In the OWASP Top 10 of 2017, XSS was the second most prevalent issue and was found in around two-thirds of all applications.
In this article, we’ll go through XSS attacks in detail, their impact, and how to mitigate them.
Disclaimer: This article is for educational purposes only.
How XSS works
- session cookies
- user credentials
Among other information.
First, we need to find a vulnerable website. As we can’t go around testing random websites on the internet, we’ll be carrying out this attack on an intentionally vulnerable website. We’ll be making use of an online vulnerable web application by Acunetix. To use the vulnerable web app, we visit Acunetix vulnerable application.
The next step is to locate an input field where we can paste our script. It could be a username, a search box, a text area, or any other type of input field. Our vulnerable website has a search box, perfect! Now, let’s give it some simple HTML code and see what happens. Type in the following HTML code in the search box and hit the go button:
<u>test</u> <!-- the HTML u tag or underline tag is used to give a word an underline in HTML -->
From the screenshot above we can see that the word
test is underlined. Perfect! We are getting a reflection on the page. By viewing the application’s source code, we can also see how it’s reflected.
We notice that as soon as we hit the go button after entering our XSS payload, we get an alert box with
Types of XSS
This is a one-time XSS. The malicious script is part of the victim’s online application request which is frequently reflected in the application’s response.
Reflected XSS is most commonly employed in targeted attacks where the hacker sends a phishing email with the malicious script in the URL. The attacker could even post a link on a public website and deceive the user into clicking it.
Also known as
Persistent XSS, the payload is saved on the server and can be triggered by a victim without requiring any user interaction outside of the application. This type of XSS happens when the server saves your supplied input somewhere into the server (i.e. a database or cache server).
Stored XSS Example
Let’s go back to our vulnerable web application. We click on the
Your profile tab, which presents us with a login page.
Now let’s log in with these default credentials:
username: test password: test
Now that we are logged in, let’s inject our payload in the name field and click on the update button to update our profile:
As we can see, we got an alert box. This occurred because the payload was saved in the name field, and the alert box was triggered every time the page was loaded.
The victim’s browser is directly affected by DOM XSS, a local attack. The Document Object Model (DOM), the browser’s API for manipulating and presenting web pages, is used in this attack rather than malicious content being delivered to the server.
The impact of XSS
Through XSS, the attacker can do the following:
- capture user credentials
- deface the website
- impersonate a user
- carry out user actions
How to mitigate XSS attacks
You may prevent XSS attacks through:
- the usage of appropriate response headers
- the filtering of user input
- the encoding of data on output
- sanitization of HTML
XSS is a common web vulnerability. Web vulnerability scanners such as burp suite, can be used to carry out XSS tests on web applications. You can read more on XSS here:
Peer Review Contributions by: John Amiscaray