What is an XSS attack?

XSS stands for Cross Site Scripting, so it is called XSS to differentiate it from CSS. An XSS attack is the execution of malicious scripts (whether cross-domain or co-domain) in a browser to retrieve user information and perform operations.

These operations generally do the following:

  1. To stealCookie.
  2. Monitor user behavior, such as entering the account password and sending it directly to the hacker server.
  3. Modify DOM forgery login form.
  4. Generate floating window ads in the page.

Typically, XSS attacks are implemented in three ways — storage, reflection, and documentation. The principle is relatively simple, first to introduce one by one.

Storage type

Stored, as the name implies, stores malicious scripts. Indeed, stored XSS stores the scripts in the server’s database, and then executes the scripts on the client side to achieve the effect of attack.

The common scenario is to submit a script code in the comment area. If the back and forth end has not done a good job of escaping, the comment content is stored in the database and executed directly in the page rendering process. It is equivalent to executing a section of JS code with unknown logic, which is very scary. This is a stored XSS attack.

reflective

Reflective XSS refers to malicious scripts as part of a network request.

For example, if I type:

http://sanyuan.com?q=<script>alert(" You're screwed ")</script>Copy the code

This option, on the server side, takes the q argument and sends it back to the browser, which parses it as part of the HTML, discovers it’s a script, executes it, and is attacked.

It is called reflective because malicious scripts are parsed through the server as parameters to a network request and then reflected back into an HTML document. Unlike the stored type, the server does not store these malicious scripts.

The document type

Document-type XSS attacks do not go through the server side, but act as a middleman, hijacking network packets during data transfer and modifying the HTML document inside!

Such hijackings include WIFI router hijackings or local malware.

Measures to prevent

Understanding how the three XSS attacks work, we can see one thing in common: they all allow malicious scripts to be executed directly in the browser.

The way to prevent it, then, is to avoid the execution of these scripts.

In order to accomplish this, one belief and two uses must be achieved.

A belief

Never trust any user input!

Both on the front-end and server side, user input should be transcoded or filtered.

Such as:

<script>alert(' You're screwed ')</script>Copy the code

After transcoding, it becomes:

&lt; script&gt; alert(&#39; You're screwed. &lt; /script&gt;Copy the code

Such code cannot be executed during HTML parsing.

Of course, you can also use keyword filtering to delete script tags. So now all that remains is:

Copy the code

Nothing 🙂

Using the CSP

CSP is a content security policy in the browser. The core idea of CSP is that the server decides which resources the browser loads. Specifically, it can accomplish the following functions:

  1. Restrict resource loading in other domains.
  2. Disallow data submission to other domains.
  3. Provide a reporting mechanism to help us detect XSS attacks in a timely manner.

Using the HttpOnly

Many XSS attack scripts are used to steal cookies, and after setting the HttpOnly attribute of cookies, JavaScript cannot read the value of cookies. This is also a good defense against XSS attacks.

conclusion

An XSS attack is a malicious script executed in a browser and then executed with user information. It is mainly divided into storage, reflection and document. Preventive measures include:

  • One belief: Don’t trust user input, transcode or filter input to make it unexecutable.
  • Two uses: using CSP, using the HttpOnly attribute of Cookie.

What is a CSRF attack?

Cross-site Request Forgery (CSRF) refers to a situation in which a hacker induces a user to click on a link to open the hacker’s website, and then the hacker initiates a cross-site request using the user’s current login status.

For example, if you click on a picture of a little sister carefully selected by a hacker in a forum, you click and enter a new page.

So congratulations, attacked 🙂

You might be wondering, how could you suddenly be attacked? Let’s take a look at what hackers are doing behind the scenes when you click on a link.

You might do three things. The list is as follows:

1. Automatically send GET requests

A hacker’s web page might contain a code like this:

<img src="https://xxx.com/info?user=hhh&count=100" />
Copy the code

When you enter the page, you automatically send a get request. Note that this request is automatically accompanied by a cookie information about xxx.com (this assumes that you are already logged in to xxx.com).

If the server does not have the corresponding authentication mechanism, it may think that the user sending the request is a normal user, because it carries the corresponding cookie, and then carries out the corresponding various operations, such as transfer of money and other malicious operations.

2. Automatically sends a POST request

The hacker could have filled out a form and written an auto-submission script.

<form id='hacker-form' action="https://xxx.com/info" method="POST"> <input type="hidden" name="user" value="hhh" /> <input type="hidden" name="count" value="100" /> </form> <script>document.getElementById('hacker-form').submit(); </script>Copy the code

It will also carry the corresponding user cookie information, so that the server mistakenly thinks that it is a normal user in the operation, so that all kinds of malicious operations become possible.

3. Induced click to send GET request

On a hacker’s website, a link may be posted that urges you to click:

<a href="https://xxx/info? User =hhh&count=100" count= "_blank">Copy the code

Click and automatically send a GET request.

This is how CSRF attacks work. Compared with XSS attack, CSRF attack does not need to inject malicious code into THE HTML document of the user’s current page, but jump to a new page, and simulate the user’s operation by taking advantage of the authentication vulnerability of the server and the user’s previous login status.

Measures to prevent

1. Take advantage of the SameSite property of the Cookie

An important part of a CSRF attack is to automatically send a Cookie under the target site, and then this Cookie simulates the user’s identity. Therefore, Posting on cookies is the best defense.

As it happens, there is one key field in cookies that places some restrictions on how cookies can be carried in requests: SameSite.

SameSite can be set to three values, Strict, Lax, and None.

A. In Strict mode, the browser completely forbids third-party requests to carry cookies. For example, sanyuan.com can only carry cookies in the domain name of Sanyuan.com, but not in other websites.

B. In Lax mode, the Cookie can only be carried if the GET method submits a form condition or the A tag sends a GET request.

C. In None mode, which is the default mode, requests automatically carry cookies.

2. Verify the source site

This requires two fields in the request header: Origin and Referer.

Origin contains only domain name information, while Referer contains the specific URL path.

Of course, both of these can be forged by customizing the request headers in Ajax, which is less secure.

3. CSRF Token

Django is a backend framework for Python. If you’ve developed with Django, you’ll know that its template is often accompanied by a line of code like this:

{% csrf_token %}
Copy the code

This is a typical application of the CSRF Token. So how does it work?

First, when the browser sends a request to the server, the server generates a string and implants it into the returned page.

Then the browser, if it wants to send a request, must carry the string, and the server verifies that it is valid and does not respond if it is not. This string is known as a CSRF Token, which is usually not available to third-party sites and is therefore rejected by the server.

conclusion

Cross-site Request Forgery (CSRF) refers to a situation in which a hacker induces a user to click on a link to open the hacker’s website, and then the hacker initiates a cross-site request using the user’s current login status.

CSRF attacks are generally carried out in three ways:

  • Automatic GET request
  • Automatic POST request
  • Induced clicks send GET requests.

Precautions: Use the SameSite attribute of the Cookie, verify the source site, and CSRF Token.