About XSS attack
cross-site scripting attack, when users browse the web, the embedded script code is executed, thus achieving the purpose of attacking users, common vulnerability pages, website search Page, message board.
To understand this article requires html foundation, do not understand html should also be able to understand some!
Table of Contents
Second, the content summary
XSS vulnerability types are mainly divided into three categories: reflective, storage, and DOM.
- Principle of XSS vulnerability
- Reflective mining
- Storage mining
3.1 Vulnerabilities
The main cause of the XSS vulnerability is that the backend receives the parameters without filtering, causing the parameters to change the structure of the HTML, as shown in the following figure.
In the figure, it can be seen that the attacker’s parameters are placed in the HTML code as they are, causing the original structure to be changed. When the code is executed by the browser, the alert event will be executed.
3.2 Reflective type
Reflective XSS is defined in the alarm clock. If the malicious parameters in the URL address are directly output to the page, causing the attack code to be triggered, it is called reflective XSS.
As you can see in the figure, the original is to enter a name, but actually passed a script tag, this tag is also placed in the HTML structure, the code in the script tag code is triggered, indicating the existence of xss vulnerability.
3.3 storage type
Storage XSS, as the name suggests, is that malicious parameters are stored, usually stored in the backend server, so the stored XSS does not contain malicious parameters in the URL address, it is difficult for the victim to find that it has been attacked.
The script code is not seen in the URL, but the attack code is still triggered, indicating that the attack code is from the server, and the attack code is actually passed to the server by the attacker.
Under normal circumstances, when the attacker passes the attack code to the server through the form, it will get the address of a new page. The URL in this address has no obvious exception, such as the following URL address.
But when there is a stored XSS, the victim opens the URL and the attack code will be triggered. In this case, it is called a storage XSS vulnerability.
3.4 DOM type
DOM type XSS is special. The front reflection type XSS and the storage type XSS are all distinguished by propagation mode, while the DOM type XSS has nothing to do with the parameter transfer method, but when the developer has made some security protection, the security problem occurs. a phenomenon.
In the picture, you can see that the parameter name has been escaped using the function. It is reasonable to say that passing the parameter to the front-end page at this time will not generate an XSS vulnerability; but when the JavaScript code performs the DOM node operation on the parameter, it is originally escaped. The code will be restored again, so it will still be triggered.
In the figure, I saw that the XSS code has been triggered. This DOM XSS is relatively more concealed. Therefore, the defense against XSS vulnerabilities cannot rely solely on back-end developers. Front-end developers should also understand XSS vulnerabilities.
4.1 Analysis of ideas
Knowing that the reflection type XSS is propagated through the URL address, then you need to think about the places where the parameters of the URL address will be displayed on the page. I believe that the readers have used the site search of some websites, and the search position in the station will often search. The keywords are displayed on the page.
On the homepage, I also see that this site has a search function, so you can start from the search location, you can enter a simple payload in the search location, refer to the following.
<script>alert(123)</script>
When you click Search, it will automatically jump to the following URL. At this time, the URL of the browser has changed. The URL address is as follows:
Http://permeate.songboy.net/home/search.php?keywords=<script>alert(123)</script>
The search form uses the GET pass parameter, which satisfies the first step of the test reflection type.
The Xiaofeng Tutorial Search page automatically filters the xss code.
4.2 Vulnerability testing
Next, you need to see if the payload is triggered. The result is very unexpected. Not only is it not triggered but also blocked by the browser.
Here we need to explain to the reader, Google kernel browser comes with XSS filter, so for reflective XSS testing, try not to use Google Chrome, it is recommended to use Firefox browser for testing;
4.3 Analysis of results
Now copy the URL above and paste it into the Firefox browser and press Enter to see the effect as shown below.
At this point, the payload has been triggered, indicating that a reflective XSS vulnerability has been found. This vulnerability is relatively primitive. As the browser’s XSS filter becomes more intelligent, this vulnerability is also less and less. Storage content XSS mining and bypassing will be mentioned in the content.
Five, storage mining
Now looking for storage XSS, the storage type of attack code is stored on the server side, so you need to find some places where the form content will be stored on the server. I have already learned about permeate before, so I know that permeate has post and Replies, these functions are where you need to store and display parameters.
5.1 Discovery Vulner
Click on the XSS section on the home page and enter the list of sections.
In the lower right corner, you can see that there is a post button. After clicking the post button, you can enter the post interface.
In the permeate penetration test system, if you want to post a post, you need to have an account. Register an account here, and the registration process will not be explained in detail.
5.2 Verifying Vulnerabilities
After the registration account is completed and logged in, open the posting page again, and fill in the payload at both the title and the content. The reference content is as follows:
<script>alert(123)</script>
Fill in the payload in the title and post content respectively. After filling in, it should be consistent with the following figure.
After filling in the content, click the post button below to post the post. If the post is successful, a prompt will pop up, as shown in the figure below.
After clicking OK, you will be redirected to the posting list and a 123 prompt box will pop up.
If you see this box, the description of the payload has been executed, click OK to see the contents of the list.
Only the title is displayed in the list, so the payload in the post content is not executed;
5.3 Packet capture bypass
Now click on the title to enter the post details page. On the details page, the payload is only triggered once, and the tags in the content are displayed directly.
When the label is directly displayed, the parameters indicated are escaped; the escaping is divided into two types, front-end escaping and back-end escaping. If the back-end escaping is usually abandoned, if it is front-end escaping, Bypassing this limitation; here it is found that the title is not escaping, and the content is transferred, the guess may be the escaping of the front end, so the packet can be copied through the browser’s review tool;
First reopen the posting page, then right-click on a random page -> select review element -> switch to the network tab and check Preserve log, open the network and check the Preserve log to let the post be posted. The record is found in the network request, and now you can fill in the new payload.
After clicking the publish button, you can find the post request in the console. As you can see from the request, this data has been escaping.
5.4 code replacement
When it is determined that there is a front end in this place, the front end is escaping. If the back end does not process it, you can bypass it. Now copy the request and change the data inside.