This article has participated in the “Digitalstar Project” and won a creative gift package to challenge creative motivation.
Preface: everybody good, I am east east acridine. The other day I received a notification from the security department about a high risk XSS attack vulnerability.
Our department first identified the source of risk and proposed a solution. The front end part was resolved by me and the emergency repair was on-line.
One: So what is an XSS attack?
People often abbreviate Cross Site Scripting to CSS, but this confuses the abbreviation for Cascading Style Sheets (CSS). For this reason, cross-site scripting attacks have been abbreviated to XSS. A malicious attacker inserts malicious HTML code into a Web page. When the user browses the page, the HTML code embedded in the Web will be executed, so as to achieve the special purpose of the malicious user. It mainly refers to the construction of XSS cross-site vulnerability web pages or looking for non-target computers with cross-site vulnerability web pages. XSS is the most common attack mode of Web security, and ranks the top of web security vulnerabilities in recent years.
Just look at this definition, many students must not understand what it means, I will simulate the XSS attack, students should know what is going on. Before simulating XSS attacks, let’s look at the classification of XSS attacks.
How many types of XSS attacks are there?
① Reflective XSS attacks (non-persistent XSS attacks)
② Storage XSS attack (persistent XSS attack)
③DOM-based XSS attack
Three: Next we will simulate these XSS attacks
The first type: Reflective XSS attack (non-persistent XSS attack)
A reflective XSS attack usually means that the attacker induces the user to visit a URL containing malicious code by a specific means. When the victim clicks on the specially designed link, the malicious code will be executed directly in the browser on the victim’s host. This type of XSS attack usually appears in the search bar of a website, user login interface and other places, and is commonly used to steal client Cookies or phishing.
Here’s an example:
This is a normal click event, when the user clicks, js script is executed, popup warning.
What does that mean, you say, but what if the script looks like this?
When the browser executes this script, it steals the user’s cookie information and sends it to its designated server. What do you think he’ll do next?
Type 2: Stored XSS attack (persistent XSS attack)
The attacker uploads or stores malicious code to the vulnerability server in advance and executes the malicious code whenever the victim browses the page containing the malicious code. This means that anyone who visits the page could execute the malicious script, making stored XSS attacks more harmful. Such attacks usually occur at the interaction places such as website messages, comments, and blog logs. Malicious scripts are stored in the database on the client or server.
Add, delete, modify and search are very common in web management systems. We find a new feature page, take a rich text input field as an example. Enter the following statement, click Save, and view the details.
That’s right, as you might have guessed if it’s the front end, h is the browser tag, and this is passed to the server, and the server returns it to the front end, and when the browser renders, it will render the second line as an H1 tag, and it will look like this, and the second line will be bolded and enlarged.
I’m just typing plain text here, but with the development of the Internet in recent years, there are a lot of H5 multimedia tags, so what if I use them? If you are not sure, you can open the website of W3cschool by yourself:
How do hackers attack us? The hacker will write some scripts to get our cookies and sensitive information, and then send them to his own server. When he gets our information, he can bypass the front end and directly adjust the back end interface, such as the withdrawal interface.
Here I use an online remote site to simulate an XSS attack. The address is as follows:svg.digi.ninja/xss.svg** The website is still accessible at present, students can experience it by themselves. If the link fails to be accessible later, students can find another one, or write a script by themselves, and then upload it to their own server disguised as SVG. Let’s type the above address in the address bar to see what happens, indicating that you have triggered an XSS attack.
When we click OK, a black man appears, ha ha ha, congratulations, your bank card has been hacked all money. This is what happens when a hacker succeeds, and then he taunts you.
Next, we use the multimedia tag and the script to attack our actual site.
Remember to prefix the address with // to indicate a span, as shown in the figure below:
Oh no, the scene of the website just triggered in our web management system, click OK, that little black man is mocking you again.
This script successfully runs in our management system and obtains our sensitive information, so it can directly bypass the front end and directly disable our back-end card withdrawal interface. In addition, such scripts are stored in the server and coexist with some public areas, such as the interaction places of website messages, comments and blog logs. Therefore, stored XSS attacks are more harmful.
The third kind: DOM-based XSS attack
Client-side scripts can examine and modify page content on the fly, independent of server-side data. For example, if the client extracts data from the URL and executes it locally, the application may be subjected to DOM-based XSS attacks if the data entered by the user on the client contains malicious JavaScript scripts that are not properly filtered or sanitized.
Let’s look at an example
This code means that after clicking submit, it renders the contents of the input box to the page. The effect is shown in the following two images.
① Enter the content in the input box
② Click OK to render the content in the input box to the page
So how do we type content is not plain text, but malicious script?
That’s right, malicious scripts are rendered to the page as scripts instead of plain text.
Conclusion: XSS is to use the browser doesn’t recognize it is plain text or malicious code, so we have to do is to prevent malicious code execution, such as front-end submission and rendering, request and return to the backend interface to such special labels do escape and filtering processing, to prevent his execution scripts, leak of sensitive data. Interested students can follow my steps above to simulate an XSS attack, so that they also experience the feeling of being a hacker.