This is the 14th day of my participation in the August Text Challenge.More challenges in August

preface

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. In the era of mobile Internet, front-end personnel often encounter new security problems such as network hijacking and illegal calling of Hybrid API in addition to traditional security problems such as XSS and CSRF. Of course, the browser itself is also constantly evolving and developing, constantly introducing CSP, same-site Cookies and other new technologies to enhance security, but there are still many potential threats, which require front-end technical personnel to continue to “check the missing”, the last introduction is the attack, this article we will talk about how to defend against these attacks ~

First, XSS attack defense

The philosophy of XSS attack defense is never trust the user! Never trust your users!

  • Never trust user submissions
  • Do not convert user-submitted content directly into the DOM

1.1 Off-the-shelf tools to defend against XSS attacks

Front end:

  • Mainstream frameworks defend against XSS by default
  • google-closure-library

Server (Node) :

  • DOMPurify

1.2 Dynamic DOM generation is required

Convert string to DOM

You can use the New DOMParser()API, in which case strings must be filtered

Upload the SVG

Script tags can be embedded in SVG, which causes XSS attacks when the SVG is loaded by the browser, so the SVG files uploaded by the user should also be filtered.

<svg>
    <script>alert("xss");</script>
</svg>
Copy the code

Custom jump links

Be sure to filter if you allow users to customize jump links.

<a href="javascript:alert('xss')"></a>
Copy the code

Custom styles

Try not to allow user-defined styles.

1.3 the Content Security Policy (CSP)

  • Which sources (domain names) are considered secure
  • Scripts from a secure source can be executed, otherwise an error is thrown
  • Say 🙅 to eval + inline script

How to configure

The server’s response header:

Content-Security-Policy: script-src 'self'The same Content ws-security - Pplicy: script - the SRC'self' https://domain.com
Copy the code

Browser Meta:

<meta http-equiv="Content-Security-Policy" content="script-src self">
Copy the code

Second, CSRF defense

We know that in CSRF, the request is forged, that is, all its request sources are abnormal, not real domain name, so can we limit the request source to achieve the purpose of restricting the forged request, the answer is yes.

2.1 token

2.2 Limiting iframe Attacks

2.3 Avoid carrying User information: SameSite Cookie

2.4 Correct posture for CSRF defense

If CSRF defense is done on every interface, it is too tiring, or rather, not elegant, to handle CSRF defense uniformly in the middleware.

Third, SQL injection defense

  • Find the place in the project to query SQL
  • Using a prepared statement

Iv. Other injected defenses

5. Defend against DDoS

6. Guard against middlemen

The involvement of the HTTPS

Some features of HTTPS

  • Reliability: encryption

  • Integrity: MAC authentication

  • Non-repudiation: digital signature

HTTP Strict-Transport-Security(HSTS)

Subresource Integrity(SRI)

Compares whether the hash value of a static file has been tampered with

The last

⚽ to this, our Web security defense has been introduced, we should know that security is no small matter, should always pay attention to network security issues, keep learning mentality ~ ⚾ if you are interested in this article welcome to praise attention + collection, more wonderful knowledge is waiting for you! 😘 🏀GitHub blogs at github.com/Awu1227. 🏉 I have other columns, please read ~ 🏐 play the beauty of CSS 🎱Vue from giving up to getting started 🎳 simple JavaScript