1.9.1 用HTML 写安全的应用程序

When HTML is used to create interactive sites, care needs to be taken to avoid introducing vulnerabilities（漏洞） through which attackers can compromise 损害 the integrity of the site itself or of the site's users.避免引进漏洞导致黑客可以损害站点的完整性或站点的用户

A comprehensive 广泛的、综合的 study of this matter is beyond the scope of this document, and authors are strongly encouraged to study the matter in more detail. However, this section attempts to provide a quick introduction to some common pitfalls 陷阱 in HTML application development.

The security model of the Web is based on the concept of "origins", and correspondingly many of the potential attacks on the Web involve cross-origin actions.[ORIGIN]

Not validating user input 非法的用户输入 Cross-site scripting (XSS) SQL injection

When accepting untrusted input, e.g. user-generated content such as text comments, values in URL parameters, messages from third-party sites, etc, it is imperative 必要的、不可避免的 that the data be validated 合法化 before use, and properly escaped when displayed. Failing to do this can allow a hostile user to perform a variety of attacks, ranging from the potentially benign, such as providing bogus 假冒的、伪造的 user information like a negative age, to the serious, such as running scripts every time a user looks at a page that includes the information, potentially propagating 扩散 the attack in the process, to the catastrophic灾难性的, such as deleting all data in the server.

When writing filters to validate user input, it is imperative that filters always be whitelist-based, allowing known-safe constructs and disallowing all other input. Blacklist-based filters that disallow known-bad inputs and allow everything else are not secure, as not everything that is bad is yet known (for example, because it might be invented in the future).

For example, suppose a page looked at its URL's query string to determine what to display, and the site then redirected the user to that page to display a message, as in:

<ul>
 <li><a href="message.cgi?say=Hello">Say Hello</a>
 <li><a href="message.cgi?say=Welcome">Say Welcome</a>
 <li><a href="message.cgi?say=Kittens">Say Kittens</a>
</ul>

If the message was just displayed to the user without escaping, a hostile attacker could then craft a URL that contained a script element:

http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E

If the attacker then convinced 说服 a victim 受害者 user to visit this page, a script of the attacker's choosing would run on the page. Such a script could do any number of hostile actions, limited only by what the site offers: if the site is an e-commerce shop, for instance, such a script could cause the user to unknowingly make arbitrarily many unwanted purchases.

This is called a cross-site scripting attack.

There are many constructs that can be used to try to trick a site into executing code. Here are some that authors are encouraged to consider when writing whitelist 白名单 filters:

• When allowing harmless-seeming elements like img, it is important to whitelist any provided attributes as well. If one allowed all attributes then an attacker could, for instance, use the onload attribute to run arbitrary 任意的、随意的 script.
• When allowing URLs to be provided (e.g. for links), the scheme of each URL also needs to be explicitly明确的 whitelisted, as there are many schemes that can be abused 滥用. The most prominent著名的 example is "javascript:", but user agents can implement (and indeed, have historically implemented) others.
• Allowing a base element to be inserted means any script elements in the page with relative links can be hijacked 劫持, and similarly that any form submissions can get redirected to a hostile site.

Cross-site request forgery伪造 (CSRF)

If a site allows a user to make form submissions提交 with user-specific side-effects, for example posting messages on a forum under the user's name, making purchases, or applying for a passport, it is important to verify that the request was made by the user intentionally 有意的, rather than by another site tricking the user into making the request unknowingly.

This problem exists because HTML forms can be submitted to other origins.

Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by checking Origin起点、初始 headers on all requests.

Clickjacking

A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to avoid the possibility that users can be tricked into activating the interface.

One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click, for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site's interface.

To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are not in a frame (e.g. by comparing the window object to the value of the top attribute).