The scope of front-end security

Web security problems are classified according to the regions where they occur. Security problems in browsers and Web pages are front-end security problems.

The same-origin policy

Same-origin: A URL consists of the protocol, domain name, port, and path. If the protocol, domain name, and port of two urls are the same, they are of the same origin.

The browser’s same-origin policy restricts documents or scripts from different sources from reading or setting certain properties on the current document. Scripts loaded from one domain do not allow access to document properties in another domain.

If there is no same-origin restriction, cookies and other data in the browser can be read arbitrarily, DOM in different fields can be manipulated arbitrarily, and Ajax can be requested arbitrarily. If you visit a malicious web site, you can leak this private data

In browsers, tags such as

Each time these SRC tags are loaded, the browser actually makes a GET request. Unlike XMLHttpRequest, browsers limit JavaScript’s permissions to read and write returned content from resources loaded through the SRC attribute.

Cross-site scripting (XSS)

XSS, or Cross Site Script; To distinguish it from Cascading Style Sheets, it is called XSS in the security world.

XSS attack refers to an attack in which an attacker injects malicious client code into a website and uses malicious scripts to tamper with the client’s web page so as to control the browser or obtain the privacy data of users when they browse the web page. There are many ways to carry out XSS attacks, but they all have in common: sending private data such as cookies and sessions to the attacker, redirecting the victim to a website controlled by the attacker, and performing malicious operations on the victim’s machine.

attacks

Reflective XSS

The malicious code is not stored on the target website, and the attack is carried out by enticing users to click on a malicious link to the target website.

Attack flow:

  1. A sends B A maliciously constructed URL
  2. B Click the URL to go to the HTML page with the vulnerability
  3. The HTML page executes JavaScript in browser B and can execute commands with the permission of USER B

Type stored XSS

Malicious codes are stored in the server of the target website. Such attacks have strong stability and persistence. The common scenarios are blogs, forums, OA, CRM and other social networking sites.

Attack flow:

  1. The attacker submits a message or other data containing XSS code to the database
  2. When the target user queries, the XSS content is parsed from the server and loaded
  3. The browser parses and executes malicious codes as normal scripts and can execute commands authorized by the browser

DOM Based XSS

Dom-based XSS attacks are client-side attacks that modify the DOM structure of a page through malicious scripts. DOM TYPE XSS attack, taking out and executing malicious code is completed by the browser side, which belongs to the security vulnerability of front-end JavaScript itself.

Attack flow:

  1. A sends B A maliciously constructed URL
  2. B Click on the HTML page after the URL to obtain the offensive code, such as passlocation.hashParameters, etc
  3. Offensive code is written to the page as HTML code
  4. The HTML page executes JavaScript in browser B and can execute commands with the permission of USER B

Precautions,

  • Input inspection

    In the source control, the user input some illegal things are filtered or coded out, so as to ensure security. For example, remove the DOM attribute submitted by the useronerror, remove the node uploaded by the user,<iframe>.<script>.<a>Node, etc.

    In common services, input checks are performed on both the client and server.
  • Output checking uses escape libraries to fully escape nodes throughout the HTML template.
  • useHttpOnly

    By setting theHttpOnlyThe browser can disable JavaScript access to pages withHttpOnlyProperties of theCookie. Its purpose is not to counter XSS, but to counter XSSCookieHijack attacks.

Cookie usage process: \

  1. The browser makes a request to the server without Cookie\
  2. The server returns the set-cookie header and writes Cookie\ to the browser
  3. The Cookie will be sent when the browser visits all pages in the domain before the Cookie expires

HttpOnly is marked at set-cookie time

The Set - cookies:  <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]Copy the code

  • Input Length Limit A proper length of the input content increases the difficulty of XSS attacks

  • Avoid using concatenated HTML or inline events. It is dangerous to use concatenated HTML or inline events on the front end. You are advised to use createElement, setAttribute, and addEventListener instead, or use a mature framework for rendering, such as Vue/React

  • Enable CSP Content Security Policy A developer-defined Security Policy statement that specifies trusted sources of Content (remote resources such as scripts, images, styles, etc.) through the responsibilities imposed by the CSP. The essence of CSP is whitelisting. The developer clearly tells the client which external resources can be loaded and executed, which is equivalent to providing a whitelist. Open mode: \

    • Through HTTP headersContent-Security-Policyfield
    • Set in the web page<meta>The label
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
Copy the code

Cross-site Request Forgery (CSRF)

The principle of cross-site request forgery attack is that the attacker constructs a back-end request address and induces the user to click or initiate the request automatically through some means. Using the victim in the attacked website has obtained the registration credentials, bypassing the background user authentication, posing as a user to perform some operations.

Attack process

  1. The victim logs in to site A and retains the login credentials
  2. The attacker induces the attacked to visit site B
  3. Site B sends A request to site A, and the browser carries the Cookie of site A by default
  4. After receiving the request, site A authenticates it, misperceives it as A request initiated by the attacked, and performs the corresponding operation as the attacked

attacks

  • GET the type

    Usually by using<img>Tag, etc.



    When an attacker accesses a page, the browser automatically sends a message to the attackersrcMakes a request to the address pointed to
  • The POST type usually constructs an auto-submitted form on the page, simulating that the user has completed a POST operation
  • Link types are usually triggered by tricking the user into clicking

Attack characteristics

  • Attacks usually occur on third-party sites, and the attacked sites cannot prevent attacks
  • The attack means submitting operations as a victim rather than stealing data directly
  • During the attack, the attacker can not obtain the login credentials of users, but only impersonate them

Precautions,

  • Verification code The verification method of website A, such as the graphic verification code or SMS verification code, is added. Only the request that passes the verification is valid. However, this scheme has two limitations, one is to increase the development cost, the other is to reduce the user experience.
  • validationReferer

    According to the HTTP protocol, there is a field in the HTTP header calledReferer, which records the source address of the HTTP request. Through the verificationReferer, you can check whether the request is from a valid “source”.
  • validationToken

    The server generates the token randomly and stores it in the server session and the client. When the client sends a request, it carries the token to the HTTP request header or parameter. The server receives the request and verifies whether the token in the request is consistent with that in the session. If there is no token in the request or the token content is incorrect, the request may be rejected as a CSRF attack.

Click on the hijacked

A transparent iframe (opacity: 0) is hidden under a Web page, and an outer fake page is used to induce users to click. In fact, click events are triggered on the hidden frame to perform some operations that users are unaware of.

Attack process

  1. The attacker constructs a click-inducing content and places the page in<iframe>
  2. usingz-indexandopacitywill<iframe>Overlay over the actual page and make it transparent
  3. When a victim visits a spoof page, what he or she actually sees is the click-inducing content, and then the harmful page

attacks

  • Steal users’ funds
  • Access to sensitive user information
  • Cooperate with XSS or CSRF to trick users into clicking malicious links

Precautions,

  • Set up theX-FRAME-OPTIONS

    HTTP headers can be set on the server sideX - Frame - Options: DENYTo make the browser actively disable<iframe>Embedded, but this method needs to be combined with HTTPS to achieve, because HTTP is not reliable, easy to eavesdrop and tamper with content