The principle of XSS cross-scripting attack

XSS attacks, the full name of cross site scripting attacks (Scripting), are abbreviated as XSS, primarily to differentiate from cascading style sheets (cascading stylesheets,css) to avoid confusion. XSS is a computer security vulnerability that often appears in web applications, allowing malicious Web users to embed code into pages that are available to other users. The code includes HTML code and client script. For cross-site scripting attacks, the hacker consensus is that cross-site scripting attacks are a new type of "buffer overflow attack", and JavaScript is the new "ShellCode".

The purpose of an XSS attack is to steal client-side cookies or any other sensitive information that can be used to identify a customer on a Web site. With the tag of a legitimate user at hand, hackers can continue to act as users interacting with the site to impersonate the user. Cross-site scripting attacks occur if a malicious person (an attacker) can force an unsuspecting user (the victim) to run a client-side script that the attacker chooses.

The technical foundation of a WEB application is made up of HTTP and HTML. The HTTP protocol is the transport mechanism for HTML, and you can use code to design Web page layouts and build pages. If the WEB application accepts input from a user through an HTTP request, such as GET or POST, and then uses the output HTML code to display the information in some places, there may be an XSS vulnerability.

1. The WEB request looks like this:

Http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. After the request is made, the HTML content returned by the server includes:

As you can see, user input passed to the "title" query string parameter may be saved in a string variable and inserted into the

3. Now, if the site does not filter user input on the server side (because the client control can always be bypassed), a malicious user can use many means to abuse the vulnerability:

Attackers can inject code by getting rid of the

<scrīpt>alert (' xss%20attack ') </scrīpt ">

Http://www.somesite.com/page.asp?pageid=10&lang=en&title=section%20title

The HTML output for this request will be:

The following is reproduced from: https://www.zhihu.com/question/26628342/answer/33504799

1, first to analyze the LZ said dom-based XSS.
In a nutshell: The dom-based XSS vulnerability is a vulnerability based on Document Object model documents Objeet model,dom).
If the landlord does not understand the relationship of the DOM tree, then the knowledge of Dom XSS is very limited. The
first describes what the DOM is:


. It turns out to be like this (it seems you know a little. Yes, Dom is a tree-like model, and you can write JavaScript code to traverse/get/Modify the corresponding node, object, and value according to the layer-by-layer nodes of the DOM.
Understanding this knowledge point, you will find that Dom XSS is not complex, he is also a reflection type of XSS (2016.3.16 modified, DOMXSS depends on the output location, does not depend on the output environment, so the DOMXSS is both possible to be reflective type, It may also be a storage type), simply to understand because he output points in the DOM, so in the brother's "White hat Talk Web security" is also described in detail. DOM-XSS is triggered by passing the URL to the parameter to control.
2,) after the analysis of DOM-XSS, said that storage-type XSS, in fact, also very good understanding, storage-type XSS, nature is deposited into the database, and then taken out, resulting in XSS.
3,) reflected XSS actually includes DOM-XSS, and the key is still to control the output of the page through the URL (DOM-XSS is similar, because the output location is different, resulting in inconsistent results).
said these 3 kinds of differences, can not just stay in theory, I posted the following three kinds of XSS code demo "All in PHP as an example":
Dom-xss:

<?php
error_reporting (0);
$name = $_get["name"];
? >
<input id= "text" type= "text" value= "<?php echo $name;? > "/>
<div id=" print "></div>
<script type=" Text/javascript ">
var text = document.getElementById ("text"); 
var print = document.getElementById ("print");
print.innerhtml = Text.value; Gets the value of the text, and the output is inside print. This is the main cause of XSS.
</script>

One of the enthusiastic respondents in front said: DOMXSS need to turn off IE XSS filter before triggering. Actually not needed, DOMXSS is can be triggered in each browser, screenshot description (based on the above code):
Chrome:
IE (XSS protected mode turned on):

Storage-Type XSS:

<?php
error_reporting (0);
$name = $_get["name"];
Connect the server
$conn = mysql_connect ("127.0.0.1", "Root", "");
Open database
mysql_select_db ("test", $conn);
Execute SQL
mysql_query ("Set names ' UTF8 '");
$sql _insert = "INSERT into Liuyan (id,content) VALUES (' $id ', ' $name ')";
$result = mysql_query ($sql _insert, $conn);
$sql _select = "SELECT * from Liuyan";
$results = Mysql_fetch_array (mysql_query ($sql _select));
echo $results [content];
? >

The above code is relatively concise, you can see the user-controllable $_get name is directly brought into the database, and then queried and output, directly resulting in XSS. Interested students can do the next test, first through

Http://localhost/2.php?name=%3Cscript%3Ealert (1)%3c/script%3e

Then visit http://localhost/2.php. Can trigger Storage-type XSS:

Step one is to have the XSS code write to the database, and step two is to remove the malicious code from the database and output it on the page.
Reflection Type XSS:

<?php
$name = $_get["name"];
? >
<input type= "text" value= "<?php echo $name?>" >

Results:
Well, took such a long time to explain, actually want to tell the title: Well, it took so long time to explain, actually want to tell the title of the Lord:
On-the-use, storage-type XSS > Dom-xss > Reflective XSS.
Why do you say that? Because the storage-type XSS is the most persistent and more covert, because there is a database, the trigger URL is not with JS or other HTML code. DOM-XSS, ranked second. Why. The above diagram is most intuitive: because it bypasses the filtering of most browsers (the new version of Chrome detects DOMXSS for the script context type). Reflective XSS also has to consider the bypass of various filters according to the browser, ease of use is slightly worse. Note: Both reflective XSS and DOM-XSS need to be added to the URL to trigger the JS code.

You can avoid this by validating and escaping parameters, and if you use a framework, you can use some built-in methods and configurations. If you write a filtering method to filter out some dangerous characters and sensitive information, this method can not only protect against XSS attacks but also protect against CSRF attacks, SQL injection and other security issues. For example:

Value = Value.replaceall ("<", "& lt;"). ReplaceAll (">", "& gt;");  

Value = Value.replaceall ("\ \ (", "& #40;"). ReplaceAll ("\ \)", "& #41;");  

Value = Value.replaceall ("'", "& #39;");  

Value = Value.replaceall ("eval\\ ((. *) \ \)", "");  

Value = Value.replaceall ("[\\\" \\\ '][\\s]*javascript: (. *) [\\\ "\\\ ']", "\" \ "");  

Value = Value.replaceall ("Script", "");