preface

For a shadow killer, there’s always a way to kill. There are also shadow killers on the front end, which can wreak havoc on your site

This article is going to introduce some of the front-end shadow killers — XSS and CSRF. Maybe you hate it. Or maybe you’re doing it right. Hate your guts, probably because your website is suffering from it; Handy, probably because you deal with this kind of problem every day in your job. So we’re here today to understand it and defend against it. If you like my article, welcome to comment, welcome to Star~.

The body of the

Note: Before we start the text, it is important to note that all the experimental environments are locally built – DVWA.

Shadow killers, for a long time, have accompanied the development of almost the entire Internet. The tide of history is always worth studying and pondering. Maybe a decade ago, these problems were cropping up; As developers become more and more aware of security, it is always more or less avoidable. So, let’s take a look at today’s first protagonist — XSS.

The first protagonist — XSS

I remember that when I was in school, I played CTF and dealt with network vulnerabilities like XSS. There were always fixed routines. Today we will also learn about these routines.

An overview of the

The full name for XSS is Cross-Site Scripting. I wonder if you have a question. Foreigners like to abbreviate English, but why XSS? Because I can only blame it for coming late, CSS beat it to ^_^. But that’s okay, that doesn’t stop us from remembering it.

XSS is a code-injection type of attack that allows an attacker to execute malicious scripting code on other people’s computers. Often XSS does not require an attacker to attack the victim’s browser directly. An attacker can take advantage of a vulnerability on the site and submit this piece of malicious code. Then, through the website to pass on to the victim, while stealing the victim’s information.

Let’s start with a simple example:

You may wonder how I can use the bugs in my website, so let’s take a look at a picture:

comment

This is a comment box where we can then type:

comment

You then submit this information, and if the site is not protected (e.g., filtered), the following screen pops up on your page:

xss

Reading this message, you may already be aware of its dangers. Because if you can run js scripts like this, all information about your client (such as cookies) will be stolen.

Getting back to our topic, after seeing the basic effects of XSS, do you think JavaScript is dangerous?

In fact, true JavaScript runs in a strict environment and does no harm to the operating system or other applications. If you don’t believe me, you can go to the console, try anything in it, and you’ll find that you haven’t done any harm. So, is our so-called severity of XSS blown?

That’s even less so. First of all, what is malicious code? Malicious code is so called not because it is inherently harmful, but because it is intended to be harmful to users. We can look at, what is bad for the user? Example:

JavaScript reads the user’s private information (for example, cookies).
JavaScript can send arbitrary information to any server using XMLHttpRequest
JavaScript can modify any DOM element in the current page

These behaviors, if the person is not good, so, will cause immeasurable loss to the user.

Role-playing in XSS

Throughout the XSS process, there are different roles. The cast list can be divided into: website, victim, attacker.

Web sites, usually HTML pages that will be accessed by victims.

Victims are ordinary users who visit websites

The attackers are malicious users who hide in dark corners, tapping away at their keyboards. Typically, the attacker also has a server of its own to receive incoming user information.

The entire flow chart is as follows:

xss-process

Actors are a necessary part of the whole process, otherwise the whole attack would not be completed. Four steps can be seen in the figure:

The attacker selects a site with a vulnerability and inserts malicious code into its database
The user requests the injected web site from the web server
The web server responds to the user’s request and sends the user the modified web site
The user completes the access, while the injected malicious code executes, sending the user’s cookie to the attacker’s server

I encourage you to take a look at this flow chart, as it will also be a prerequisite for our future XSS defense. After that, let’s look at the classification of XSS

classification

The goal of XSS is to execute malicious code in the victim’s browser. There are usually only different ways to achieve this goal, which can be mainly divided into three types: reflective XSS, storage XSS and DOM based XSS.

Reflective XSS: The user’s malicious code string is derived from the victim’s request, for example, a malicious link in an email.
Stored XSS: The user’s malicious code string comes from the site’s database. This is usually the case in our diagram — injecting malicious code into comments for victims to access
Dom-based XSS: The vulnerability of this attack is mainly on the client side, not the server side. Generally relatively rare.

We have already seen this above because of the flowcharts for storage-type XSS. After that, we need to take a look at the flow chart of reflective XSS, as shown in figure:

xss-reflect

As you can see, the process does not insert malicious code into the site’s database, but consists of the following 4 steps:

The attacker passes a website URL to the victim
The victim then clicks on the address and sends a request to the website
The site responds to the original page with malicious code to the user
When the web page is loaded, the user sends a private message to the attacker’s server.

This is often a form of user click.

There is also a KIND of DOM based XSS, which is seldom used and the attack conditions are more demanding. We will not discuss it here.

After we read the classification, the general process of the attack has been mastered.

The next operating platform I recommend is DVWA. At present, there are few XSS vulnerabilities on the Internet, mainly due to the attention of developers, and online operation will lead to certain harm, so it is the best choice to build a local development environment.

Actual operation:

Initially, we need to install DVWA. There are many tutorials online, so you can search for them.

First step, we need to lower the security level of DVWA, because different security levels take different defense measures.

DVWA

The second step is to start the XSS experiment in the XSS REFLECTED.

Step 3: Enter “” in the input box, as shown in the picture:

XSS

Step 4: After submitting, we can see the popup window (here is a reminder to try not to use Chrome, that browser will block these, better use the old version of IE), as shown in the picture:

xss

If you have a backend server, you can send this cookie in the form of a request to the backend server, so I won’t demonstrate it here.

defense

If someone is trying to use these devices to harm the user, then we developers will have a way to deal with it in the process of developing our apps. Do you remember the attack flowchart above? If you forget, go back and have a look. The best defense is to cut off any part of the attack.

First of all, as a developer, you have to agree that all user input is unsafe. Especially injection vulnerabilities like XSS. We can defend against this in two ways — coding and validation.

Encoding: For user input, what is entered is only data, not code.

Verification: Uses regular expressions to check whether user input contains sensitive characters.

Therefore, our solution can be based on the above two points:

Input detection Detects the data entered by the user. The vulnerability to these code injection classes does not trust user-input data in principle. Therefore, we need to filter the user input data to a certain extent, filter out the special characters and keywords in the input data, and limit the length of the input. XSS attacks can be prevented as long as developers rigorously check each input point for detection and XSS filtering of data from each input point.
Output encoding From the previous analysis of the principles of XSS, we know that another cause of XSS is that applications embed user-entered data directly into HTML pages. If we encode the data entered by the user and then embed it in the page, the HTML page will treat the input as normal data.
Cookie security Using XSS attack, we can easily obtain the user’s Cookie information. So we need to do something with the user’s cookie. First of all, we try to reduce the storage of sensitive information in cookies, and try to use hash algorithm to store cookies multiple times. Appropriate use of the cookie’s httponly attribute value. This prevents malicious JS code from calling cookies.
Disable scripts to enable JS security Settings in the browser. Browsers like Chrome block dangerous XSS operations. For example, when you want to read a cookie, the browser blocks the operation, asks the user for instructions, and reminds the user of the dangers of such operations.

That’s as far as XSS is concerned. If you want to dig deeper, read some books on network security, or read other articles for detailed answers. Now we need to introduce our second protagonist — CSRF

The second protagonist — CSRF

Do you remember the name of the first main character? This is called cross-site scripting. The second protagonist has a similar name, Cross-site Request Forgery.