What is Cross Site Scripting?
Cross-site scripting (or “XSS”) is a vulnerability in web applications that's caused by insecure coding practices, which do not sanitize user input. If a user of a vulnerable web application can pass scripts to the server and the server does not attempt to discover and remove scripts (“sanitizing input”), then the script can be executed in the context of the user's browser.XSS attacks can cause a web browser to be redirected to a malicious site, theft of a session ID, and even steal authentication cookies allowing an attacker to impersonate somebody else (including a web administrator) to gain access to otherwise restricted resources.There are generally three types of XSS attacks:
How to Discover an XSS Vulnerability
- Reflected (AKA non-persistent) XSS: this occurs when a script is executed on a one-time basis. Usually, this takes the form of a script injected into a URL, which is then passed to the target. When the target opens the URL, the script executes.
- Stored (AKA persistent) XSS: this attack occurs when a server is made to store a script such that when users visit the website, the script is executed in the context of the browser. The classic example of this type of XSS is when a malicious user finds a form on a site (such as a comment section or web forum) that stores content does not block the execution of scripts. They place the script in a comment or as a signature in their user account. Whenever the page loads the script is executed. A more nefarious example may be when a user enters a script into a “feedback” section of the website in order to execute a script inside the browser of an administrator who later reviews feedback messages.
- DOM-based XSS: this attack occurs by manipulating an existing script that's served to a user, such that the script executes on the client in a manner that's not anticipated. A DOM-based attack does not modify the source code of the website (as reflected and stored XSS do), but instead “tricks” the browser that receives the HTTP response to execute the code in a way that was not intended.
Not all of these techniques will work for any given application. Testing for XSS vulnerabilities is a trial and error process because you need to feel out what, if anything, is being filtered. You can manually try various bypass techniques or you can use a fuzzer. “Fuzzing” refers to the process of providing a wide variety of unexpected input to some application and observing how the application behaves.Typically, this requires the use of a tool to automate the process and provide the various input types to the application. This may take a short or long period of time depending on how comprehensive you make the process. OWASP's free tool Zed Attack Proxy includes the capability to fuzz web applications or entire websites. Remember to use the tool only against resources you own or have explicit permission to test.Common techniques to bypass script filtering involve encoding part or all of the injected script. There are basically two methods of encoding the script: URL and hex encoding.You can find URL or hex encoders online that you can use to encode any given script. Since web applications need to encode various parts of a URL (such as blank spaces in a search query), browsers can read encoded script content. If a firewall is not configured to check for the URL or hex encoded versions of these strings, they may be allowed to pass through. But, when the victim browser loads the content it will decode the script and execute it.Scripts can also be double-encoded (that is, encode the script and then encode the encoded script) to achieve the same results. Some firewalls will only check for single-encoded scripts, but most browsers can also read double-encoded content.Below is a list of various types of input that may bypass a filter to inject code and an explanation for why they work. This is by no means a comprehensive list of bypass techniques. OWASP maintains a very comprehensive list of techniques that may be used
. All of the techniques below can be found on the site. Each technique listed here was tested by me against an Apache webserver under my control inside a VirtualBox hypervisor. The bypass: <SCRIPT>alert('XSS')</SCRIPT>Why it works:
A WAF may have a rule to strip “<script>” whenever the tag is seen. Adjusting the case of the tag may work if the WAF rule is case-sensitive. You can also capitalize any random set of letters in each tag instead of capitalizing all letters. The bypass: <a onmouseover=alert('XSS')>Test link</a>Why it works:
This code injects an invisible image that contains, as its data, the OnMouseOver function instead of a pointer to an image file. If the victim mouses over the location of the tag, the dialogue box containing the text “XSS” will pop up. The bypass: <img src=/ onerror=”alert(String.fromCharCode(88,83,83))”>Why it works:
In this case you must replace “script_location” with an actual URL that points to a different website that runs a script. Here, we have generated an iframe in the HTTP response that's used to load a script from a different location. Because iframes are important tools in many web applications and may need to be used, there's a reasonable chance this technique can work. For some browsers, you need to malform the tag so the end bracket is open instead of closed. The bypass: <iframe src=alert('XSS')>Why it works:
Similar to the previous example, iframes are common and may need to be used by web applications. In this case, we have loaded an iframe onto the page that executes the script instead of calling a remote script on a different website. The bypass: <body onload=alert('XSS')>Why it works:
Here, we have injected the OnLoad function into a <body> tag. When the body of the site loads, the OnLoad function triggers the dialogue box. - Thanks and please post your comments and questions below. -