1 2 3 4 5 6 next »

1. User input abounds
2. The first step is not the hardest
3. Making exceptions
4. Restructuring
5. Smoke detector
6. Pros and cons

Content Security Policy halts XSS in its tracks

by Hendrik Brummermann

Cross-site scripting (XSS) is one of the biggest problems faced by webmasters. Even banks and payment service providers like PayPal appear unable to prevent XSS from being used to inject external code. The new Content Security Policy standard should finally relieve the problem.

Modern web applications accept all sorts of user input. An obvious example is a search function for searching through goods available in an online store. Servers frequently return the input value as part of the search results: "Your search for search term returned 7 hits". If a web developer has failed to exercise sufficient care, cyber-criminals can exploit this to inject code into a web page, with a search term such as <script>alert("Pwned!")</script> being interpreted by the browser as JavaScript and executed in the context of the web site on which it is displayed. It therefore follows that unforeseen user input needs to be filtered.

A Content Security Policy allows webmasters to specify the resources a browser should be permitted to load when it calls a web page For complex web applications, however, forgetting to filter input or failing to properly filter input at some point or other in the application is the rule, rather than the exception. The XSS cheat sheet provides an impressive illustration of the range of tricks available to potential attackers for injecting their content into third-party web sites. XSS is a serious security risk. It can be exploited by attackers to access cookies, distribute malicious code or add phishing forms to vulnerable web sites. Options for cyber-criminals are limited only by their imagination.

Six degrees of separation

Content Security Policy (CSP) prevents XSS by blocking the use of scripts in web page source code (inline scripts). Instead, scripts have to be outsourced to separate files, providing a much greater level of control. A whitelist is then used to specify sources from which a browser is permitted to load and execute scripts when it visits a web site or to forbid them altogether. But that's not all. There are whitelists for frames, images, media, plugins, CSS files and fonts. It is also possible to specify with which servers the browser is permitted to communicate via XMLHttpRequest, WebSocket and server-sent events (EventSource).

Next page: The first step is not the hardest

1 2 3 4 5 6 next »