This document provides information about security considerations related to Dynamic HTML (DHTML). This document doesn't provide all you need to know about security issues—instead, use it as a starting point and reference for this technology area.
innerHTML
Using the innerHTML property to display user input as HTML can compromise the security of your application. Developers often use innerHTML despite their expectation that the property's value will always be text. In those circumstances, set the innerText property instead. If appropriate for the context, validate user input for string length, script tags, and special characters (<) and their escape code equivalents.
If you must use innerHTML to create elements in the document, create only those elements that are not available through the DOM (param is one example) or that are not generated by user input. To generate HTML elements, use the createElement, appendChild, and setAttribute methods for greater safety.
Cross-site Scripting
Malicious attacks on Web sites are an industry-wide problem, bringing down Web servers, disrupting online commerce, and threatening users' personal data. Such attacks can affect anyone whose platform implementation is not secure or whose system is not maintained. Fortunately, you can better protect your Web sites. Using the best coding practices, Web developers can avert most attacks and make Web sites more trustworthy.
An essential part of writing secure Web applications is validating that incoming data is trustworthy. You should take the same precautions with data from the Internet and your intranet. An attacker might use an unwitting intranet user to send malicious data in order to bring down the Web server, attack data stores, or steal cookies.
For example, suppose that you run a bulletin board on which visitors can post their remarks to various topics you host. They send their comments in e-mail messages, which are then automatically posted to the site. (Posting means that you incorporate the comments into pages on your Web site; that is, the comments become part of your Web pages.) If an attacker sends a comment that contains some malicious code hidden behind a link, the attacker's comment is automatically posted. When a visitor to your site reads the attacker's innocuous-looking comment and clicks the link, the attacker's code runs on your Web site with the same security privileges as any other code that runs on your site.
Your Web site can also be the vehicle of an attack on your users by a third party, potentially making you appear to be the attacker. For example: an attacker's site sends a trusted link to a user in an e-mail message, or invites the user to another site displaying a trusted link. The user clicks the link. However, the URL includes a parameter that sends the user's name to the server so that the server can display that name to the user in some text string. The attacker has appended script tags and some malicious script to the URL, rather than a name.
www.adatum.com?name=<script>malicious.script</script>
Your site (in this example, "www.adatum.com") creates a page that contains the script tags and malicious script, which it then serves to the user. The script runs in the user's browser, attacking the user from a trusted site—yours! This script could send to the attacker's site the user's cookie data, which might include credit card or other private information. There's nothing the user can do about it; what's worse, your site facilitated the attack.
Protect your Web sites. Here are a few things you can do.
- Scan HTTP headers, URLs, and form data submitted to your site and remove suspicious input. The article Information on Cross-Site Scripting Security Vulnerability has good information about how to begin. One approach is to validate input against a restricted set of characters and strip out all others. For example, you could scan input for a-z, A-Z, and 0-9, removing everything else from the input stream.
- If your site is constructed with frames, you can set the SECURITY attribute on FRAME and IFRAME to
restricted. This sets the security zone of the frame in the browser to the user's restricted zone, which does not allow any script to run. - Restrict access to cross-frame scripting to trusted pages. Windows Internet Explorer restricts cross-frame scripting to pages within the same domain. For more information, see About Cross-Frame Scripting and Security.
Security Alerts
The following table lists features that, if used incorrectly, can compromise the security of your applications.
| Feature | Mitigation |
|---|
| codeBase | The URL of the component cannot be a local path. |
| contentEditable | Users can change the contents of a Web page when the contentEditable property is set to TRUE. Using this property incorrectly can compromise the security of your application. Incorrect use of the contentEditable property might include not validating user input. If you do not validate user input, a malicious user can inject control characters or script that can harm your data. You should take routine precautions against displaying unvalidated user input. |
| domain | Set the domain property only if you must allow cross-domain scripting. Use a value determined on the server. Setting this property to a value determined on the client (like through the location object) could expose your site to attack from another site through Domain Name System (DNS) manipulation. |
| form | Data submitted through a form object using the HTTP protocol is not encrypted and can be read and possibly tampered with in transmission. The HTTPS protocol can provide more secure data transmission. |
| frame | To protect user privacy and safeguard your applications, Internet Explorer restricts some interactions between frames that host Web pages from different domains. For more information about using the DHTML object model with the frame and iframe objects, see About Cross-Frame Scripting and Security. |
| frameSet | To protect user privacy and safeguard your applications, Internet Explorer restricts some interactions between frames that host Web pages from different domains. For more information about using the DHTML object model with the frame and iframe objects, see About Cross-Frame Scripting and Security. |
| iframe | To protect user privacy and safeguard your applications, Internet Explorer restricts some interactions between frames that host Web pages from different domains. For more information about using the DHTML object model with the frame and iframe objects, see About Cross-Frame Scripting and Security. |
| input type=file | When a file is uploaded, the file name is also submitted. The path of the file is available only to the machine within the Local Machine security zone. The value property returns only the file name to machines outside the Local Machine security zone. For more information on security zones, see About URL Security Zones. |
| input type=password | Using Secure Hypertext Transfer Protocol (HTTPS) is strongly recommended. You should also use the post method for submitting passwords. This submission method hides the password from most users by placing it in the HTTP header. The get method submits the password as part of the URL string, which might be exposed in the Address bar and the status bar. |
| input type=text | When submitting text through input type=text over an intranet or the Internet, validating the text string is recommended. For instance, you might validate the string for a restricted set of known, good values (like letters and numbers) and ignore the rest. |
| insertAdjacentHTML | If you must use the insertAdjacentHTML method to create elements in the document, create only elements that aren't available through the DOM (param is one example) or that aren't generated by user input. To generate HTML elements, use the createElement, appendChild, and setAttribute methods for greater safety. |
| innerHTML | Like the insertAdjacentHTML method, innerHTML can be used as an attack vector for script injection attacks. When accepting text from an unknown source, use createTextNode to convert the HTML to text, and append the element to the document using appendChild. |
| meta http-equiv="refresh" | When httpEquiv equals refresh and the content attribute specifies a new URL, developers should verify that the URL value does not contain semicolons. When the URL value contains one or more semicolons, Internet Explorer treats the value as a list of URL's; the page is refreshed from the last URL in the list. In addition, developers should take routine precautions to treat the value of the content attribute as text, rather than HTML. |
| moveBy | The x and y parameters must be greater than or equal to 0. |
| moveTo | The x and y parameters must be greater than or equal to 0. |
| open | A window in full-screen mode must also be in theater mode (channel mode). The top = number and left = number parameters must be greater than or equal to zero. |
| src | When the #sami suffix is specified with a valid URL for the SRC attribute of a media element, the contents of the Synchronized Accessible Media Interchange (SAMI) stream display as text in that element. Likewise, the stream contents can be returned as the innerText of that element. For security reasons, developers should regard the SAMI stream as user input and take routine precautions against displaying unconfirmed user input as HTML rather than text. |
| textArea | When submitting text through TEXTAREA over an intranet or the Internet, validating the text string is recommended. For instance, you might validate the string for a restricted set of known, good values (like letters and numbers) and ignore the rest. |