UPDATE
Before reading on any further I want to prefix that the purpose of this post is to begin a discussion on the ways a website can communicate to a browser to instruct it of what its behavior should be on that site. The example below is a "sample implementation" and isn't meant to be a proposal for a new standard (those things are built by committees :). Such a concept isn't supposed to be a magic bullet and may not work for all/most sites however when used in pieces could be 'one way' of hardening the site experience for the user.

Sites like Yahoo, MySpace, blogspot, LiveJournal and others allow their users by default to provide active content in the form of html, images, movies, and in rare cases javascript. They also utilize third party advertisers to serve up ads including flash based ads. From a security perspective running a site with this functionality opens you up to:

- XSS and Script based attacks
- Drive by malware via ad network infection
- Inappropriate information gathering
- Inappropriate content (adult content, offtopic, etc)

The business may require some active content to execute either by the user, an advertiser, or a partner which of course comes with many known risks. Unfortunately there is no way to say 'advertiser X can only do X on my domain' or a way to prevent someone exploiting an xss hole from getting script to execute in the users browser. Here is where a site Active Content Policy comes into play. Before diving into the guts here are the objectives of such a policy.

Objectives
- Restrict active content executed from domains other than the current domain
- Inform the browser which domains should be serving up which type of content and to ignore others
- Inform the browser of allowed execution behaviors for that domain

The policy will only control execution behavior for that domain. If for example a.com referenced flash.com and b.com also referenced it, a.com could state what flash.com can and can't do when the ad is served on a.com. A separate policy may or may not exist for b.com and in no way would conflict with other sites utilizing flash.com. Below is an example of what such a policy may look like.

File Location:  http://site.tld/activecontentpolicy.xml

Sample Active Content Policy File v0.1
<all>http://*.site.tld</all>    // Allow all types of content from specified host
<script>https://foo.advertiser.tld</script> // JavaScript/VBScript/etc...
<flash>http://somesite.tld</flash> //Allow flash
<css>http://somecsssite.tld</css> //Allow cascading style sheets
<movie>http://moviehoster.tld</movie> //Allow movies to be served
<image>http://*.host.tld:8080/</image> //Allow images to only be served from specified domain
<applet></applet>
<activex></activex>
<silverlight></silverlight>
<other></other> //Other web technologies

In addition to specification on a per technology basis you may also have tag attributes specifying the way the browser should behave.

Sample Tag Properties/Attributes

* allowoffsiterequests=bool
Specifies if HTTP requests can be made to any domain. This would include image tags, frames/iframes, or any other tag performing a GET or POST action. An advantage here is that you can lockdown the types of information being sent to a third party such as cookies, browser stats, etc... Transfer can still happen via a proxy or middleware script relaying this information off.

* allowajax=bool
Specifies if ajax/xmlhttp can be utilized

?FUTURE?
* Allowcontentscripting
For movies allowing scripting as part of the standard. This could allow the site owner to inform the browser not to execute any script contained within the content. Currently not possible without tweaks in the way plugins interact with the browser. More of a future suggestion to show the possibilities/where I'm going with this rant.

Sample policy utilizing attributes

<all allowoffsiterequests="false" allowcontentscripting="false">http://*.site.tld</all> // Allow requests to the same site, allow script to execute on the same site, but do not allow the javascript on *.site.tld to generate requests off domain.
<script>http://googleanalytics.com</scriptinclude> // Allow any script from "the google"
<movie allowoffsiterequests="false">http://host</movieinclude> // Allow movies to be served but not to spawn requests to a site for supported formats

Advantages
- Central control by security organization/business for what is and isn't allowed.
- If malicious content is somehow inserted into the site, advertiser or other content domain access rights are restricted
- Tags are optional, attributes are optional. Very granular allowing for flexible business requirements.
- Allows some active content to execute on a website while disallowing others. Much better than disallowing all!
- Extensible to future attributes/properties and technologies
- Doesn't require technical user knowledge of allowing or disallowing a domain with noscript. Those users can still function with no change.
- Separation of privileges from business layer logic.

Disadvantages
- For sites allowing many providers maintaining a whitelist may be a challenge

Where this won't help:
- Persistent XSS where the entire payload is contained. This may help in preventing the transfer of content offsite.

The primary motivation for this rant post is to get the industry to start talking about practical ways to reduce risk on the broken web and ask why don't we have something like this/better already? Pretend for a moment that this browser technology exists and is available in at least 1 major browser (don't focus on adoption). What are the pros/cons of such a technology and what comes close currently? Hop on irc.freenode.net #webappsec to discuss such initiatives.

Post your comments online for discussion.