With the rapid development of the Internet, information security has become one of the most concerned focus of enterprises, and the front end is the high-risk stronghold of enterprise security problems. Recently, common front-end security problems and corresponding solutions have been sorted out, hoping to help you prevent and repair security vulnerabilities in daily development.

XSS, Cross Site Scripting

XSS attack refers to cross-site scripting attack, which is a code injection attack. Attackers inject malicious scripts into websites to run on users’ browsers so as to steal users’ information such as cookies. The essence of XSS is that the site does not filter malicious code, mixing it with normal code, and the browser does not have a way to tell which scripts are trusted, leading to the execution of malicious code.

XSS attack type

XSS is generally classified as storage, reflection, and DOM.

Storage type

Stored code refers to malicious code submitted to the website’s database. When the user requests data, the server splices it into HTML and returns it to the user, resulting in the execution of malicious code. For example, enter in the input, textarea and other areas where text information can be input. After submission, the information will be stored in the server. When the user opens the website again and requests the corresponding data, the page will be opened. Malicious scripts upload user data, such as Cookie information, to the hacker’s server.

reflective

Reflective is when an attacker builds a special URL, and when the server receives the request, it takes the data from the URL, concatenates it into HTML and returns it, leading to the execution of malicious code. In real life, hackers often induce users to click on these malicious links through QQ groups or emails, so we must be very careful about some links. Note: Web servers do not store malicious scripts for reflective XSS attacks, which is different from stored XSS attacks.

The DOM model

Dom-type refers to the fact that an attacker constructs a special URL. After the user opens the website, the JS script obtains data from the URL, resulting in the execution of malicious code. Dom-based XSS attacks do not involve the page Web server. It is characterized by modifying the data of a Web page during the transfer of Web resources or during the user’s use of the page. For example, use tools such as Burpsuite to scan all pages of the target site and automatically test written injection scripts.

XSS attack defense method

XSS attacks can be prevented from two aspects, one is when malicious code is submitted, and one is when the browser executes malicious code.

For the first aspect, the data of database if we are to escape, but a data may be used in multiple places, some places may not need to escape, because we have no way to judge the data last usage scenarios, so directly in the input for the processing of malicious code, is actually not very reliable.

So we can prevent this from being implemented in the browser. One way is to use a pure front-end approach, without server-side splicing back. The other is to do a good job of escaping code that needs to be inserted into HTML. For DOM type attacks, mainly caused by the unreliable front-end scripts, we should judge the possible malicious code for data acquisition rendering and string splicing.

Specific measures are as follows:

  1. Front and back end filter sensitive characters: for example&,<,>,",',/Characters such as
  2. Sensitive information such as cookies uses Httponly, making it impossible for scripts to obtain document. Cookie
  3. In the use of.innerHTML,.outerHTML,document.write()Be very careful
  4. useCSP, namely, content security policy. The essence of a CSP is to create a whitelist that tells the browser which external resources can be loaded and executed, thus preventing injection attacks by malicious code
  5. Use captcha to prevent scripts from masquerading as users.

CSRF, Cross-site Request Forgery

A CSRF attack refers to a cross-site request forgery attack in which an attacker induces a user to a third-party website that then sends a cross-site request to the site being attacked. If a user saves the login status in the attacked website, the attacker can use this login status to bypass the background user authentication and impersonate the user to perform some operations to the server.

There are three requirements for launching a CSRF attack:

  1. The target site must have CSRF vulnerabilities
  2. The user must have logged in to the target site and remain logged in to that site on the browser
  3. Requires the user to open a third party site, such as a hacker’s site, etc

CSRF attack type

  1. A GET type of CSRF attack, such as building a request in an IMG tag on a website, will automatically initiate a submission when the user opens the site.
  2. POST type CSRF attacks, such as building a form, hiding it, and submitting the form automatically when the user enters the page.
  3. Link type CSRF attacks, such as building a request in the href attribute of the A tag and inducing the user to click.

CSRF attack defense method

Homologous detection

The server filters the request based on the origin or referer information in the HTTP request header to determine whether the request is an accessible site. When the origin or referer information does not exist, directly block. The downside of this approach is that referers can be forged in some cases. There is also our method at the same time the search engine link also to shield, so the general website will allow the search engine page request, but the corresponding page request this request way may also be used by the attacker.

CSRF Token is used for authentication

The server returns a random Token to the user, and when the web site makes a request again, it adds the Token returned by the server to the request parameters, and the server verifies this Token. This method solves the problem that cookies may be used fraudulously when the single authentication method is used. However, one disadvantage of this method is that we need to add this token to all requests on the website, which makes the operation cumbersome. Another problem is that there is usually not only one web server. If our request is load balanced and transferred to another server, but this server’s session does not retain this token, there is no way to verify. This situation can be resolved by changing the way tokens are constructed.

Use dual Cookie authentication

When the user visits the website page, the server injects a Cookie into the requested domain name, the content is a random string, and then when the user sends the request to the server again, it takes the string from the Cookie and adds it to the URL parameter. The server then validates by comparing the data in the cookie to the data in the parameter. This approach takes advantage of the fact that the attacker can only use cookies, but cannot access and obtain cookies. And this method is more convenient than the CSRF Token method, and does not involve the problem of distributed access. The downside of this approach is that it will not work if the site has XSS vulnerabilities. At the same time, this method cannot achieve the isolation of subdomain names.

Set the Samesite property

Set Samesite when setting the cookie property to prevent cookies from being used by third parties and attackers. Samesite has two modes: strict mode, in which cookies cannot be used as third-party cookies under any circumstances, and loose mode, in which cookies can be used for GET requests and page hops.

SQL injection

SQL injection is a common Web security vulnerability that allows an attacker to access or modify data or exploit potential database vulnerabilities. Splicing SQL without careful filtering, hackers can submit malformed data to change semantics. For example, check a certain article, submit such data id=-1 or 1=1 etc. 1=1 is always true, causing the WHERE statement to always be true. Then the result of the query is equivalent to the contents of the entire table, and the attacker has achieved his goal. Alternatively, you can infer SQL statements from the error prompt on the screen.

Prerequisites for SQL injection

  1. You can control the input data
  2. The code to be executed by the server concatenates the controlled data.

SQL injection prevention methods

  1. Disallow target websites from accessing the database by dynamically concatenating strings
  2. Reduce unnecessary database error messages
  3. Give strict permission control to database operations
  4. Purify and filter out unnecessary SQL reserved words, such as where, OR, exec, etc

Click on the hijacked

Clickjacking is an attack of visual deception. The attacker embedded the website to be attacked in its own web page by nesting iframe, and set iframe as transparent, revealing a button in the page to induce users to click.

For example, after logging in the system of website A, the user is tempted to open the third-party website by the attacker, and the third-party website introduces the page content of website A through iframe. When the user clicks A button (decorated button) in the third-party website, it actually clicks the button of website A.

Click on the hijacking prevention method

  1. The server adds the X-frame-options response header. This HTTP response header is used to defend against clickjacking attacks nested with iframe. This prevents the browser from rendering the embedded web page

  2. JS Checks whether the domain name of the top-level viewport is the same as the domain name on the page. If the domain name is not the same, the operation is not allowed. Top.location. hostname === self.location.hostname

  3. Sensitive operations use more complex steps (captcha, enter the project name to delete)

The resources

  • Six common Web security attacks and defenses are analyzed

  • Web Security Summary