Overview of XSS vulnerabilities in Web Applications with Mutillidae
Introduction / TLDR
When transferring data from the client to the server side, a lot of script changes are done to the original code to hack the data. The major challenges that arise when trying to tackle vulnerabilities like this is, the proposed technology has to block every insertion of malicious scripts and stay current of new techniques. Should you tackle server side or client side remediation, you must build a solution adapted to your system. Mitigation by design is the approach that has the highest percentage of avoiding successful attacks, but in some cases is not possible to build a service with less attack vectors, for reasons like usability and readability, necessary in its design. To carry out a successful analysis and evaluation of OWASP’s Mutillidae, we will be following The Open Source Security Testing Methodology Manual (OSSTMM) 4 point process, starting with Induction, Inquest, Interaction and finalising with Intervention.
Background on XSS
What is Cross Site Scripting?
Cross-Site Scripting (XSS) attacks are a type of code injection vulnerability where a malicious payload is inserted into otherwise benign or trusted websites[1]. This payload usually takes the form of code, generally in the shape of a browser script, sent to a different target. Flaws that allow for XSS usually involve an attacker exploiting a web application that uses input from users, where the output it generates isn’t validated or encoded. These bugs can be quite widespread and occur anywhere in an application, where it has a similar attack vector to an input field. Cross-Site Scripting (XSS) attacks occur when data enters an application through an untrusted source, normally via Web request. The unsuspected end user’s browser will execute the script, since it came from said trusted source, allowing the attacker to access cookies, tokens or other sensitive information[1]. This happens when the data is included in dynamic content being sent to the web user without proper validation.
What are some types of XSS?
The malicious content sent to the web browser often takes the form of a JavaScript payload, but can also include HTML, Flash, CSS etc. The rule of thumb being any type of code executable by a browser. The variety of XSS based attacks almost has no limits. Commonly, the aim is to transmit private data, like session information to the attacker, so the victim can be redirected to web content controlled by the malicious user.
XSS attacks are categorised into stored, reflected, and the less well-known, DOM based XSS.
Stored XSS
Stored XSS attacks, like the name suggests, are those where arbitrary content is injected in the input field, and are permanently stored on the target servers, like databases. Possible attack vectors for these could be message forums, visitor logs, comment fields etc.The victim would accidentally execute these scripts when requesting the stored information. Stored XSS is also known as Persistent or Type-i XSS. Stored XSS is similar to Reflected XSS, but there is a delay. After injecting the malicious payload, it would wait for a user to navigate to that page for execution. This is also known as Blind Cross-site Scripting, where the attacker’s paload is saved on the server and reflected back to the victim from the backend application. An example scenario could be a feedback form, and once the user opens the hackers form, the malicious payload is executed. Here, the term “blind” becomes more clear, as we don’t know when the victim will execute the script, or if it ever will. For this reason, Blind Cross-site scripting is very hard to verify in the real world. A well known tool for confirming this type of stored XSS is XSS Hunter, a service that hosts specialised XSS probes, which scans the page and sends information about the vulnerable site to the XSS hunter service [2].
Reflected XSS
Reflected XSS refers to types of XSS attacks that display a response on the screen, in other words, input from the user is directly returned by the browser. This could be an error message, search result, or similar scenario where the response includes some or all of the malicious input sent to the server, as part of the request. Typically, Reflected XSS are delivered to the victim via different routes, for example an e-mail message. An example scenario could be, a user tricked into clicking on a malicious link, browsing to a malicious site, where the injected code travels to the vulnerable site, reflecting the attack back to the user’s browser. Reflected XSS is also referred as Non-Persistent or Type-II XSS.
DOM Based XSS
DOM Based XSS was first discovered by Amit Klein in 2005[3]. In this vulnerability, an attacker is able to create arbitrary nodes, by allowing the insertion of malicious code directly into the DOM. By modifying the DOM environment in the target’s browser used by the original client side script, the website will run in an unexpected manner. The HTTP response (the page itself) does not change, but the client side code contained in the page will behave differently. In contrast with Stored or Reflected XSS, where the attack payload is placed in the response page[4] . DOM based XSS is also known as Type-0 XSS.
Example Mitigations
To prevent XSS many solutions have been proposed. OWASP has proposed solutions like “AntiSanny” , to prevent XSS attacks. Here API’s are used to filter and validate the input incoming from the attempted attack, and later encode the output. This tool leverages this functionality by practicing techniques seen in NekoHTML and Policy Files. NekoHTML parses HTML to XML files, and Policy Files then ensures authentication of HTML and CSS entities by setting specific rules for collective attributes, general expressions, tags and other commands [31]. There are also libraries that help prevent XSS vulnerabilities like HTML Purifier, which is an HTML filter library, where the standards are engraved in PHP. XSS Guard, is a tool that produces almost identical HTTP payloads producing the same responses, to compare the ones received and distinguish malicious from benevolent content. This is made by producing duplicate responses from the scripts projected by the web application. XSS auditor, used to be implemented by chrome[5], many other browsers have done the same, X-XSS-Protection or similar has been left behind, due to modern browsers implementing a strong Content-Security-Policy, and deeming it unnecessary. Content-Security-Policy disables the use of inline Javascript(‘unsafe-inline’)[24].
Head over to Overview of OSSTM for an example methodology you can follow to exploit XSS. It will be used for the Mutillidae XSS Dive
References
[1] Owasp.org. 2021. Cross Site Scripting (XSS) Software Attack | OWASP Foundation. [online] Available at: https://owasp.org/www-community/attacks/xss/ . [2] Owasp.org. 2021. Cross Site Scripting (XSS) Software Attack | OWASP Foundation. [online] Available at: https://owasp.org/www-community/attacks/xss/ . [3] Webappsec.org. 2021. [DOM Based Cross Site Scripting or XSS of the Third Kind] Web Security Articles - Web Application Security Consortium. [online] Available at: http://www.webappsec.org/projects/articles/07110 5.shtml . [4]Owasp.org. 2021. DOM Based XSS Software Attack | OWASP Foundation. [online] Available at: https://owasp.org/www-community/attacks/DOM _Based_XSS . [5]Cimpanu, C., 2021. Google to remove Chrome’s built-in XSS protection (XSS Auditor) | ZDNet. [online] ZDNet. Available at: https://www.zdnet.com/article/google-to-remove- chromes-built-in-xss-protection-xss-auditor/ . [24]Developer.mozilla.org. 2021. X-XSS-Protection - HTTP | MDN. [online] Available at: https://developer.mozilla.org/en-US/docs/Web/HT TP/Headers/X-XSS-Protection . [31]2019. XSS Attack Prevention over Code Injection Vulnerabilities in Web Applications. [ebook] IJITEE. Available at: https://www.ijitee.org/wp-content/uploads/papers/ v8i8/G5456058719.pdf .
