xss.md 5.5 KB
title: CROSS-SITE-SCRIPTING course: intro_pentest section: "Web-Based Exploitation"
layout: lesson
Cross-site scripting, also referred to as XSS, is the process of injecting scripts into a web application. The injected script can be stored on the original web page and run or processed by each browser that visits the web page. This process happens as if the injected script was actually part of the original code.
Cross-site is different from many other types of attacks as XSS focuses on attacking the client, not the server. Although the malicious script itself is stored on the web application (server), the actual goal is to get a client (browser) to execute the script and perform an action.
As a security measure, web application only have access to the data that they write and store on a client. This means any information stored on your machine from one website can’t be accessed by another website. Cross-site scripting can be used to bypass this restriction. When an attacker is able to embed a script into a trusted website, the victim’s browser will assume all the content including the malicious script is genuine and therefore should be trusted. Because the script is acting on behalf of the trusted website, the malicious script will have the ability to access potentially sensitive information stored on the client including session tokens and cookies.
It’s important to point out that the end result or damage caused by a successful XSS attack can vary widely. In some instances, the effect is a mere annoyance like a persistent pop-up window, whereas other more serious consequences can result in the complete compromise of the target. Although many people initially reject the seriousness of XSS, a skilled attacker can use the attack to hijack sessions, gain access to restricted content stored by a website, execute commands on the target and even record keystrokes!.
You should understand that there are numerous cross-site scripting attack vectors. Aside from simply entering code snippets into an input box, malicious hyper-links or scripts can also be embedded directly into websites, e-mails and even instant messages. Many e-mail clients today automatically render HTML e-mail. Oftentimes, the malicious portion of a malicious URL will be obfuscated in an attempt to appear more legitimate.
In its simplest form, conducting a cross-site scripting attack on a web application that doesn’t perform input sanitization is easy. When we are only interested in providing proof that the system is vulnerable, we can use some basic JavaScript to test for the presence of XSS. Website input boxes are an excellent place to start. Rather than entering expected information into a text box, a penetration tester should attempt to enter the script tag followed by a JavaScript “alert” directly into the field. The classes example of this test is listen below:
<script>alert("XSS Test")</script>
If the above code is entered and the server is vulnerable, a JavaScript “alert” will pop-up. The following image shows an example of a typical web page where the user can log in by entering a user-name and password into the text boxes provided.
However, as previously described, rather than entering a normal user-name and password, enter the test script.
After entering our test script, we are ready to click the “Submit” button. Remember, if the test is successful and the web application is vulnerable to cross-site scripting, a JavaScript “alert” window with the message “XSS Test” should appear on the client machine.
Just as there are several attack vectors for launching cross-site scripting, the attack itself comes in several varieties. Because we are covering the basics, we will look at two examples: reflected cross-site scripting and stored cross-site scripting.
Reflected cross-site scripts occur when a malicious script is sent from the client machine to a vulnerable server. The vulnerable server then bounces or reflects the script back to the user. In these cases, the payload (or script) is executed immediately. This process happens in a single response/request. This type of cross-site scripting attack is also known as a “First Order XSS”. Reflected cross-site scripting attacks are non persistent. Thus, the malicious URL must be fed to the user via e-mail, instant message, and so on, so the attack executes in their browser. This has a phishing feel to it and rightfully so.
In some instances, the malicious script can actually be saved directly on the vulnerable server. When this happens, the attack is called a stored XSS. Because the script is saved, it gets executed by every user who accesses the web application. In the case of stored XSS attacks, the payload itself (the malicious script or malformed URL) is left behind and will be executed at a later time. These attacks are typically saved in a database or applet. Stored XSS does NOT need the phishing aspect of reflect XSS. This helps the legitimacy of the attack.
As mentioned earlier, cross-site scripting is a very practical attack. Even though we only examined the simplest of XSS attacks, don’t let this deter you from learning about the true power of cross-site scripting. To truly master this content, you’ll need to learn how to harness the power of XSS attacks to steal session from your target and deliver the other payloads discussed earlier in this section. Once you have mastered both reflected and stored cross-site scripting attacks, you should begin examining and studying DOM-based XSS attacks.