In 8 Front-end Security Issues (Part 1), we discussed what front-end security issues are and introduced four typical security issues. In this article, we introduce the remaining four front-end security issues, which are:

  • Fire prevention and theft prevention pig teammate: insecure third party dependent package
  • HTTPS can also fall into the hole
  • Data on the local storage is leaked
  • Lack of static resource integrity verification

Fire prevention and theft prevention pig teammate: insecure third party dependent package

Developing apps these days is like writing code on the shoulders of giants. According to statistics, nearly 80% of the code in an application actually comes from third-party components, dependent libraries, etc., while only about 20% of the code in the application itself. Whether it is back-end server applications or front-end application development, most of the time we are using development frameworks and various class libraries for rapid development.

The benefits of this approach are obvious, but the security risks are also accumulating — with so much third-party code being used in an application, vulnerabilities in third-party code, no matter how secure the application’s own code, pose a serious challenge to the overall security of the application.

(Photo: t.cn/RlAQsZ0)

For example, jQuery has several known security vulnerabilities, such as jQuery Issue 2432, that make applications vulnerable to XSS attacks. Node.js also has some known security vulnerabilities, such as CVE-2017-11499, which can lead to DoS attacks on front-end applications. In addition, front-end applications, in addition to the front-end development framework, often rely on a number of Node component packages, which may also have security vulnerabilities.

Manually checking third-party code for Security problems is a chore, mainly because the application relies on a large number of these components, manual checking is too time-consuming. Fortunately, there are automated tools available, such as NSP(Node Security Platform), Snyk, etc.

HTTPS can also fall into the hole

To protect information from being leaked and secure during transmission, TLS or, colloquially, HTTPS is now standard. But that’s not so simple. Even if HTTPS is turned on on the server, the hacker could use SSL Stripping to force HTTPS to degrade back to HTTP, which in turn would lead to a man-in-the-middle attack.

The essence of the problem is that the first request made by the browser is intercepted and modified by the attacker, which does not give the browser and server a chance to communicate with HTTPS. The general process is as follows: When a user enters a URL in the browser, it usually starts from the domain name instead of https://. Then the browser initiates HTTP communication with the server. However, due to the presence of an attacker, it blocks the response returned by the server to redirect to the HTTPS page. And instead of the client and server side for subsequent communication. Because this is all done in the dark, the users of the front-end application have no idea.

The solution to this Security problem is to use HSTS (HTTP Strict Transport Security), which uses the following HTTP Header and a pre-loaded manifest to tell the browser that it is mandatory to use HTTPS when communicating with the site. Instead of communicating over plaintext HTTP:

Strict-Transport-Security: max-age=<seconds>; includeSubDomains; preload
Copy the code

“Mandatory” means that the browser makes HTTPS requests directly to the server in any case, rather than jumping from HTTP to HTTPS as usual. In addition, when a certificate or link is insecure, the user is first warned and is no longer given the option of continuing the insecure communication.

(Photo: t.cn/Rfj3Tku)

Data on the local storage is leaked

Previously, for a Web application, storing a small amount of user information on the front end through cookies was enough to support the normal operation of the application. However, with the separation of the front and back ends, especially the rise of the stateless architecture style of the back end services, and the emergence of a large number of SPA applications, the amount of data stored in the front end, that is, the user’s browser, is gradually increasing.

Front-end applications are completely exposed to users and attackers. Any sensitive and confidential data stored in the front-end will be exposed to the risk of disclosure, even if the data is encrypted in the front-end through JS scripts.

For example, let’s say your front-end application wants to support offline mode so that users can use your application offline, which means you need to store some user data locally. Such as Personal Identifiable Information (PII), such as email address, cell phone number, home address, and perhaps historical bills, spending records, and so on.

Despite the browser’s same-origin policy restrictions, if the front-end application has an XSS vulnerability, all data stored locally can be read by the attacker’s JS script. If the user uses the front-end application on a public computer, is the data completely wiped when the user leaves? The front end encrypts data and stores it as a defense, but in fact it only raises the threshold of attack a bit, because the encryption key is also stored in the front end, and a patient attacker can still break through the encryption barrier.

Therefore, storing sensitive and confidential information on the front end is always dangerous, and it is recommended to store it as little as possible.

Lack of static resource integrity verification

For the sake of performance, front-end applications usually store some static resources on CDN (Content Delivery Networks), such as Javascript scripts and Stylesheet files. Doing so can significantly speed up access to front-end applications, but it also introduces a new security risk.

If the attacker hijacked the CDN or polluted the resources in the CDN, then our front-end application got the JS scripts or Stylesheet files with problems, allowing the attacker to arbitrarily tamper with our front-end page and attack users. The effect of this attack is similar to that of XSS cross-site scripting, except that the attacker starts the attack from the CDN, whereas traditional XSS attacks start from the user input.

One way to defend against this attack is to use the Subresource Integrity (SRI) function provided by the browser. As the name implies, Subresource refers to the resource file specified by the

Each resource file can have an SRI value, as shown below. It consists of two parts, the left side of the minus sign (-) is the Hash algorithm name used to generate SRI value, and the right side is the Hash value of the resource file after Base64 encoding.

< script SRC = "https://example.js" Integrity = "sha384 - eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX" > < / script >Copy the code

When the browser processes this script element, it will check the integrity of the corresponding JS script file to see if it matches the SRI value specified by the integrity attribute of the script element. If it does not match, the browser will stop processing the JS script.

summary

In the previous and this article, we introduced you to the top 8 security issues you may encounter when developing front-end applications. They are:

  • Cliche XSS
  • Be aware of the risks associated with iframe
  • Don’t get hijacked by clicks
  • Incorrect content inference
  • Fire prevention and theft prevention pig teammate: insecure third party dependent package
  • HTTPS can also fall into the hole
  • Data on the local storage is leaked
  • Lack of static resource integrity verification

We hope that through the introduction of these problems, attract the attention of front-end development partners, as far as possible in advance to bypass these security problems pit.

For more insights, please follow our wechat official account: Sitvolk

WeChat
Sina Weibo
Evernote
Pocket
Instapaper
Email
LinkedIn
Pinterest