Archive for June 5th, 2008

A couple of months ago, Brandon Sterne of the Mozilla Security Team asked me some questions about NoScript’s internals, because he was developing a Firefox add-on which involved selective script-blocking.

Looks like he finally delivered: Site Security Policy is a proof of concept for an idea proposed by RSnake and turned into a specification by Gervase Markham, known as “Content Restrictions”.

A Site Security Policy is defined by the website administrator and communicated to the web browser as a set of special “X-SSP-…” HTTP headers either attached to the affected content or sent in response to a “discovery”

HEAD

request:

  • X-SSP-Script-Source

    specifies a deny/allow list of hosts which are allowed to run scripts.
    If this header is sent, no embedded script is allowed to run, and only included scripts whose sources match the rules are executed. This is an effective anti-XSS countermeasure, and could be extremely useful for so called “Web 2.0″ sites featuring user-generated rich content.

  • X-SSP-Request-Source

    lists the hosts which can or cannot send HTTP requests to a certain resource, and the “acceptable” HTTP verbs.
    This can help enforcing referrer-based checks against CSRF attacks which work even if user chooses to omit or spoof the

    Referer

    header for privacy reasons, and mitigating verb-tampering attacks when used to “enhance” CSRF.

  • X-SSP-Request-Target

    limits the destinations of requests originated by the current page.
    This may help mitigating data-leakage outcomes of a successful XSS attack, e.g. by preventing authentication tokens from being logged to remote hosts, but also avoiding the page to be used as a platform for CSRF attacks and blocking inclusion of unwanted 3rd party content.

  • X-SSP-Report-URI

    declares an URL where policy violation attempts should be logged by the browser.

If you want to start applying these restrictions to your web content, you’ll find a detailed yet simple reference* with examples on Brandon’s project web site.
Implementing a Site Security Policy cannot surrogate web developers’ security awareness and best practices, but it’s nonetheless a big step forward in making a website safer for its users.

Obviously enough, to be generally effective this technology still needs to be evangelized to administrators and coders, correctly deployed and supported in a consistent cross-browser fashion. But as soon as it gets built in our favourite browser and we begin to see badges like “Browsing this site is safer with Firefox”, we can hope other vendors to join making the Web a safer place.

* Update:

Site Security Policy changed its name to “Content Security Policy”, and it dropped its anti-CSRF features to focus on XSS prevention only.
Details have been relocated here.

Bad Behavior has blocked 2615 access attempts in the last 7 days.