https->http iframe redirect matches "inc from https:"

[al_9x]

Code: Select all

Site http:
Anon INC from https:

1. The root page is over http (root.htm)
2. it contains an https iframe (iframe.htm)
3. iframe has a form that submits to https (httpredir.asp)
4. which 302 redirects to http (http.asp)

In the above scenario, it's not entirely clear why http.asp matches "inc from https:" The confusion stems from expecting the origin of inclusions to be the page that contains them, but here the origin is the iframe being replaced and a replacement is not an inclusion. Here the INC status and origin are unrelated, but the way the rules are written (inc from), strongly implies they should be.

There are also two matches for the same page, with origin chains reversed ( likely related to http://forums.informaction.com/viewtopi ... =10&t=7425 )

Code: Select all

[ABE] <http:> Anonymize INCLUSION from https: on {GET http://localhost/tests/abe/http.asp <<< https://localhost/tests/abe/httpredir.asp, https://localhost/tests/abe/iframe.htm - 7}
USER rule:
Site http:
Anonymize INCLUSION from https:
 ----------
[ABE] <http:> Anonymize INCLUSION from https: on {GET http://localhost/tests/abe/http.asp <<< https://localhost/tests/abe/iframe.htm, https://localhost/tests/abe/httpredir.asp - 7}
USER rule:
Site http:
Anonymize INCLUSION from https:

[Giorgio Maone]

On the other hand, thing of this (desirable by many) scenario: you want to anonymize or deny any Facebook inclusion from non-Facebook pages, and you write a rule like

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

Would you expect it to work or not if you include a frame with a non-Facebook page which, in turn, redirects to a Facebook one?

[al_9x]

On the other hand, thing of this (desirable by many) scenario: you want to anonymize or deny any Facebook inclusion from non-Facebook pages, and you write a rule like

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

Would you expect it to work or not if you include a frame with a non-Facebook page which, in turn, redirects to a Facebook one?

Yes I would expect it to block, but in my conceptual model for a different reason than currently, not because the page being replaced is non facebook, but because the container (parent) is non facebook.

I have not thought through all the implications, but I am suggesting that it's logical for the from url in INCLUSION clauses to always refer to the container, not the replaced origin. The page being replaced can not be said to be INCLUDING its replacement, inclusion is a parent-child relationship. The page INCLUDING is still the parent. Do you see problems with INC clauses behaving this way? Is it not more logical? Then, in my example, the rule would not match because the parent is http.

What about the double logging, is it related to http://forums.informaction.com/viewtopi ... =10&t=7425 ?

[Giorgio Maone]

On the other hand, thing of this (desirable by many) scenario: you want to anonymize or deny any Facebook inclusion from non-Facebook pages, and you write a rule like

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

Would you expect it to work or not if you include a frame with a non-Facebook page which, in turn, redirects to a Facebook one?

Yes I would expect it to block, but in my conceptual model for a different reason than currently, not because the page being replaced is non facebook, but because the container (parent) is non facebook.

Unfortunately ABE's "From" clauses implement a notion of "Origin" (i.e. the site where the code (HTML, JavaScript or response header) triggering the request belongs), not of "Container".
When INC was implemented, IIRC I did notice that it was a bit of a stretch in a CSRF context, but that it had nonetheless interesting use cases.
I believe the current model is the most consistent possible without making things overcomplicated with semantic exceptions.

it's logical for the from url in INCLUSION clauses to always refer to the container, not the replaced origin.

While this is always true for embeddings, images, scripts, stylesheets and the like, whose container always coincides with the document initiating the request (i.e. container == load originator), this becomes more complicated with frames, which don't just carry a document of their own, which may become the originator for other document loads inside (replacement) and outside it, but it can also be explicitly targeted by loads initiated by the parent documents, its subdocuments, or even by other frames or windows/tabs! (window.open(url, frameName))

Given the above, keeping the current meaning for the From clause and thus tracking the origins chain, i.e. the site(s) of the potential attacker in a CSRF perspective, makes more sense from a security standpoint.

What about the double logging, is it related to http://forums.informaction.com/viewtopi ... =10&t=7425 ?

As I replied there, I'm investigating.

[al_9x]

On the other hand, thing of this (desirable by many) scenario: you want to anonymize or deny any Facebook inclusion from non-Facebook pages, and you write a rule like

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

Would you expect it to work or not if you include a frame with a non-Facebook page which, in turn, redirects to a Facebook one?

Yes I would expect it to block, but in my conceptual model for a different reason than currently, not because the page being replaced is non facebook, but because the container (parent) is non facebook.

Unfortunately ABE's "From" clauses implement a notion of "Origin" (i.e. the site where the code (HTML, JavaScript or response header) triggering the request belongs), not of "Container".
When INC was implemented, IIRC I did notice that it was a bit of a stretch in a CSRF context, but that it had nonetheless interesting use cases.
I believe the current model is the most consistent possible without making things overcomplicated with semantic exceptions.

it's logical for the from url in INCLUSION clauses to always refer to the container, not the replaced origin.

While this is always true for embeddings, images, scripts, stylesheets and the like, whose container always coincides with the document initiating the request (i.e. container == load originator), this becomes more complicated with frames, which don't just carry a document of their own, which may become the originator for other document loads inside (replacement) and outside it, but it can also be explicitly targeted by loads initiated by the parent documents, its subdocuments, or even by other frames or windows/tabs! (window.open(url, frameName))

That's the point, who initiated the load is irrelevant for INC rules, if the rule says A can't INC B, then A is the parent doc of B. That is simply the the meaning of INCLUSION, other meanings are nonsensical (some arbitrary doc that initiates a load in a distant frame is not including it), so there is no question what the author of the rule intends. If you want to say that A can't initiate B then that's something different, not useless, but the two should not be conflated, and the plain from already allows you to say that.

Given the above, keeping the current meaning for the From clause and thus tracking the origins chain, i.e. the site(s) of the potential attacker in a CSRF perspective, makes more sense from a security standpoint.

Not the plain from, only the inc from. Why can't INCLUSION actually mean INCLUSION? However, If you don't want to change INC from, then what about a proper "contained in" method (which would also do the right thing for css loaded resources (i.e. container would be the doc not the css) When I suggested INC functionality, that is what I had in mind.

[Giorgio Maone]

Ah OK, maybe an "In(side)" clause alternative to "From".
It should work. No commitment for an ETA is possible at this point, though

[al_9x]

Ah OK, maybe an "In(side)" clause alternative to "From".
It should work.

Yes, a different clause makes sense, rather than overloading from for inc.