Intended Audience This document describes the security issues and coding specifications that front-end developers need to pay attention to during application development, aiming to eliminate common security risks.

* * note: ** The keywords used in the document “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” are in This is described in RFC2119.

Background knowledge

This article does not describe the attack and defense technologies of Web security in detail. Therefore, refer to the following documents for related knowledge:

XSS

XSS defenses

Be sure to read the ultimate XSS Protection Memo to do data escape operations as described.

Smarty template XSS escape using FIS:

Fis-plus enables the XSS escape function by default, and the -o parameter must be added during compilation

fisp release -o

Rich text data

Rich text data “MUST” MUST be processed by RD dependency minimization to prevent unsafe content.

CSRF

Background:

Cookies are used

Do NOT set cookies for the Baidu.com domain by using MUST NOT. Set cookies to the current domain name.

Disallow “MUST NOT” to set document.domain = “baidu.com” for pages.

phishing

There seems to be no good way.

Private data

Do NOT display IP information in MUST NOT. If you need to submit an IP address to the server, change it to another format, for example, the RD obtains IP information from the server indirectly.

The user’s personal privacy information: name, email address, telephone number, QQ, etc., MUST comply with the principle of minimization. The “MUST NOT” cannot appear in the page code if the information is NOT used. The JSON interface that obtains these data MUST also go through permission control.

Page jump

When you obtain parameters in the URL and jump to another site, do NOT use MUST NOT to jump to any site, and use MUST to set a whitelist to allow you to jump to only specified sites.

When clicking on a link in a page to jump to a third party site, it is RECOMMENDED to “RECOMMENDED” in the form of a server-side redirect similar to what is seen in baidu or Google search results. The backend can perform a security scan on the URL and detect that it is a malicious site or that the target resource is an executable file. Users should be strongly warned of the risks.

Third-party functions and resources

Third party functionality embedded in a page prohibits “MUST NOT” directly embedded in third party JS code, and is RECOMMENDED to be introduced as “RECOMMENDED” iframe.

If you need to use data from a third party in a page, it is RECOMMENDED that “RECOMMENDED” RD be used and jSONP is not used. If you must use JSONP, limit the callback function names returned by the third party, and prohibit the function names that are not allowed.

In principle, it is forbidden for “MUST NOT” to use resources provided by third parties: pictures, documents, etc. If necessary, it is RECOMMENDED for “RECOMMENDED” that RD capture relevant content and save it to its own Server. Because external chains generate off-site requests, they can be exploited for CSRF attacks and often have performance problems.

Click on the hijacked

For important operations, such as deleting data, making payments, etc., it is RECOMMENDED that “RECOMMENDED” verify that nesting is performed first. If you are in the frame of a third-party page, a confirmation box should be displayed to remind the user. The coordinate position of the confirmation box should have some random offset to invalidate the click area constructed by the attacker. The verification mode is as follows:

Use Flash

The SWF/JS interaction control property AllowScriptAccess, “RECOMMENDED” is never. If you choose sameDomain or always, should you know what you are doing

SWF’s network property AllowNetworking, “RECOMMENDED” none, otherwise CSRF may be caused. If you select All or Internel, you should know what you are doing

SWF and JS parameters are passed. “SHOULD” needs to be filtered to prevent XSS attacks

Executable file (.swf) grants credit, SHOULD NOT “NOT” use security.allowDomain (“*”), the loader or the loaded will get the same permissions as the current SWF

Allow-access-from domain=”*” in crossdomain-xml file (.txt,.xml,.json,.jpg)

When loading a cross-domain SWF, “SHOULD NOT” be careful with merging security domains (crossdomain.xml authorization or loadBytes()). The loaded SWF will have the same permissions as the parent SWF and can do anything

When using sharedEvents, the event “SHOULD” sent SHOULD be limited to events containing only simple data, otherwise it may expose the data in the SWF and all objects on the stage

Upload a file

It is RECOMMENDED that the domain name where the “RECOMMENDED” upload interface is located be isolated from the host domain name and that the file size allowed to be uploaded be limited by minimization.

JSON/JSON protocol

JSON data. HTTP header Content-Type: application/ JSON MUST be set

To provide data to third parties in JSONP form, HTTP header Content-Type: application/javascript MUST be set “MUST”, and callback function names are allowed only: array, letter, underscore.

Provide data in JSON/JSONP format, recommend “RECOMMENDED” to be minimal, expose only information that needs to be exposed, and whitelist referer to prevent malicious scraping.

Cross Domain set

In XML Httprequest 2 (xhr2) as well as the font – face if you need to support cross-domain Access requirements, ban “MUST” set the header to: Access – Control – Allow – Origin: *, set it to an accessible address, for example, access-Control-allow-origin: www.baidu.com

The resources

JSONP Security Attack defense 2014 New Tricks in XMLHttpRequest2 WooYun 80sec Open Web Application Security Project SS coding analysis XSS principle -1 XSS principle -2