ABE should be able to compare against parent (bug? RFE?)

Bug reports and enhancement requests
Post Reply
RobertDrew
Junior Member
Posts: 32
Joined: Sun Jun 14, 2015 6:51 pm

ABE should be able to compare against parent (bug? RFE?)

Post by RobertDrew » Tue Jul 07, 2015 7:02 pm

Code: Select all

Site *
Accept SUB from SELF++
Anonymize SUB

Code: Select all

Site *
Accept INCLUSION(SUBDOC) from SELF++
Anonymize INCLUSION(SUBDOC)


I believe the above two rulesets are functionally identical. In either case, I expected either of these rulesets to always Anonymize a site if it is within an iframe, unless the parent to the iframe is part of the same site.

In reality, that is not the result. Instead, "from SELF++" compares not to the parent, but rather to the most recent request (which may originate within the iframe). This is particularly surprising with the "Accept INCLUSION(SUBDOC) from SELF++" version of the ruleset -- in cases where the site is not an inclusion-from-itself as the line reads, the request is Accept'ed anyway (this is because ABE instead reads this as the site is an inclusion, (comma), and is a request from itself).

Example:

evil.com has an iframe to bank.com ... when the iframe initially loads, the request has been Anonymize'd (user is not logged in) ... however, any subsequent request initiated within the iframe no longer gets Anonymize'd (because it is considered "from" bank.com) ... therefore simply clicking a link within the iframe logs the user in (this is assuming they didn't log out last time they accessed bank.com) ...

So evil.com can clickjack to log the user in, and then continue clickjacking after the user has been logged in to do evil things (this is assuming other protections against clickjacking are not enabled or have been bypassed (either of which is possible)).

If the behavior I have described is not a bug, could you please add a way for ABE to compare against the i/frame's parent?

This would also render [RFE] option to disable password filling for i/frames moot with respect to clickjacking.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

barbaz
Senior Member
Posts: 9279
Joined: Sat Aug 03, 2013 5:45 pm

Re: ABE should be able to compare against parent (bug? RFE?)

Post by barbaz » Tue Jul 07, 2015 7:12 pm

+1 but I personally think that it would make the most sense if SUB behave the way you're requesting but INCLUSION(SUBDOC) stay as-is, the request is not itself an inclusion but it is still a subdocument and it would give people the choice when writing rules, which kind of behavior they want...
*Always* check the changelogs BEFORE updating that important software!
-

RobertDrew
Junior Member
Posts: 32
Joined: Sun Jun 14, 2015 6:51 pm

Re: ABE should be able to compare against parent (bug? RFE?)

Post by RobertDrew » Tue Jul 07, 2015 7:38 pm

It might make the most sense to add an alternative to "from", such as "parent". This would also take care of the same ambiguity issue which applies to a ruleset which specifies "Accept ALL from SELF++" ahead of "Anonymize SUB" / "Anonymize INCLUSION(SUBDOC)"
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

barbaz
Senior Member
Posts: 9279
Joined: Sat Aug 03, 2013 5:45 pm

Re: ABE should be able to compare against parent (bug? RFE?)

Post by barbaz » Tue Jul 07, 2015 7:41 pm

I was thinking assuming the syntax doesn't change. Can you please post an example rule to show how what you're thinking would look?
*Always* check the changelogs BEFORE updating that important software!
-

RobertDrew
Junior Member
Posts: 32
Joined: Sun Jun 14, 2015 6:51 pm

Re: ABE should be able to compare against parent (bug? RFE?)

Post by RobertDrew » Tue Jul 07, 2015 7:47 pm

Code: Select all

Site *
Accept SUB parent SELF++
Anonymize SUB

Code: Select all

Site *
Accept INCLUSION(SUBDOC) parent SELF++
Anonymize INCLUSION(SUBDOC)

Code: Select all

Site *
Accept ALL parent SELF++
Anonymize SUB

Code: Select all

Site *
Accept ALL parent SELF++
Anonymize INCLUSION(SUBDOC)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0

Post Reply