The Internet about XSS attack related introduction and response measures have been said to be bad, but I have always seen and forgotten, here I try to use my own understanding to review the relevant knowledge of XSS attack again, also convenient next time review ~

The same origin policy of browsers is like a balance, where the freedom of resources and the security of users are the two ends of the balance, and how to balance the two becomes a task that every developer must face. Strict compliance with the same origin policy ensures security but simplifies resource acquisition operations. The application of CORS technology to obtain flexibility of resource acquisition also brings security vulnerabilities: XSS attack is a typical example.

What is XSS defined

XSS stands for Cross Site Scripting. As the name implies, the attack is carried out through malicious scripts. The attacker implants a piece of malicious code in the web page that the user browses, which is automatically executed when loading, and attacks the user. Browsers treat script segments in HTML or DOM the same, so there’s no way to tell which code is needed and which is malicious.

XSS was originally implemented across domains. Today, “cross-site injection” is not the only way, but the name XSS is still used because it is essentially the same.

What is the purpose of the XSS attack

XSS can do several things:

  1. Get user’s cookie:

    The malicious code can directly use document.cookie to retrieve the cookie of the user browsing the current page, and then send the information to the attacker via XMLHttpRequest or Fetch. The attacker can then masquerade as a user on his own end and operate privately.

  2. Monitor user behavior:

    An attacker can register a global addEventListener to listen to user behavior, and the user’s actions will be reported back to the attacker exactly.

  3. Modify the DOM:

    Malicious code can generate DOM. If the login page happens to be injected, the operation of the malicious script overwrites the original one using a fake login interface, so that the user’s account and password will be directly submitted to the attacker through the fake DOM.

  4. Modify the DOM extension:

    Replacing the DOM also allows you to replace the entire page you’re browsing with an AD page, etc.

In short, XSS is an attack launched by an attacker in order to manipulate a web page arbitrarily.

What are the ways XSS can launch attacks

Type stored XSS

Stored XSS is to directly store malicious code in the database, when the user requests the web page is to get the page containing malicious code. In the page loading stage, it will be accompanied by the execution of this part of the malicious code, it is impossible to guard against.

Reflective XSS

Reflective XSS puts malicious code in the request, and the back end does not use this information and returns it to the page as is.

Page processing that inserts malicious code directly into the DOM using innerHTML triggers a reflective XSS attack.

Take a look at an example:

<! DOCTYPEhtml>
<html>
<head>
  <title>Reflective XSS</title>
  <link rel='stylesheet' href='/stylesheets/style.css' />
</head>
<body>
  <h1>xss</h1>
  <div>
      {{ xss }}
  </div>
</body>
</html>
<! Get request, return the requested data as it is
Copy the code

Send a request http://localhost:8888/?

XSS

123

Let’s do something, send a request http://localhost:8888/? XSS =, and then something amazing happens: the page will alert a message saying ‘Under attack! ‘popover.

The XSS attack I encountered for the first time in my work was a reflection attack. I dealt with it by filtering dangerous fields with re when sending requests, and the details were moved.

DOM based XSS

In this form of XSS attack, the attacker hijacks the data transfer phase to inject malicious code into HTML. There are many ways of hijacking, such as WiFi hijacking, malicious plug-in hijacking and so on.

How does XSS protect against it

XSS is by nature a malicious script, so XSS defenses are also against malicious scripts, and developers can prevent the vast majority of XSS attacks by filtering malicious scripts where possible.

Script filtering

Script filtering is to filter out malicious code, such as links in reflective XSS. I take the approach of banning all requests with suspicious scripts.

Another option is to transcode malicious code, again using the example in reflective XSS

? XSS =<script>alert(' Attacked! ')</script> // transcode to the following? xss=&lt; script&gt; alert(&#39; You've been attacked by XSS. &lt; /script&gt;Copy the code

CSP

This precaution needs to be defined, and when you know what a CSP is and what it does, you can understand why a CSP can also protect against XSS attacks.

So let’s first talk about what CSP is. CSP lets the server decide what resources the browser can load and whether the browser can execute inline JavaScript code.

CSP functions:

  1. Restrict the loading of JavaScript and other resource files in other domains
  2. Disallow data submission to other domains
  3. Do not execute inline scripts or unauthorized scripts
  4. Provide reporting mechanism

Utilize the HttpOnly attribute

The HttpOnly attribute is provided by the browser to protect the user’s Cookie. If HttpOnly is set in the response header that returns Cookie data, the Cookie cannot be read by document. Cookie and can only be automatically appended to the request header when the request is sent

Since most XSS attacks are aimed at obtaining user cookies to disguise the user’s identity, this approach also provides some protection against XSS attacks.

The above content is my personal understanding after reading many XSS blogs, if there is any error welcome to correct ~