InformAction Forums

s3 urls have the following pattern:
http(s)://s3.amazonaws.com/{app}/{resource}
perhaps other CDNs use something similar. In this case it's meaningless to grant trust to the domain since it's just a container of many apps from many customers. Site Specific Permissions Policy would mitigate this, but still it would be better to trust the {app} and not the whole domain, even in a site specific scenario. How feasible is this?

al_9x wrote:How feasible is this?

Currently it's not (the whole browser security model is per-site, rather than per-path).
However you can do some fine tuning with ABE.

There are no paths, there is only a part of the URI that resembles paths. It's up to the web server how to handle this.

dhouwn wrote:There are no paths, there is only a part of the URI that resembles paths. It's up to the web server how to handle this.

Not sure about what you mean here. From the browser's standpoint, they're paths (the browser can't tell what they mean to the server, e.g. if they point to actual filesystem resources or they trigger some application action through URL rewriting).

Giorgio Maone wrote:However you can do some fine tuning with ABE.

I find Using ABE to selectively grant access to s3 is like using RequestPolicy without the convenience of its UI. This really needs a better approach, like Site Specific Permissions Policy.

Would it be possible to just add some specific rules for s3 / cloudfront / etc.. (the most common CDN's) that was something along the lines of:

If top level domain is whitelisted, then trust all CDN's - Else, dont.

Additionally, perhaps we can treat the s3 domains as partial urls ( http://s3.amazonaws.com/customer/ gets white listed, instead of just s3.amazonaws.com )

So basically if I am browsing twitter.com. any CDN that trys to load scripts on twitter.com would be allowed (provided i have given permissions to twitter.com )