Cross-Site Scripting (XSS) Attacks PDF

Important ***Cross-site Scripting (XSS)*** attacks are a type of injection attack, in which malicious scripts are injected into trusted websites. ***Cross-site scripting*** vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to pe...

Important ***Cross-site Scripting (XSS)*** attacks are a type of injection attack, in which malicious scripts are injected into trusted websites. ***Cross-site scripting*** vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user\'s data. ***Cross-site scripting*** works by manipulating a vulnerable website so that it returns malicious JavaScript to users. When the malicious code executes inside a victim\'s browser, the attacker can fully compromise their interaction with the application. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application\'s functionality and data.   Characters that allow an XSS vulnerability to occur include double quotes (\"), single quotes (\'), and angle brackets ( \< \> ). ***XSS*** attacks can occur anywhere a ***web application*** accepts unsanitized user input within the output said web application generates without encoding it. The most severe ***XSS*** attacks involve disclosure of the user's ***session cookie***, allowing an attacker to hijack the user's ***session*** and take over their account. To detect an ***XSS*** vulnerability, the a hacker would typically use uniquely crafted JavaScript code snippet and inject that payload into each input vector found (after an attack surface analysis). Such input data is typically harmless, but trigger responses from the web browser that returns evidence that a possible ***XSS*** vulnerability is present in the web application.\   ***XSS*** vulnerabilities are solely executed on the client-side and hence do not directly affect the back-end server. They can only affect the user executing the vulnerability. The direct impact of ***XSS*** vulnerabilities on the back-end server may be relatively low, but they are very commonly found in web applications, so this equates to a medium risk (***low** impact* + ***high** probability* = ***medium** risk*), which we should always attempt to reduce risk by detecting, remediating, and proactively preventing these types of vulnerabilities.   An attacker can use ***XSS*** to send a malicious ***script*** to an unsuspecting user. The end user's browser has no way to know that the ***script*** should not be trusted, and will execute the ***script***. Because it thinks the ***script*** came from a trusted source, the malicious script could access any ***cookies***, ***session tokens***, or other sensitive information retained by the ***browser*** and used with that site. These ***scripts*** can even rewrite the content of the ***HTML*** page.   ***XSS*** vulnerabilities can facilitate a wide range of attacks, which can be anything that can be executed through browser JavaScript code. A basic example of an XSS attack is having the target/victim user unwittingly send their session cookie to the attacker\'s web server. Another example is having the target\'s browser execute API calls that lead to a malicious action, like changing the user\'s password to a password of the attacker\'s choosing.    As ***XSS*** attacks execute ***JavaScript*** code within the browser, they are limited to the browser\'s JS engine (i.e., ***V8*** in ***Chrome***). They cannot execute system-wide JavaScript code to do something like system-level code execution. In modern browsers, they are also limited to the same domain of the vulnerable website. Nevertheless, being able to execute JavaScript in a user\'s browser may still lead to a wide variety of attacks. In addition to this, if a skilled researcher identifies a binary vulnerability in a web browser (e.g., a ***Heap overflow*** in ***Chrome***), they can utilize an ***XSS*** vulnerability to execute a JavaScript exploit on the target\'s browser, which eventually breaks out of the browser\'s sandbox and executes code on the user\'s machine.   ***HTML Injection*** vulnerabilities can often be utilized to also perform ***Cross-site Scripting*** (***XSS***) attacks by injecting ***JavaScript*** code to be executed on the client-side. ***XSS*** is very similar to ***HTML Injection*** in practice. However, ***XSS*** involves the injection of ***JavaScript*** code to perform more advanced attacks on the client-side, instead of merely injecting ***HTML*** code.   **[Description ]**   **[*Cross-site Scripting* (*XSS*) attacks occur when:]**   1. Data enters a ***web application*** through an untrusted source, most frequently a ***web request***.   1. The data is included in dynamic content that is sent to a ***web*** user without being validated for malicious content.   1. When an attacker uses web application injection points such as HTML forms, URL parameters, and the body of a GET request (via a web proxy) to send malicious JavaScript code, generally in the form of a browser side script, to a different end user.   The malicious content sent to the ***web browser*** often takes the form of a segment of ***JavaScript***, but may also include ***HTML***, ***Flash***, or any other type of code that the ***browser*** may execute. The variety of attacks based on ***XSS*** is almost limitless, but they commonly include transmitting private data, like ***cookies*** or other session information, to the attacker, redirecting the victim to ***web*** content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.   ***XSS*** attacks can generally be categorized into 2 categories: [***Reflected*** and ***Stored***].   ***Reflected XSS Attacks***   Important ***Reflected*** attacks are those where the injected ***script*** is reflected off the ***web server***, such as in an error message, search result, or any other response that includes some or all of the input sent to the ***server*** as part of the ***request***. ***Reflected attacks*** are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable ***website***, which reflects the attack back to the user's ***browser***. The ***browser*** then executes the code because it came from a "trusted" server. ***Reflected XSS*** is also sometimes referred to as ***Non-Persistent*** or ***Type-I XSS*** (the attack is carried out through a single request/response cycle).   ***Stored XSS Attacks***    ***Stored*** attacks are those where the injected ***script*** is permanently stored on the target ***servers***, such as in a ***database***, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the ***server*** when it requests the stored information. ***Stored XSS*** is also sometimes referred to as ***Persistent*** or ***Type-II XSS***.   ***Blind Cross-site Scripting***   Important ***Blind Cross-site Scripting*** is a form of ***persistent XSS***. It generally occurs when the attacker's ***payload*** saved on the ***server*** and reflected back to the victim from the ***backend*** application.    *Example*: In feedback forms, an attacker can submit the malicious ***payload*** using the form, and once the ***backend*** user/admin of the application will open the attacker's submitted form via the ***backend*** application, the attacker's ***payload*** will get executed. ***Blind Cross-site Scripting*** is hard to confirm in the real-world.   ***XSS Attack Consequences***   The consequence of an ***XSS*** attack is the same regardless of whether it is ***stored*** or ***reflected*** (or ***DOM*** Based). The difference is in how the ***payload*** arrives at the ***server***. Do not be fooled into thinking that a "r*ead-only*" or "*brochureware*" site is not vulnerable to serious reflected ***XSS*** attacks.   Critical **XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user's session cookie, allowing an attacker to hijack the user's session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, or modifying presentation of content.**   1. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company's stock price or lessen consumer confidence.   1. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.   ***How to Determine If You Are Vulnerable***    ***XSS*** flaws can be difficult to identify and remove from a ***web application***. The best way to find flaws is to perform a security review of the code and search for all places where input from an ***HTTP*** request could possibly make its way into the ***HTML*** output. Note that a variety of different ***HTML*** tags can be used to transmit a malicious ***script***. ***Nessus***, ***Nikto***, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.   ***XSS via HTTP TRACE Method***   Caveat Also, it's crucial that you turn off ***HTTP TRACE*** support on all ***web servers***. An attacker can steal ***cookie*** data via ***Javascript*** even when ***document.cookie*** is disabled or not supported by the client. This attack is mounted when a user posts a malicious ***script*** to a forum so when another user clicks the link, an asynchronous ***HTTP TRACE*** call is triggered which collects the user's ***cookie*** information from the ***server***, and then sends it over to another malicious ***server*** that collects the *cookie* information so the attacker can mount a ***session hijack attack***. This is easily mitigated by removing support for ***HTTP TRACE*** on all ***web servers***.     **[Alternate XSS Syntax]**   ***XSS Using Script in Attributes***   ***XSS*** attacks may be conducted without using ***\***\...***\*** tags. Other tags will do exactly the same thing, for example: ***\*** or other attributes like: ***onmouseover***, ***onerror***.   ***onmouseover***    *Example*: ***\click me!\***   ***onerror***   Example *Example*: ***\***   ***XSS Using Script Via Encoded URI Schemes***   If we need to hide against web application filters we may try to encode string characters, e.g.: a=&\\\#X41 (UTF-8) and use it in IMG tags:    *Example*: \   There are many different ***UTF-8 encoding*** notations that give us even more possibilities.   ***XSS Using Code Encoding***   We may encode our script in ***base64*** and place it in a ***META*** tag. This way we get rid of ***alert()*** totally. More information about this method can be found in **RFC 2397**     The traditional way to prove that you\'ve found a cross-site scripting vulnerability is to create a popup using the ***alert()*** function. This isn\'t because [XSS](https://portswigger.net/web-security/cross-site-scripting) has anything to do with popups; it\'s simply a way to prove that you can execute arbitrary JavaScript on a given domain. You might notice some people using ***alert(document.domain)***. This is a way of making it explicit which domain the JavaScript is executing on.   Sometimes you\'ll want to go further and prove that an XSS vulnerability is a real threat by providing a full exploit.     **[Exploiting Cross-site Scripting to Steal Cookies]**   Stealing ***cookies*** is a traditional way to exploit ***XSS***. Most web applications use ***cookies*** for session handling. You can exploit ***cross-site scripting*** vulnerabilities to send the victim\'s ***cookies*** to your own domain, then manually inject the ***cookies*** into the browser and impersonate the victim. **[In practice, this approach has some significant limitations: ]**   1. The victim might not be logged in.   1. Many applications hide their ***cookies*** from ***JavaScript*** using the ***HttpOnly*** flag.   1. ***Sessions*** might be locked to additional factors like the user\'s ***IP address***.   1. The ***session*** might time out before you\'re able to hijack it. ** ** ** ** **[Exploiting cross-site scripting to capture passwords]**   These days, many users have password managers that auto-fill their passwords. You can take advantage of this by creating a password input, reading out the auto-filled password, and sending it to your own domain. This technique avoids most of the problems associated with stealing cookies, and can even gain access to every other account where the victim has reused the same password.   The primary disadvantage of this technique is that it only works on users who have a password manager that performs password auto-fill. (Of course, if a user doesn\'t have a password saved you can still attempt to obtain their password through an on-site phishing attack, but it\'s not quite the same.) ** ** ** ** **[Exploiting cross-site scripting to perform] [CSRF](https://portswigger.net/web-security/csrf)**   Anything a legitimate user can do on a web site, you can probably do too with ***XSS***. Depending on the site you\'re targeting, you might be able to make a victim send a message, accept a friend request, commit a backdoor to a source code repository, or transfer some Bitcoin.   Some websites allow logged-in users to change their email address without re-entering their password. If you\'ve found an ***XSS*** vulnerability, you can make it trigger this functionality to change the victim\'s email address to one that you control, and then trigger a password reset to gain access to the account.   This type of exploit is typically referred to as [cross-site request forgery (CSRF](onenote:#Cross-site%20Request%20Forgery&section-id=%7BB07A597B-3A0A-4E91-84C8-F78AD2D0EF96%7D&page-id=%7B637D7549-5D2D-4074-81CC-D56D7E0A5BBB%7D&end&base-path=https://d.docs.live.net/0323c8769028f7d4/Documents/Ethical%20Hacking/Web%20Attacks.one)), which is slightly confusing because ***CSRF*** can also occur as a standalone vulnerability. When ***CSRF*** occurs as a standalone vulnerability, it can be patched using strategies like anti-CSRF tokens. However, these strategies do not provide any protection if an ***XSS*** vulnerability is also present.     **[Cross-site Scripting Examples]**   ***Reflected XSS Example***   Suppose a website has a search function which receives the user-supplied search term in a URL parameter:       The application echoes the supplied search term in the response to this URL:   Example *Example*: \You searched for: gift\   Assuming the application doesn\'t perform any other processing of the data, an attacker can construct an attack like this:    [https://insecure-website.com/search?term=\/\*+Bad+stuff+here\...+\*/\](https://insecure-website.com/search?term=%3cscript%3e%3c/script%3e)   This URL results in the following response:   Example *Example*: \You searched for: \/\* Bad stuff here\... \*/\\   If another user of the application requests the attacker\'s ***URL***, then the script supplied by the attacker will execute in the victim user\'s browser, in the context of their session with the application.     ***Stored XSS Example***   Suppose a website allows users to submit comments on blog posts, which are displayed to other users. Users submit comments using an ***HTTP* POST** request like the following:    POST /post/comment HTTP/1.1 Host: vulnerable-website.com Content-Length: 100   postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net   After this comment has been submitted, any user who visits the blog post will receive the following within the application\'s response:   Example \This post was extremely helpful.\   Assuming the application doesn\'t perform any other processing of the data, an attacker can submit a malicious comment like this:    \/\* Bad stuff here\... \*/\   Within the attacker\'s request, this comment would be URL-encoded as:   Example comment=%3Cscript%3E%2F\*%2BBad%2Bstuff%2Bhere\...%2B\*%2F%3C%2Fscript%3E   Any user who visits the blog post will now receive the following within the application\'s response:    \\/\* Bad stuff here\... \*/\\   The script supplied by the attacker will then execute in the victim user\'s browser, in the context of their session with the application.