It takes about 5 minutes to read the full article.

To begin this article, let me start with two questions I was asked in interviews:

  1. To prevent XSS attacks, we will filter the user’s input, and the escape time should be A. Front-end processing when input b. back-end processing when drop library C. SPLicing HTML?
  2. Does XSS attack prevention need front-end or back-end?

What is an XSS attack

XSS attacks are short for Cross-Site Scripting, and in plain English, pages are injected with malicious code — user input goes beyond text and becomes executable code.

Classification of XSS attacks

XSS attacks are generally classified into three categories based on the source of the intrusion code:

Stored XSS attack

Features: Malicious code has fallen off the library and is spliced back into HTML.

  1. The attacker submits malicious code to the database through the comments section of the forum;
  2. Other users open the forum, the server to take out the malicious code, spliced in HTML returned;
  3. Malicious code runs in the user’s browser;

In addition to forums, this kind of attack is also common in users sending private messages.

For example, users submit comments to the site’s database.

<%= getContent("comment") %> </div>Copy the code

After splicing by the back end:

<script>alert('XSS'); </script> </div>Copy the code

When other users visit the page, a dialog box says “XSS” pops up

Reflex XSS attack

Features: Malicious code is concatenated to the URL, concatenated to HTML and returned.

  1. The attacker splices out the URL of the victim site containing malicious code to induce users to click;
  2. When the user clicks on the URL, the server of the target site takes out the malicious code, splices it into HTML and returns it;
  3. Malicious code running on other users’ browsers;

This kind of attack requires users to actively click on the URL of the victim website, and the attacker will induce clicks through QQ groups or emails.

For example, a malicious URL could look like this: http://xxx/search? keyword=”

<div> Hello <%= getParameter("keyword") %> </div>Copy the code

After splicing by the back end:

Hello < div > < script > alert (' XSS); </script> </div>Copy the code

When clicked, a dialog box will pop up that says “XSS”.

DOM TYPE XSS attack

Features: Malicious code is spliced onto urls and executed by front-end JavaScript code.

  1. The attacker splices out the URL of the victim site containing malicious code to induce users to click;
  2. The user clicks on the URL;
  3. Front-end JavaScript takes out the malicious code in the URL, and the malicious code runs in the user’s browser.

The difference between DOM type and reflection type is that in DOM type XSS attack, taking out and executing malicious code is completed by the browser side, which is a security vulnerability of front-end JavaScript itself. The other two types of XSS are server-side security vulnerabilities.

The purpose of the above three XSS attacks is the same: malicious code running on the browser side steals the user’s locally stored data: obtains the user’s identity credentials through document.cookie, and then sends the data to the malicious server through network request.

The next step is to pose as a user and request specific actions from the victim site, such as transferring money to the attacker’s account.

How do I prevent XSS attacks

The implementation of an XSS attack requires two requirements:

  1. The attacker enters malicious code;
  2. Browsers execute malicious code;

Let’s look at the first point. Can we avoid an attacker entering malicious code by escaping HTML first?

If we perform escape filtering on the input content in the front end, the attacker can successfully attack as long as he simulates launching a request and bypassing the front end.

If we run the escape filter on the back end of the database, we will find:

  1. If the content is to be provided to multiple terminals, it will only be displayed on the front end and become garbled on iOS/ Android.

  2. It is returned to the front end in a different way, and may not display properly. For example, a normal user enters 5 < 7, but before writing to the database, the content is escaped and changed to 5<. 7.

    1. When used as HTML splicing page, it can be displayed normally.
    2. When returned via Ajax and then assigned to a JavaScript variable, the string the front end gets is the escaped character. This content cannot be used directly to display Vue templates. It will become garbled like iOS/ Android5 &lt; 7.

So we need to protect against XSS attacks by “preventing browsers from executing malicious code”.

Pure front-end rendering

Pure front-end rendering is when the browser first loads a blank HTML and then executes the JS file that the HTML introduces, which retrieves business data via AJAX, calls the DOM API, and updates it to the page.

Because we’re on the front end, we can clearly tell the browser that this is text.innertext instead of html.innerhtml. This way, the browser will not execute code that is expected to be unexpected.

Pure front-end rendering can avoid stored and reflected attacks, but not DOM attacks. Attackers can use onload events, href embedded javascript:… Attack.

Escaped HTML

For SSR projects that need to consider SEO, you have to concatenate HTML files on the server side. Then you must use an HTML escape library. The basic rule is to escape the & < > “‘/characters.

Focus on high-risk apis

Use the.innerhtml,.outerhtml, document.write() API that inserts directly into HTML with caution when front-end rendering, and the source must be trusted.

In addition, location, onclick, onError, onload, onmouseover, and the href of the tag can all execute strings as code.

Other Common Strategies

  1. Use CSP: CSP is a Content Security Policy that restricts the loading of resources in other domains, so that even if a hacker inserts a Javascript file, it cannot be loaded.
  2. Enable HTTP only: JavaScript is forbidden to read some sensitive cookies, attackers can not steal the cookies after COMPLETING XSS injection;
  3. Verification code: to prevent scripts posing as users to submit dangerous operations;

conclusion

After reading this article, back to the first two questions, we know:

  1. To escape the user input content, its timing must be in the splicing HTML, if processed before falling into the library, will lead to iOS/ Android garbled;
  2. The prevention of XSS attacks needs to be completed together with RD. Storage and reflection attacks are the responsibility of the back end, and DOM attacks are the responsibility of the front end.