by al_9x » Tue Oct 18, 2011 2:36 pm
Giorgio Maone wrote:al_9x wrote:Giorgio Maone wrote: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.
al_9x wrote: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 document
s, 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.
Giorgio Maone wrote: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.
[quote="Giorgio Maone"][quote="al_9x"][quote="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]
Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC
[/code]
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?[/quote]
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.
[/quote]
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.
[quote="al_9x"]it's logical for the from url in INCLUSION clauses to always refer to the container, not the replaced origin.[/quote]
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 document[b]s[/b], its subdocuments, or even by other frames or windows/tabs! ([i]window.open(url, frameName)[/i]) [/quote]
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.
[quote="Giorgio Maone"]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 [i]attacker[/i] in a CSRF perspective, makes more sense from a security standpoint.
[/quote]
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 [url=http://forums.informaction.com/viewtopic.php?f=10&t=6660&p=28698#p28698]right thing for css loaded resources[/url] (i.e. container would be the doc not the css) When I suggested INC functionality, that is what I had in mind.
