ABE treats css as the parent of images it includes

al_9x · Post by **al_9x** » Thu Jun 16, 2011 6:39 pm

and perhaps other resources. Fx 4.0.1, NS 2.1.1.2rc3

This makes no sense, the parent should be the page itself.

[ABE] <domain1.invalid> Deny INCLUSION on {GET http://domain1.invalid/tests/css/paper.gif <<< http://domain1.invalid/tests/css/style.css - 3}
USER rule:
Site domain1.invalid
Deny INCLUSION

The previous rule should have matched the image:

Code: Select all

Site domain1.invalid/tests/css/
Accept INC from localhost

the page loaded from localhost:

Code: Select all

<html>
<head>
<link href="http://domain1.invalid/tests/css/style.css" rel="stylesheet">
</head>
<body>
</body>
</html>

style.css

Code: Select all

body {background-image:url('paper.gif');}

Post by **Giorgio Maone** » Thu Jun 16, 2011 7:32 pm

al_9x wrote:This makes no sense

Why not, exactly? Could you explain a CSRF attack scenario which is made possible by this behavior and prevented by the other one?

BTW, this is exactly what Gecko uses for its origin policies: the stylesheet is the origin of any resource it includes.
Diverging from this built-in browser behavior should be justified at least by a threat model.

al_9x · Post by **al_9x** » Thu Jun 16, 2011 8:21 pm

An image loaded by inline script has the doc as origin?
An image loaded by external script has the doc as origin?
An image loaded by internal stylesheet has the doc as origin?
An image loaded by external stylesheet has the stylesheet as origin, why the exception?

I don't know if it makes sense for gecko internals but it does not for abe rule construction.

For abe inclusion rule purposes people think in terms of pages and included resources, the idea that the stylesheet is the parent, is surprising and unintuitive. ABE should keep to a simple consistent inclusion model.

Site domain2
Deny INC(IMAGE) from domain1

One would clearly expect this rule to block all images from domain2 on pages from domain1, but it wont because of this stylesheet exception. Does this really make sense to you? It doesn't seem too difficult to look up the doc origin when gecko gives you the stylesheet as the origin, is it not just a matter of querying the stylesheet's origin? If it's not a big deal, why chose the gecko default? I don see any advantages only confusion and possibly unpleasant surprises.

Post by **Giorgio Maone** » Thu Jun 16, 2011 9:57 pm

al_9x wrote:It doesn't seem too difficult to look up the doc origin when gecko gives you the stylesheet as the origin

It is. The same stylesheet may be loaded by multiple documents, so it's not something you can reliably lookup without keeping DOM references around way longer than it would be advisable.

al_9x wrote:I don't see any advantages only confusion and possibly unpleasant surprises.

If you trust stylesheet more than you trust images you're certainly in for unpleasent surprises.
However I can see where you're coming from, and I'll check whether this is a change which can be made without too heavy side effects.

al_9x · Post by **al_9x** » Thu Jun 16, 2011 11:28 pm

Here's another origin related ABE issue I ran into:

A page on domain1 makes a resource request to domain2, which is redirected to domain3.

The abe rules are:

Code: Select all

Site domain3/domain1_allowed_path/
Accept INC from domain1

Site domain3
Deny INC

Currently, evidently domain2 is taken to be the origin and the request matches the second rule which blocks it. But that doesn't make sense to me. Per the simple inclusion model of pages and resources that I advocated, the page (i.e. origin) is domain1, so the first rule should allow the resource.

Post by **Giorgio Maone** » Thu Jun 16, 2011 11:43 pm

al_9x wrote: Currently, evidently domain2 is taken to be the origin and the request matches the second rule which blocks it. But that doesn't make sense to me. Per the simple inclusion model of pages and resources that I advocated, the page (i.e. origin) is domain1, so the first rule should allow the resource.

For ABE to be an effective "Application Boundary Enforcer", permissive rules (Accept from) must be checked strictly on the whole redirection chain (i.e. all the sites in the redirection chain must be considered origins and match). Restrictive rules (Deny from), conversely, just need one of the sites in the redirection chain to match.

Comining to your example, what if domain2 suddenly becomes malicious and turns the innocuous request from domain1 into a CSRF attack to domain3?
If you trust this to never happen (i.e. you control all the 3 domains, which form your "application boundaries), the rule must be written as

Code: Select all

Site domain3/allowed_path/
Accept INC from domain1 domain2

Site domain 3
Deny

InformAction Forums

ABE treats css as the parent of images it includes

ABE treats css as the parent of images it includes

Re: ABE treats css as the parent of images it includes

Re: ABE treats css as the parent of images it includes

Re: ABE treats css as the parent of images it includes

Re: ABE treats css as the parent of images it includes

Re: ABE treats css as the parent of images it includes