Cookie browser features: Cookie can achieve cross-page global variables, cookies can be used across multiple pages under the same domain name, but not across multiple domain names.

XSS attack (cross-site scripting attack)

A code injection method called XSS to distinguish it from CSS. Early on, it was common in online forums, where the lack of strict limits on user input lines allowed attackers to upload scripts to posts and let others navigate to pages with malicious scripts. Its injection method is very simple, including but not limited to JavaScript/VBScript/CSS/Flash, etc.

XSS classification

According to the attack sources, XSS attacks can be classified into storage, reflection and DOM attacks.

  • Storage: The location where malicious code is stored;
  • Insertion point: Who gets the malicious code and inserts it into the site.

Storage type

How it works: An attacker submits (stores) malicious code (XSS code) to a server (whether database, memory, or file system) and executes the malicious code when the victim visits a web page containing secondary malicious code.

Attack steps:

  1. The attacker submits malicious code to the target server.
  2. When the user opens the target website, the website server takes out the data containing malicious code, splices it into HTML and returns it to the browser.
  3. The user browser receives the corresponding parsing execution, mixed in the malicious code is also executed;
  4. Malicious code steals user data and sends it to an attacker’s site; Or impersonating the user’s behavior, calling the target website interface to perform the operations specified by the attacker.

Common scenarios: websites with user-saved data, such as forum posts, product reviews, and user messages.

reflective

How it works: Reflective XSS, also known as non-persistent XSS, refers to when a request occurs, the XSS code appears in the request URL and is submitted as a parameter to the server, which parses and responds. The response results contain XSS code, which is parsed and executed by the browser.

Attack steps:

  1. An attacker constructs a special URL that contains malicious code;
  2. When a user opens a URL with malicious code, the web server takes out the malicious code from the URL, splices it into HTML and returns it to the browser.
  3. After the user browser receives the response, it parses and executes the malicious code mixed in it.
  4. Malicious code steals user data and sends it to an attacker’s site; Or impersonating the user’s behavior, calling the target website interface to perform the operations specified by the attacker.

Common scenarios: This function is commonly used for sending parameters through the URL, such as website search and redirect. Because users need to take the initiative to open the malicious URL to take effect, attackers often combine a variety of means to induce users to click.

The DOM model

Principle: Same as above reflection TYPE XSS attack.

Attack steps:

  1. An attacker constructs a special URL that contains malicious code;
  2. The user opens a URL with malicious code;
  3. After the user browser receives the corresponding parsing execution, the front-end JS takes out the malicious code in the URL and executes it.
  4. Malicious code steals user data and sends it to an attacker’s site; Or impersonating the user’s behavior, calling the target website interface to perform the operations specified by the attacker.

Summary of XSS types

  • DOM type fetching and executing malicious code is completed by the browser, which is a security vulnerability of the front-end itself. The other two are server-side security vulnerabilities.
  • Storage type, continuous and effective; The other two are non-persistent.

XSS defenses

There are two elements of an XSS attack:

  • An attacker submits malicious code;
  • The browser executes malicious code.

Common defense measures:

1. Input filtering

Is it possible to filter input from the front end and then submit it to the back end when the user submits?

The answer is no. Once the attacker bypasses the front-end filtering and constructs the request directly, the malicious code can be submitted.

Is it possible for the back-end to filter before writing to the database and then return safe content to the front end?

The answer is no. Because, although before writing database input filter can filter out some of the content, but the user usage scenario is very complex, it is hard to determine where content can output, once the content of the user input after transcoding, the client will need to be reversed yards, and the front needed by different location coding are also different. Therefore, input-side filtering can solve XSS problems in some cases, but it will introduce great uncertainty and garble problems, so it should be avoided as much as possible.

Of course, input filtering is necessary for explicit input types such as numbers, urls, phone numbers, email addresses, and so on.

2. Prevent malicious code execution

In both stored and reflective XSS, malicious code is taken out by the server and inserted into the response HTML. Data that can be written by the attacker is embedded in the code and executed by the browser.

There are two common ways to prevent these vulnerabilities:

  • To the pureThe front-end renderingTo separate code from data;
  • Be thorough with HTMLescape.

Front-end rendering: Mainstream frameworks use SPA, where we explicitly tell the browser what to set next:.innertext,.setAttribute,.style, etc. Browsers can’t easily be tricked into executing code outside of them.

However, for pages with high performance requirements or seo requirements, you still face the problem of concatenated HTML.

Escape: If concatenating HTML is necessary, you need to adequately escape the insertion points of the HTML template with appropriate escape libraries. Common template engines such as EJS usually have only one rule for HTML escape, which is to escape the characters & < > “‘ /. It can play a certain protective role, but it is not perfect.

3. Reject dangerous input (for DOM TYPE XSS attacks)

4. Other XSS preventive measures

  1. Input length control

A reasonable length should be set for untrusted input. While you can’t completely prevent XSS, you can make XSS attacks more difficult.

  1. HttpOnly

Setting HttpOnly to sensitive cookies prevents JavaScript from accessing this information and prevents attackers from stealing sensitive information after completing XSS attacks.

  1. Content Security Policy (CSP)

CSP can play the following roles in XSS prevention:

  • Prohibit loading outfield code to prevent complex attack logic;
  • Prohibit outdomain submission. After a website is attacked, user data will not be leaked to the outdomain.
  • Disable inline script execution;
  • Prohibit unauthorized script execution.
  • Proper use of reports can discover XSS in a timely manner, which helps to rectify problems as soon as possible.

You can enable content security policies in the following two ways:

  • In the HTTP HeaderContent-Security-Policy
  • <meta http-equiv="Content-Security-Policy"

CSRF attack (Cross-site request forgery)

Cross-site Request Forgery (CSRF) : An attacker induces the victim to access a third-party website and sends cross-site request to the attacked website. Using the victim in the attacked website has obtained the registration certificate, bypassing the background user authentication, to impersonate the user to perform a certain operation on the attacked website.

CSRF attack flow

  1. The victim logs in to website A and retains the login credentials (cookies);
  2. The attacker induces the victim to visit the dangerous website B;
  3. Dangerous website B sends A normal request to website A, and the browser will carry the cookie stored under Website A by default.
  4. After receiving the request, website A verifies the request and confirms that it is the victim’s credential, mistakenly thinking that it is the request sent by the victim himself.
  5. Site A performs the action requested in the hazard request on behalf of the victim.

CSRF classification

CSRF of the GET type

The implementation of GET CSRF is very simple. It only needs a common HTTP request, which is usually stored in resources such as images. After the victim opens a dangerous website, the image of the dangerous website will send a dangerous GET request, thus completing a GET CSRF attack.

CSRF of the POST type

This approach typically uses an auto-submitted form. When the page is accessed, the form is submitted automatically, simulating that the user has completed a POST. POST attacks are usually a little more rigorous than GET attacks, but they are still not complex, so the back-end interface cannot rely on security to allow ONLY POST.

CSRF of link type

This method is not common. The implementation idea is the same as the GET type, but the user needs to manually click to trigger, so the attacker usually induces the user in the form of advertising.

CSRF defense:

CSRF has two characteristics:

  • Occur in theThe third partyThe domain name.
  • An attacker cannot obtain cookie information,Can only use.

Common defense measures:

1. Homology detection

Since most CSRFS occur on third party sites, we simply disallow requests from outlands to us:

  • Use the Origin Header to determine the source domain name: In some CSRF-related requests, the request Header is not carriedOriginField, which can be used to determine the source domain name if the Origin field exists;
  • Use the Referer Header to identify the source domain name: according to the HTTP protocol, there is one in the Header of the requestRefererField that records the source address of the request.

2.CSRF Token

Another feature of CSRF is that an attacker cannot steal the user’s information directly, but only impersonates it. CSRF works because the server mistook the request sent by the attacker for the user’s own request. We can then require that all user requests carry a Token that CSRF cannot obtain, and the server determines whether the Token is correct, thus distinguishing the normal request from the attack request.

Implementation steps:

  1. Outputs the CSRF Token to the page;
  2. Page submitted requests carry this Token;
  3. The server verifies that the Token is correct.

3. Double Cookie authentication

The principle is similar to Token. When requesting an interface, a cookie is attached to the request parameters. When receiving the request, the server compares the cookie in the parameters with the value in the cookie to determine whether the request is an attack request.

4. Samesite Cookie properties

Google has drafted a draft to improve the HTTP protocol by adding the Samesite attribute to the set-cookie response header, which is used to indicate that the Cookie is a “peer Cookie”. A peer Cookie can only be used as a first-party Cookie, not a third-party Cookie. Samesite has two property values:

  • Samesite=Strict: This is called Strict mode, indicating that this Cookie cannot be used as a third-party Cookie under any circumstances
  • Samesite=Lax: This is called loose mode and is stricter than Strict. If the request is this kind of request and also a GET request, the Cookie can be used as a third-party Cookie.

Summary in plain English: Generally speaking, XSS attacks focus on code injection, or stealing cookies and other information to launch attacks; CSRF focuses on the login status of the stolen user, because it cannot be obtained directly, only stolen.

(If you don’t understand the following points, you can check the browser features of cookies.)