Cross-site Scripting (XSS) [explanation & details]

CyberPunk Vulnerability Analysis
Last Release: 12/19/2019     Last Commit: 03/20/2022
Cross-site Scripting (XSS) [explanation & details]

Introduction

Cross-Site Scripting (XSS) attacks are a type of injection, in which attackers/hackers can execute malicious scripts/payload in another user’s browser.

Wherever we have a website with dynamically generated code without adequate encoding and input field filtering, can become a victim of XSS attacks. From the user’s perspective, everything will still look normal and they won’t even know that their data are compromised.

What is Cross-site Scripting (XSS)?

Cross-site Scripting (XSS) is one of the most common hacking technique when it comes to the web application vulnerabilities, and occurs when a web app generate an output based on user input. If the web page contains input fields without proper validation and encoding, it will surely be caught by hacker’s eye.

XSS allows hackers to run their malicious JavaScript in the victim’s browser which can hijack user sessions, redirect user to a “non-friendly” site, spread malware, create false requests, steal user identity and sensitive data such as: credentials, passwords, credit card numbers, etc. Cross-site scripting (XSS) flaws are classified into three groups:

  • Stored/Persistent XSS
  • Reflected XSS
  • DOM-based XSS

XSS attack needs three actors: the website, the victim and the attacker.

How Cross-site Scripting (XSS) Works?

Cross Site Scripting (XSS) attack means sending and injecting malicious code or script into victim’s browser, which are usually written with client-side programming languages such as Javascript and HTML. So, in order to run malicious JavaScript, the first step is to identify which field/part of the web page is susceptible to XSS.

When attacker finds the vulnerable part of the website and sent it as malicious input, and a user (victim) visits infected part, the injected code will be executed in the user’s browser. That’s mean that the attacker has successfully bypassed the browser’s SOP (Same Origin Policy) and is able to play with a victim’s life as he wish.

For example, simple server-side script is used to display the latest comment on a website:

print "<html>"
print "Latest comment:"
print database.latestComment
print "</html>"

The above script will simply print out the latest comment from a comments database. Comment should consists only of text, but in this case, the user input is included directly. Therefore, attacker could easily submit comment that contains a malicious payload within <script>destroyEverything();</script> tags, and make some serious damage.

When user’s visits page, it will receive the response below, and destroyEverything() will be executed:

<html>
Latest comment:
<script>destroyEverything();</script>
</html>

Stored/Persistent XSS

Stored (persistent) type of XSS attack occurs when an attacker stores malicious JavaScript into web app’s database. This type of attack, where the malicious script is being saved on the server and executed every time when the user visit/load the page, is the most devastating XSS attack since it can destroy the whole system and effect many, even all users.

The malicious JavaScript, which is being stored in the database, might be submitted to the web app via HTTP requests. It involves: blog post comments, chat rooms, every type of message board where users can submit their messages. So, the common example to perform Stored XSS Attack is to display malicious code in the blog comment section, for example:

<script>alert(document.cookie)</script>

Stored Cross-site Scripting (XSS)

  1. The Evil Hacker inject payload containing a malicious JavaScript in the website’s database by submitting a vulnerable form.
  2. The victim requests a page from the website.
  3. The website serves the victim’s browser the page with the evil hacker’s payload (malicious JavaScript is included in the response)
  4. The victim’s browser executes the malicious script inside the response,and sends the victim’s cookies to the evil hacker’s server.

Reflected XSS

Reflected XSS attack occurs when the malicious JavaScript (string) is sent as a part of the victim’s request to the website. In the reflected type of attack, is not going to be saved permanently, but the malicious code will be reflected back to user. (fake URLs or HTTP requests/parameters). This type of Cross-site scripting (XSS) is commonly found in phishing attacks.

For example, an attacker might craft a malicious URL that exploits a vulnerable web app and trick the user to click malicious URL, using phishing/social engineering techniques. Malicious code will be reflected back to the victim, and it will be executed in the victim’s browser.

Reflect Cross-site scripting (XSS)

  1. The Evil Hacker crafts a URL containing a malicious JavaScript and sends it to the victim.
  2. Tricked victim requests the URL from the website.
  3. The malicious code is being reflected back to the user (malicious code in the response).
  4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the evil hacker’s server.

DOM-based XSS

DOM-based XSS attack is slightly different from previous two XSS techniques, but we can say it represents a variant of both stored (persistent) and reflected XSS. It occurs when the attack payload is executed by modifying the DOM.  DOM-based XSS is client-side attack So, the injected payload will never go to the server and it will only ever be processed by the client, which is the main difference between this and previously explained types of XSS attacks.

For example, web app uses some JavaScript to read the value from an input field and write that value to an element within the HTML. If the input field is not properly sanitized, attacker will be able to inject malicious value and execute evil script.

DOM-based Cross-site Scripting (XSS)

  1. The Evil Hacker crafts a URL containing a malicious JavaScript and sends it to the victim.
  2. Tricked victim requests the URL from the website.
  3. The website receives the request (malicious JavaScript not included)
  4. The victim’s browser executes the legitimate script inside the response which will insert malicious JavaScript into page.
  5. The victim’s browser executes the inserted malicious script, sending the cookies to the evil hacker’s server.

Cross-site Scripting (XSS) Prevention

Preventing cross-site scripting (XSS) seems easy, but it can be more complex then we think. There are plenty of XSS Scanners and tools that can help us identifying XSS vulnerabilities, such as XSStrike – Advanced XSS Detection Suite, XSS Scanner (online), etc. Of course, identifying isn’t the only thing we need to do. We’ll list some crucial steps in XSS prevention process below.

  • Escape submitted user input/output so that the browser interprets it only as data, not as code (e.g. HTML escaping: converting <script>...</script> into &lt;script&gt;...&lt;/script&gt; ).
  • Validate user submitted input/output (blacklisting/whitelisting, reject and sanitize malicious input)
  • Secure input handling from both client-side (front-end) and server-side (back-end)
  • Enable CSP (Content‑Security‑Policy).

In order to give users the best and trusted web experience as possible, every developer need to know how to secure their websites.

If you want to learn more about vulnerabilities that can be found in Java-based applications, to gain more knowledge about web security and develop your penetration testing skills, you can try out WebGoat 8 – A Deliberately Insecure Web Application.

PhishingSocial EngineeringXSS