What are we talking about when we say “front-end security issues”
“Security” is a big topic, and there are many types of security problems. If we classify security problems according to the area in which they occur, then all security problems that occur in back-end servers, applications, and services are “back-end security problems”, and all security problems that occur in browsers, single-page applications, and Web pages are “front-end security problems”. For example, SQL injection vulnerabilities occur in back-end applications and are back-end security issues, while cross-site scripting (XSS) attacks are front-end security issues because they occur in the user’s browser.
In addition to categorizing the area where a security problem occurred, there is another dimension: which role on the team is best suited to fix a security problem? Back-end development or front-end development?
In general, when we talk about “front-end security issues” below, we are talking about security issues that occur in browsers, front-end applications, or are usually fixed by front-end developers.
Top 8 Front-end security issues
According to the classification method above, we summarize 8 typical front-end security problems, which are as follows:
- 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
- Static resource integrity check is missing
Due to space constraints, this article introduces you to the first four front-end security issues.
Cliche XSS
XSS, short for Cross-site Scripting, is a veteran of the OWASP Web Application Top 10, never falling out of the Top three. The root cause of security problems like XSS is that browsers mistakenly execute user input data provided by attackers as JavaScript scripts.
XSS can be classified into several different methods. For example, XSS can be classified into “storage XSS” and “reflection XSS” according to whether malicious input scripts are stored in the application. If they interact with the Server, XSS can be classified into “Server Side XSS” and “DOM Based XSS”.
No matter how you classify it, XSS vulnerabilities remain a security threat to users. Attackers can use XSS vulnerability to steal sensitive information including user identity information, modify Web pages to deceive users, even control the victim’s browser, or combine with other vulnerabilities to form worm attacks, and so on. In short, the use of XSS vulnerabilities, only unexpected can not be done.
How to defense
The best defense against XSS is strict output encoding of the data so that the data provided by an attacker can no longer be mistakenly executed as a script by the browser. For example,
Coding is also not easy, depending on the context in which the output data is encoded. For example, since the data is to be placed in an HTML element, it is HTML encoded, whereas if the data is to be placed in a URL, it needs to be URL encoded to become %3Cscript%3E. In addition, there is JavaScript coding, CSS coding, HTML attribute coding, JSON coding, and so on. Fortunately, front-end development frameworks provide front-end output coding by default, which greatly reduces the workload of front-end developers.
Other defense measures, such as setting CSP HTTP headers, input validation, and enabling browser XSS defense, are optional because these measures may be bypassed and cannot be guaranteed against XSS attacks. But they and the output code can work together to implement a defense in depth strategy.
Check out OWASP XSS Prevention Cheat Sheet_Prevention_Cheat_Sheet for a detailed description of XSS and its defense measures.
Be aware of the risks associated with iframe
Sometimes our front-end pages need to use third-party page components, usually in the form of iframe. Typical examples are using iframe to add third-party ads, weather reports, social sharing plug-ins, and so on to a page.
Iframe brings more rich content and capabilities to our pages, but also brings a lot of security risks. Because the content in an IFrame is provided by a third party, they are not under our control by default, and they can run JavaScirpt scripts, Flash plug-ins, pop-up dialog boxes, and so on inside the IFrame, which can ruin the front-end user experience.
If the iframe is only likely to affect the user experience, seemingly risk is not big, so if the domain name due to expire in the iframe is a malicious attacker, or a third party by hackers breached, be replaced the content of the iframe, by use of the user’s browser security vulnerabilities in the download and install a Trojan blackmail, malicious software, etc. That’s a big problem.
How to defense
Fortunately, in HTML5, iframe has a security property called sandbox, which can restrict the behavior of iframe and fully implement the principle of “minimum permissions”. The easiest way to use the sandbox is to simply add the keyword to the iframe element, as follows:
<iframe sandbox src="..."> ... </iframe>
Copy the codeSandbox also faithfully implements the “Secure By Default” principle, which means that if you simply add this property and leave its value empty, the browser will impose some of the harshest restrictions on iframe ever, basically allowing static resources to be displayed but nothing else. No submission of forms, no pop-ups, no scripts, etc. Even Origin is forced to reassign a unique value, in other words a page in an IFrame visiting its own server is counted as a cross-domain request.
In addition, Sandbox provides a wealth of configuration parameters that allow for fine-grained control. Some typical parameters are as follows:
- Allow-forms: Allows iframe forms to be submitted
- Allow-popups: allows new Windows or tabs to popup in an iframe (e.g. Windot.open (), showModalDialog(), target= “_blank”, etc.)
- Allow-scripts: allows JavaScript to be executed in iframe
- Allow-same-origin: allows the same origin policy to be enabled for web pages in iframe
For more detailed information, see iframe’s introduction to sandboxes.
Don’t get hijacked by clicks
There is a word called “unguarded.” When we use content provided by others through iframe, our own pages may be put into their carefully constructed Iframe or frame for clickjacking attacks.
This is a deceptive relatively strong, but also requires a high degree of user participation to complete a kind of attack. The usual attack steps are as follows:
- The attacker carefully constructs a click-inducing content, such as a Web page mini-game
- Put our page into an iframe
- Use CSS styles such as Z-Index to superimpose the iframe directly above the vertical direction of the mini-game
- Set iframe to 100% transparency
- When the victim visits this page, what he sees is a little game, and if he is induced to click on it, what he actually clicks on is our page in iframe
The danger of clickjacking is that the attack exploits the victim’s user identity to do something without his or her knowledge. Forcing users to follow a Weibo account might seem bearable, but deleting an important file or stealing sensitive information is much more damaging.
How to defense
There are several defenses against clickjacking attacks, such as the Frame Breaking scheme. A recommended defense is to use the HTTP Header x-frame-options: DENY to explicitly tell the browser not to display the contents of the current HTTP response in an HTML Frame.
For more details on Clickjacking, check out the OWASP Clickjacking Defense Cheat Sheet.
Incorrect content inference
Imagine an attack scenario where a site allows users to upload images in comments, and the attacker appears to be submitting an image file when it is actually a script file containing JavaScript. The file escaped file type verification (a common security issue involving malicious file uploads, but not related to the front end) and was stored on the server. Then, when the victim accesses the comment, the browser requests a JavaScript script disguised as an image. If the browser misunderstands the MIME types of the response, the image file is executed as a JavaScript script, and the attack succeeds.
The crux of the problem is that the content-Type headers set in the response returned by the backend server simply give the browser a suggestion for the current response Content Type, and the browser may presume to infer the Content Type based on the actual Content in the response.
In the example above, the back end uses the Content-Type Header to suggest that the browser render the HTTP response as an image, but the browser realizes that the response is actually JavaScript, so it takes the decision to interpret the response as a JavaScript script, and security issues arise.
How to defense
The browser can infer the type of response based on the content of the response. This is a very “smart” feature, which is a manifestation of the browser’s strong fault tolerance, but it can bring security risks. One way to avoid this security problem is to explicitly disable the browser from infering the response Type by setting the X-Content-type-options HTTP Header.
In the same attack scenario as above, the content-type returned by the back-end server suggests that the browser should perform Content rendering according to the image. The browser has found the existence of x-Content-Type-OptionShttP Header and its parameter value is nosniff, so it does not infer the Content Type. Instead, it forces rendering as an image, and since this is actually a JS script and not a real image, the script will be treated by the browser as a corrupted or incorrectly formatted image, rather than as a JS script, ultimately preventing security issues.
See here for more details on x-Content-type-options.
summary
This paper introduces four typical front-end security problems, including their causes and defense methods. In the next article, we’ll cover several other front-end security issues, so stay tuned.
For more insights, please follow our wechat account ThoughtWorks Business Insights