View source for Cross-Site Scripting (XSS)

[[Category:Basic]]
== Cross-Site Scripting (XSS) ==

 [[Image:xss_diagram.png|300px|thumb| The operational principle of stored Cross-Site Scripting (XSS)]]


Cross-Site scripting is a web application vulnerability that allows those exploiting it to inject and execute Javascript code on victim's machine. It is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of a web application. XSS is a vulnerability of the injection type, meaning that without proper validation/sanitisation of the user input, an attacker could steal data from users, like cookies and private information or even get control over the machine. This vulnerability is also capable of triggering website actions, redirecting to other sites or hiding advertisements. There are three major types of XSS that are listed below.

== Types ==
There are two ways to classify XSS attacks. Up until 2012, there were three types of XSS, DOM-based (Type 0), reflected/non-persistent (Type I) and stored/persistent (Type II). However, due to the potential overlap among these three types, the research community introduced the terms Server XSS and Client XSS from 2012 onward.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]


=== Reflected XSS (Type I) ===
Reflected XSS or non-persistent XSS  can occur when unchecked and unmasked user input is immediately returned by a web server. By injecting executable javascript code, the attacker could execute arbitrary HTML, compromising the victim's browser and even stealing session cookies. Typically, an attacker would craft a malicious link (phishing link) with the payload to a vulnerable website and bait the user to click on it. Most of the time, these links are found in advertising, e-mail, suspicious websites, etc. 

=== Stored XSS (Type II) ===
Stored XSS, also known as persistent XSS, occurs when the application or API stores unvalidated user input on the server, for example, in a database, comment field, visitor log, etc. This stored input is later retrieved and displayed by another user or administrator who requests the stored information.

=== DOM Based XSS (Type 0) ===
DOM-based Cross-Site Scripting occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks occurs when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is also most of the time injected in the form of a phishing link. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

=== Server XSS ===
Server XSS occurs when untrusted data is included in an HTTP response sent by the server. The source of this data could be from the request or a stored location (e.g., database). Both Reflected Server XSS and Stored Server XSS count as Server XSS.

=== Client XSS ===
Client XSS happens when untrusted data is used directly to manipulate the DOM (Document Object Model) via unsafe JavaScript methods on the client side.

== XSS attack consequences ==

A Cross-Site Scripting (XSS) attack can have various severe consequences, including:

'''Data Theft''': Stealing sensitive user data such as login credentials, session tokens, and personal information.

'''Identity Theft''': Stealing user identities to take over their accounts, resulting in fraudulent activity.

'''Session Hijacking''': Taking control of user sessions and accessing their accounts without the user's knowledge.

'''Malware Propagation''': Injecting the malicious code into websites, which is then executed by unsuspecting users, resulting in the spread of malware.

'''Phishing''': XSS can be employed to display fake login forms or deceptive content on legitimate websites, leading to phishing attacks.

'''Content Manipulation''': Manipulation of website content to send users false information or carry out malicious actions on their behalf.

'''Reputation Damage''': Cross-Site Scripting (XSS) attacks have the potential to damage user confidence in a website or application, particularly in cases where personal information is exposed.
== Prevention==

The prevention of these vulnerabilities is the responsibility of the programmer. Programmers should adopt secure programming practices, such as context-sensitive server-side output encoding, to ensure the prevention of malicious script injections through incorrect or unchecked entries.



Effective prevention measures include:

'''Input validation''': Rigorous validation of user input before acceptance and processing by the server is crucial to prevent cross-site scripting attacks.

'''Output encoding''': Encoding all output data (using HTML entities) is another effective measure to prevent cross-site scripting. This ensures proper display in the user's browser.

'''Content Security Policy (CSP)''': Implementing a Content Security Policy defines rules for the types of content a website can load, contributing to preventing cross-site scripting attacks.

'''Use of tokens''': Employing random character strings (tokens) to identify users can help prevent cross-site scripting attacks, ensuring that only authorized users access the website.

'''Disabling script execution''': While disabling script execution on the server, especially for certain scripting languages like JavaScript or VBScript, can help prevent cross-site scripting, it is rarely used due to the widespread use of JavaScript.

'''Secure Password Policies''': It is recommended to use complex passwords and consider introducing multi-factor authentication for an additional layer of security.

'''Session Management''': The application of session management, such as session timeout, involves configuring actions related to sessions.

'''Security Patching''': Ensuring that all software, including web servers, databases and frameworks, are kept up to date with the latest security patches. Regular updates and patches should be applied to fix known vulnerabilities in the system.

'''Security Audits and Code Reviews''': Conducting regular security audits and code reviews to help identify and remediate potential vulnerabilities. Third-party security assessments can provide an independent assessment of your application's security posture.




==Demonstrations==

This section demonstrates the three Cross-Site Scripting (XSS) attacks using the intentionally vulnerable OWASP Mutillidae II platform. These demonstrations include Stored XSS, Reflected XSS, and DOM-based XSS attacks, showcasing how vulnerabilities can be exploited to steal sensitive information in real-world scenarios. Specifically, these examples focus on stealing the victim's cookies.

If you want to recreate these attacks, refer to this article: https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021) for detailed instructions on installing and using OWASP Mutillidae II.

===Preparation Steps=== 
Before demonstrating the attacks, it's essential to understand the groundwork required for successful execution. This includes identifying vulnerabilities, inspecting cookies, and preparing the necessary scripts and files for the exploitation process.

====Searching for Exploits====

Identifying vulnerabilities is a the first step. Attackers exploit weaknesses in web applications to inject malicious scripts. Techniques include:

* Analyzing the Page Source: Review the HTML and JavaScript code for insecure functions like innerHTML, document.write, or unescaped user inputs. These functions often process user-supplied data without proper sanitization, creating potential attack vectors.
* Testing Input Fields: Use simple script tags to test input validation. For example, <script>alert("Yooooooo")</script> can reveal whether the application sanitizes or escapes user input. If the alert box appears, it indicates the input field is vulnerable.
* Using Developer Tools: Open developer tools (F12) in your browser to inspect how data is handled:
* Check the "Application" tab for cookies or local storage.
Inspect server responses and client-side behavior to understand how data flows between them.

[[File:Innerhtml.PNG]] [[File:Test-script.PNG]]

Exploring these areas helps pinpoint potential vulnerabilities that can be leveraged in the attacks.

====Inspecting Cookies====

Cookies are a primary target for XSS attacks because they often store sensitive session data like authentication tokens. To check their accessibility:

* Developer Tools Navigation: Go to the "Application" tab in browser developer tools and locate the "Cookies" section under "Storage."
* Check for Security Flags: Look for cookies missing protective flags such as HttpOnly (prevents client-side access), Secure (ensures transmission over HTTPS), or SameSite (restricts third-party context usage).
* Use the Console: Enter document.cookie in the browser console to see if cookies are accessible. If cookies are displayed, they are vulnerable to theft.

[[File:Document-cookies.PNG]] [[File:Httponly-no.PNG]]

Understanding how cookies are stored and secured provides critical insight into an application's vulnerability.

====Required Files====

To execute the XSS demonstrations successfully, the following files and scripts are essential:

* Cookie Logger Script (cookie-logger.php): A PHP script hosted on the attacker’s server to log cookies sent by the malicious payload. It listens for a cookies parameter in the URL, extracts its value, and writes it to the stolen-cookies.txt file along with a timestamp.
* Stolen Cookies File (stolen-cookies.txt): A plain text file used to store intercepted cookies. Each entry includes the captured cookie data and the timestamp of when it was received.
* Malicious Script: A custom JavaScript payload crafted to exploit the identified vulnerabilities. This script retrieves cookies using document.cookie and sends them to the attacker’s cookie-logger.php script.

[[File:Php-script.PNG]]  [[File:Stolen-cookies.PNG]]

These files and scripts form the backbone of the XSS demonstrations. Ensure they are set up correctly and tested in a controlled environment to replicate the attacks.

====Demonstrations====
=====Stored XSS=====
Stored XSS involves injecting malicious scripts that are permanently stored on the server, such as in a database or a comment field. These scripts execute whenever a victim accesses the vulnerable page. I used the ”Add to your blog” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/Persistent (Second Order) in Mutillidae II.

This is the script we then send to the database to essentally "poison" the website:

[[File:Stored-script.PNG]]

Once this is uploaded one can check if its properly working by visiting this website from another device and also ckecking the stolen-cookies.txt file. If, after visiting the site, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a Stored XSS attack.

=====Reflected XSS Attack=====

Reflected XSS uses a crafted URL that directly includes the malicious payload, which is reflected back in the server's response. This attack relies on tricking the victim into clicking the URL. I used the ”DNS Lookup” found underOWASP 2017/A7 - Cross-Site Scripting (XSS)/Reflected (First Order) in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Coded-reflected.PNG]] [[File: Decoded-reflected.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a ReflectedXSS attack. Note:the second and thrid IP should be the attackers servers IP.

=====DOM based XSS=====

DOM-based XSS manipulates the client-side Document Object Model (DOM) without server interaction. The attack occurs entirely in the victim's browser. I used the ”Password Generator” found under OWASP 2017/A7 - Cross-Site Scripting (XSS)/DOM-Based in Mutillidae II.

This is the manipulated URL that one has to send(coded and decoded):

[[File: Dom-xss-coded.PNG]]    [[File:Decoded-dom-based.PNG]]

You can now send this URL to yourself to test it out and also ckeck the stolen-cookies.txt file out. If, after visiting the site through that URL, the file has something in it (the Cookie) then its properly working and you have successfully finshed/done a DOM based XSS attack. ote:the second and thrid IP should be the attackers servers IP.


These demonstrations illustrate the risks of XSS attacks and their potential to steal sensitive data like cookies. Understanding these methods is crucial for identifying and mitigating vulnerabilities. Always practice responsibly in controlled environments like OWASP Mutillidae II to promote safer web applications.

== References ==

* https://owasp.org/www-community/Types_of_Cross-Site_Scripting
* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)
* https://portswigger.net/web-security/cross-site-scripting
* https://www.sans.org/white-papers/988/
* https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting?view=aspnetcore-8.0
* https://www.wallarm.com/what/a7-cross-site-scripting-xss-2017-owasp
* https://wiki.elvis.science/index.php?title=OWASP_Mutillidae_(2021)