JavaScript Security - Preventing Cross-Site Scripting
(Page 9 of 9 )
You should use a two-pronged approach to preventing cross-site scripting attacks. The first tenet is to always positively validate user input at the server (i.e., in your CGI, PHP, and so on). You should check submitted form values against regular expressions that are known to be “good” (or use equivalent logic to make the determination). This is as opposed to checking values for undesirable characters, which we term “negative” validation. For example, if usernames are supposed to be alphanumeric characters, ensure that inputs match a regular expression such as ^[a-zA-Z0-9]+$ instead of looking for potentially problematic non-alphanumeric characters. Positive matching is superior to negative matching because there’s no opportunity to make a mistake by forgetting to search for a particular “bad” character.
The second approach is to always HTML-escape data before writing it into a Web page. HTML-escaping replaces meaningful HTML characters such as < and > with their entity equivalents, in this case < and >. Doing so ensures that even if malicious input makes it past your input validation code, it will be rendered harmless when written into the page.
Note that how data must be escaped to be safe for output (termed output sanitization) depends on how it is written into the page. For example, if the user passes in a URL to be written into an <iframe>:
<IFRAME src="VALUEGOESHERE"> </iframe>
An attacker could pass in http://somelegitsite.com"%20onload="evilJSFunction()" as the URL (%20 is a space). This would be decoded and inserted into the page, resulting in:
<IFRAME src="http://somelegitsite.com" onLoad="evilJSFunction()"> </iframe>
Merely escaping < and > is not sufficient; you need to be aware of the context of output as well. A policy of escaping &, <, >, and parentheses, as well as single and double quotes, is often the best way to go.
Output sanitization can be tricky, and requires an in-depth knowledge of HTML, CSS, JavaScript, and proprietary browser technologies to be effective. Readers interested in learning more about cross-site scripting and Web application security in general might benefit from reading the Open Web Application Security Project (OWASP) Guide, currently found at http://www.owasp.org/documentation/guide.
Summary The JavaScript security model is based on a sandbox approach where scripts run in a restricted execution environment without access to local file systems, user data, or network capabilities. The same-origin policy prevents scripts from one site from reading properties of windows loaded from a different location. The signed script policy allows digitally signed mobile code to request special privileges from the user. This technology guarantees code authenticity and integrity, but it does not guarantee functionality or the absence of malicious behavior. Both major browsers are capable of using signed code, but Internet Explorer unfortunately does not support signed JavaScript. Yet even if perfectly implemented, many users will refuse to grant signed script privileges out of well-founded security fears. As a result, if employed, signed scripts should always be written in a defensive manner to accommodate this possibility, and are probably best suited for intranet environments.
The sad reality is that JavaScript can be used to wreak havoc on the user’s browser and operating system without even violating the security policies of the browser. Simple code that eats up memory or other resources can quickly crash the browser and even the operating system itself. Deceptive programming practices can be employed to annoy or trick the user into actions they might not intend. Yet clean, careful coding does not solve all JavaScript security-related problems. Web applications accepting user input need to be careful to properly validate such data before accepting it, and to sanitize it before writing it into a Web page. Failing to do so can result in cross-site scripting vulnerabilities, which are as harmful as violations of the same origin policy would be. Because of the range of potential problems, it is up to individual developers to take the responsibility to write clean, careful code that improves the user experience and always be on the lookout for malicious users trying to bypass their checks.
 This chapter is from JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider, McGraw-Hill/Osborne, ISBN: 0072253576). Check it out at your favorite bookstore today.
Buy this book now. |
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 58 
