---
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:

```javascript
<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.

![](/img/courses/intro-pentest/xss1.png)
![](/img/courses/intro-pentest/xss2.png)

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.
