Whether you’re a React, Angular, Vue. Js, or a native JavaScript developer, your code is vulnerable to hackers.
As a front-end developer, we tend to focus more on performance, SEO, UI/UX, and tend to overlook security issues.
It may come as a surprise to learn how large frameworks keep you open to XSS attacks. For example, dangerouslySetInnerHTML in React or bypassSecurityTrust in Angular are risky operations.
We need to remember that the front end now has the same responsibilities as the back end, DevOps, in terms of security. The front end can also suffer thousands of malicious attacks.
Common attacks
Let’s take a look at some common types of attacks.
1. Upload any file
This type of attack is to upload malicious files to the server and execute them to attack the system. Attacks can include file system or database overloading, complete system takeover, forwarding attacks to back-end systems, or simple sabotage.
Click hijacking
This is an attack that induces users to click on pages or elements that are not part of the site. Such attacks can cause users to inadvertently provide certificates or sensitive information, download malicious software, visit malicious web pages, buy products online or have assets secretly transferred.
Translator’s note: In simple terms, a malicious website is covered with a transparent layer on the website viewed by the user, and the user is induced to click a button on the malicious website to trigger the attack
3. XSS attacks
This is a malicious script JS script into the web page attack. Flaws in websites allowed these attacks to succeed and spread widely.
4. SQL injection
This is an attack that corrupts the database by injecting malicious SQL into it through user input.
5. Dos attack (Denial of Service)
This is an attack that bombards servers with traffic and prevents normal users from accessing the servers.
6. Man-in-the-middle attack or session hijacking
This is an attack that intercepts the communication between a client and a server to steal a user’s password, account number, or any personal details.
Precautions,
Attackers will go to great lengths to find security holes in the front end, and in this article, we’ll look at some security-related best practices when writing front-end code.
1. Strictly restrict user input (first attack point)
User input should always be treated strictly, avoiding SQL injection, click hijacking, and so on. Therefore, it is important to validate and filter user input before sending it to the server.
Data can be filtered by removing or replacing dangerous characters, for example, using a whitelist and escaping incoming data.
However, I realize that filtering and coding user input is not an easy task, so we can use the following open source libraries:
- DOMPurify. You can filter user input with just one function. Custom rules are also supported, and are supported in
HTML5,SVG,MathMLThe use of. - secure-filtersIt provides a way to filter
HTML,JavaScript,Inline CSSAnd so on. When you want to take advantage of user input generationJavaScriptorCSSThis library is particularly useful.
For file uploads, check the file types and use the file filtering function to allow only certain file types to be uploaded.
2. Hide data or fields in the browser memory
If we use type=”hidden” to hide sensitive data in the page, or put them in the browser localStorage, sessionStorage, cookies, we need to carefully consider whether the data is safe.
An attacker can easily access everything added to the browser. An attacker can open a development tool and change all variables stored in memory. What if you hide the authentication interface based on the values in localStorage, sessionStorage, cookies?
Tools like ZapProxy expose these values to attackers after they find a way to inject scripts, which they can then use for further attacks.
Therefore, avoid using type=”hidden” to store keys, authentication tokens, and so on in the browser’s memory as much as possible.
3. The use of CSP
Never trust everything the server returns, define a strong CSP policy in Http headers that only allows trusted content to be executed in the browser.
It is better to have a whitelist list, and even if an attacker injected a script that did not match the whitelist, it would not be executed.
Here’s an example:
// header
content-security-policy: script-src ‘self’ https://apis.xyz.com
Copy the codeHere we define our Web application to trust only the script https://apis.xyz.com and its own domain name. An error will be reported in the console for resources with other domain names.
You can read more about CSP on the MDN website.
Not only can you set CSP rules in the header, you can also set them in the meta tag.
4. Enable the XSS protection mode
If an attacker somehow inserts attack code into the user’s input, “x-xss-protection “: “1; Mode =block” to tell the browser to block the response.
Most modern browsers have XSS Protection enabled by default, but it is recommended to add X-xSS-protection. This helps improve security in older browsers that do not support CSP.
5. Avoid typical XSS errors
The Dom API innerHTML is often used as an entry point for XSS attacks. Such as:
document.querySelector('.tagline').innerHTML = nameFromQueryString
Copy the codeAny attacker can use the above lines to inject malicious code.
Consider using textContent instead of innerHTML to avoid generating HTML directly. If you don’t generate HTML, no JavaScript will be inserted into the page, and even if you can see the attacking code in the page, nothing will happen.
Keep an eye out for Trusted Types(MDN addresses), a scheme developed by Google programmers to protect against all DOM-based XSS attacks.
In React. Js, dangerouslySetInnerHTML can have a similar effect to innerHTML.
Note: Don’t take the innerHTML value directly from the user input. Try to use textContent instead.
In addition, we should normally set the HTTP response headers content-type and x-Content-type-options. For example, do not encode JSON data as text/HTML to avoid accidental execution.
6. Disable IFrame embedding
Disabling iframe can help protect us from clickjacking attacks. We should add “x-frame-options “: “DENY” to the header to prevent the browser from rendering iframe in the page.
We can also use the CSP directive frame-rooted, which better controls which parent pages our page can be presented in the form of nested iframes.
7. Common error messages
Prompts like “your password is wrong” are user-friendly, but they are also friendly to attackers. They can use the error message returned by the server to determine what kind of attack he needs to do next.
When dealing with user accounts, emails, and personal information, try using ambiguous error messages like “incorrect login information.”
8. Use a verification code
Use captcha for external public services (login, registration). Captchas are intended to help us distinguish between humans and robots, and also to prevent DoS attacks.
9. SetReferrer-Policy
When we use tags or hyperlinks to direct users away from our site, make sure you add “referreer-policy” to the request header: “No-referrer”, or add rel=”noopener” or rel=”noreferrer” attributes to the tag.
When we do not set the header or rel properties, the target site can obtain some user-specific data.
Rel =noopener guarantees that a website that hops to the past cannot steal information from the original web page by window.opener. Rel =noreferrer is used to prevent referrer information from being passed to the target site. You can go to MDN to know the MDN Referrer Policy and MDN Link Type
10. Limit browser functionality or apis
Just as CSPS can limit trusted resource domains, we can also limit what capabilities browsers offer us. You can use the feature-policy field in the HTTP header to restrict the use of browser-provided functionality.
Tip: Disable anything you don’t use
Feature-policy is an experimental header property that currently works fine in Chrome, but not in IE or Safari. For details, see MDN feature-policy.
11. Periodically review NPM dependencies
Run NPM Audit regularly to get a list of NPM packages with vulnerabilities and upgrade them to avoid security issues.
GitHub now flags vulnerable dependencies. We can also use Snyk to automatically check your source code and automatically update the version number.
12. Separate your apps
As with the back end, we also have a microservices architecture that transforms a single Web application into an aggregation of small front-end applications, each of which can run independently.
The same principle can be applied to the front end. For example, a Web application can be divided into a common part, an authentication part, and a background administration part, each hosted in a separate subdomain, Such as https://public.example.com, https://users.example.com and https://admin.example.com. This will reduce vulnerabilities in Web applications.
Note: Proper separation also prevents XSS vulnerabilities in the common parts of the application from automatically corrupting user information.
13. Avoid using third-party services whenever possible
A single line of code can use a third-party service like Google Analytics, but it can also leave your app vulnerable. Think about these third-party service scripts being tampered with.
It is important to have a sound CSP strategy. Most third-party services have CSP directives defined, so be sure to add them.
Also, if possible, be sure to attach integrity to all your script tags. Sub-resource integrity (SRI) validates the hash value of a script and ensures that it has not been tampered with.
<script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..." crossorigin="anonymous"></script>
Copy the codeTo enable child resource integrity check, write the base64 encoded file hash value to the integrity property value of your reference
Think carefully about the auto-fill field
The personal data stored in the auto-fill browser is convenient for both users and attackers.
The attacker added a third-party script that took advantage of the browser’s auto-fill to extract the user’s email address to build tracking tags. They can use this information to build profiles of users’ browsing history, which can then be sold to bad guys.
Many of us don’t even know what information is stored in their auto-fill browser.
Tip: Do not automatically fill sensitive information into the form
MDN also has a special topic on Web security, which you can take a look at
About me
I am a modefeelings code porter, will update 1 to 2 front-end related articles every week, interested in the old iron can scan the following TWO-DIMENSIONAL code attention or direct wechat search front-end cram school attention.
Mastering the front end is difficult, let’s make up the lesson together!
Well, the translation is done. The link to the original text is here.