Discussion on Web Security

The authors introduce

Qi Wang, a member of the proprietary Dingding front-end team, is responsible for the end-to-end application, modular application and small program development of the proprietary Dingding PC client.

background

Some time ago, a piece of information about SonarQube and vue. js being used by overseas hackers to detect network attacks on important Chinese enterprises appeared on the Internet. Then yuxi yu, the author of Vue.js, made a relevant response after learning about this news — about the recent bug notification involving SonarQube and Vue; So today I want to talk to you briefly about front-end Web security.

Security has always been a long time and appears in all aspects of the problem, for example, the gentry for the security of money, will make all kinds of complex safe to prevent theft, for their own safety, will hire armed personnel to protect themselves; Similarly, after the emergence of the Internet, the security problems of the Internet are gradually exposed. Web, as one of the representatives of Internet prosperity, is also one of the focuses of attack.

Browser Same-origin Policy

The same origin policy is an important security policy that restricts how an Origin document or the scripts it loads can interact with resources from another source. It can help block malicious documents and reduce the number of vectors that can be attacked. It can be said that the same origin policy avoids most security problems to a certain extent.

The table below gives the with URL store.company.com/dir/page.ht… Examples of sources for comparison:

Let’s take a look at common Web vulnerability attacks.

1. SQL injection

SQL injection attack is one of the common methods used by hackers to attack databases. With the development of B/S pattern application development, more and more programmers use this pattern to write applications. However, due to the uneven level and experience of programmers, some programmers do not judge the validity of user input data when writing code, which makes the application exist security risks. SQL Injection a user can submit a database query code and obtain certain data he/she wants to know based on the result returned by the program.

SQL syntax

SELECT * from (SELECT * from (SELECT * from (SELECT * from (SELECT * from)) where (SELECT * from (SELECT * from)) The section after the # hash is commented with the syntax that # SQL injection may use 1 = 1 # SQL operator # and/orCopy the code

attack

Take login as an example. Currently, there are account systems in common background Web systems. If you do not have a correct account and password, you cannot log in to the system, which ensures the basic security of the system.

As shown in the above, after we enter account and password, the front-end data will be submitted to the server, the server based on the account and password query the database, the database returns the query results, the server-side processing results after success or failure to return to the login information, finally the front-end processing response from the server as a result, the login system or errors.

In the above process, we can find that the core of the login account is the database, and SQL is a database-oriented syntax, and partly depends on the input of the front end, that is to say, we can control THE SQL statement to a certain extent (PS: the backend design of this paper is developed to support SQL injection attack);

function signIn(username, password) {
  const sql = `select * from users where username='${username}' and password=${password}`
  
	Mysql.query(sql);
}
Copy the code

Under normal circumstances, the server based on the correct account and password to spell out the SQL execution, must be able to query the existing data, so that the successful login; Otherwise, you cannot log in with an incorrect account password. However, if the site is vulnerable to SQL injection attacks, you can log in without knowing your account number as long as you enter some special characters.

We can complete the login by entering the following information in the login box of the page without requiring the correct account and password:

Username: 'or 1=1# password: aaaaaaaCopy the code

prevent

At present, the risk of SQL injection attack is not too high, the database server has good preventive measures; From the front end, you can do some error prevention if you need to; For example, check invalid characters.

2. Cross-sitescripting (XSS cross-site scripting attack)

XSS attack usually refers to the use of the vulnerabilities left in the development of the web page, through a clever way to inject malicious command code into the web page, the user load and execute the malicious web program made by the attacker. These malicious web programs are usually JavaScript, but can actually include Java, VBScript, ActiveX, Flash, or even plain HTML. After a successful attack, the attacker may gain various contents including but not limited to higher permissions (such as performing some operations), private web content, sessions and cookies

Type stored XSS

The attacker submits malicious code to the server via a text box, and when the server issues the data to other users, the malicious code executes in the browser to cause damage.

<img SRC ="xss.png" onerror="alert(' XSS ')" /Copy the code

Precautions: Escape the HMTL/Script code and submit it to the server.

Reflective XSS

Data submitted to the server on the Web is immediately used to parse and display the user’s results page, such as a shared link, to induce the user to click through to retrieve the user’s information.

Preventive measures: The server processes data

The DOM model XSS

DOM – based XSS vulnerability is a vulnerability based on Document Objeet Model (DOM). Similar to reflective XSS, DOM XSS is a Web attack that does not go through the server side. The Web side does not process the data on the URL and inserts it dynamically into THE HTML, resulting in this attack.

Precautions: The front end escapes HTML/Script 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;

You can see from the above that the CSRF attack is an implicit authentication mechanism derived from the Web. The Web’s authentication mechanism can guarantee that a request is from a user’s browser, but it can’t guarantee that the request is user-approved!

Measures to prevent

1. Validate the HTTP Referer field
2. Add token to request address and validate
3. Add cSRFToken to the Request Headers attribute (cSRFToken) in the HTTP header attribute (cSRFToken)

The same origin policy of the browser – MDN

Content Security Policy (CSP) — MDN

Attached source 📎 web – securite. Zip