Cross Site Scripting or XSS as it is popularly known, is one of the common vulnerabilities found in web applications. It has firmly retained its spot in the OWASP Top 10 Application Security Risks — 2017. In this post, we discuss about how to test Cross Site Scripting (XSS) vulnerability in web apps. If you want to understand what XSS is, I recommend reading it here.
Typically when we encounter an input field in web page, we go straightaway and insert the most loved XSS payload <script>alert(‘XSS’)</script> to see if we get an alert box like this.
If that happens, great!
Just in case you do not get pop-up box, the application may still be vulnerable to XSS attack. Here is what we are going to do next. The first step is to figure out where the user input goes into the web page, I mean where in the HTML page the provided user input is inserted without any validation and output encoding.
Web page with input field
Let us look at the following cases and observe where the user-input has gone into the web page.
- Context — body
2. Context — HTML attribute
3. Context — hidden variable
4. Context — JavaScript
5. Context — DOM
6. Context — CSS
As you have rightly observed the user input has gone into various places or contexts i.e. body, HTML attribute, hidden variable, JavaScript, HTML DOM, CSS. The classical payload executes only in one case i.e. when the user input is inserted in the body.
In all other cases, the application is still vulnerable to XSS but the payload fails to execute. The reason is simple <script>alert(‘XSS’)</script>did not execute when inserted in other contexts like HTML attribute, DOM, JavaScript, hidden var, CSS.
In part_2 of this series we will discuss about various payloads that we can use in different context to confirm the presence of XSS.
