The final chapter of detailed analysis of HTML5 security attacks and defenses: HTML5's security improvements

                                                                                                                                                                                                                                              Please indicate the source when reprinting: The final chapter of the detailed analysis of HTML5 security attack and defense: HTML5’s security improvements

HTML5 makes a lot of additions to the old security strategies.

1. iframe sandbox

HTML5 adds a sandbox attribute to the iframe element to prevent untrusted web pages from performing certain operations, such as accessing the DOM of the parent page, executing scripts, accessing local storage or local databases, etc. But this security strategy will bring other risks, which is very interesting. For example, ClickJacking attacks prevent JavaScript scripts from running to bypass JavaScript defense methods.

2. CSP content security policy

XSS bypasses the same-origin policy through fake content and clickbaiting. The core of the XSS attack is that the browser cannot distinguish whether the script is injected by a third party or is actually part of your application. CSP defines the Content-Security-Policy HTTP header to allow you to create a whitelist of trusted sources so that the browser only executes and renders resources from these sources, rather than blindly trusting all content provided by the server. Even if an attacker can find a vulnerability to inject a script, it will not be executed because the source is not included in the whitelist.

The principle of XSS attack

3. XSS filter

Modern browsers such as Chrome and Safari have also built security defense measures and provide XSS filters on the front end. For example, http://www.php.cn/;/p><script>alert(1)</script> will not be executed in Chrome, as shown in the figure below.

4. Others

In addition, HTML5 applications are more restricted in accessing system resources than Flash.

Finally, the HTML5-specific security specifications are still under discussion. Some people want to spread them into various chapters of the HTML5 specifications, and some people want to list them separately. There is currently no separate content, because not only the security of Web App developers must be considered , we should also consider the vendors that implement HTML5 support and standardize and guide them.

I personally think that the security specifications of HTML5 will be explained in a unified chapter and mentioned accordingly in each functional module.

The above is the final chapter of the detailed analysis of HTML5 security attacks and defenses: HTML5’s security improvements. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!