rules.abe

[dhouwn]

Something I don't like about the functionality of "ABE for Web Authors" is the fact it automatically looks for the file "rules.abe" in the root path.
It reminds of the IE behavior regarding "favicon.ico". The logs of the web hosters might be filled up with requests leading to 404.

Alternative: Announcing via HTTP headers or meta tags in the source that this website is offering ABE rulesets (maybe also announcing the path to the ruleset file).

What do you think?

[Giorgio Maone]

It would have been much simpler for me to implement ruleset delivery that way (like CSP does), but unluckily using headers or other information coming from responses to arbitrary requests is not feasible, for a very simple reason: ABE's primary aim is defeating CSRF (Cross Site Request Forgery) attacks.

If a site wants to configure custom protection, its ruleset must be available from a fixed and secured location (i.e. https://site.com/ruleset.abe ), so ABE can perform a preflight request before any other (potentially dangerous/forged) request can be sent.

If ABE had to wait for headers to come down, the response carrying them could come too late, as an useless answer to the CSRF attack itself.

[GµårÐïåñ]

So alternatively, if someone breeches a site and modifies the rules.abe file, they can hijack the user and execute malicious code since ABE would honor it. No?

[Giorgio Maone]

So alternatively, if someone breeches a site and modifies the rules.abe file, they can hijack the user and execute malicious code since ABE would honor it. No?

No.

Site rules are low-priority, i.e. the SYSTEM rules run first, then the USER rules and finally, if found, site's rules.abe.
The first rule matching the request with a DENY statement aborts the connection and the processing.

Also, the site ruleset (rules.abe) applies exclusively to the site itself: all the "Site" statements not matching the current site are just discarded.
Therefore, if an attacker "breeches a site and modifies the rules.abe file", the maximum damage he can do is nullifying the protections given by the site itself (i.e. adding a "Site * ACCEPT" which is exactly equivalent to deleting rules.abe) or DOSing the site ("Site * DENY"), but he surely can't execute any additional malicious code because of ABE.
Nothing an attacker who can write arbitrary files on the root of a web site couldn't do anyway

However, setting for rules.abe the same permissions you would use for .htaccess is definitely a good idea:

Code: Select all

chown root rules.abe
chmod 644 rules.abe

[EDIT]:
Forgot, if you find a site is DOSed or otherwise broken because it has a buggy rules.abe (e.g. the "Site * DENY" above), you can just disable its ruleset from NoScript Options|Advanced|ABE.

[GµårÐïåñ]

I am sorry, consider it poor choice of words. Thank you for clarifying but what I meant was that if the page is pushing malicious code after being hacked and lowering the permissions through a ruleset could allow them more control. Of course nothing can be launched at root without more control and access. I promise next time to post when its not 3 AM and my head totally pounding so I can get it right.

[nagan]

I am not the wizard type...
I use a free firewall Online Armor ,using this I make FF run on the safe mode.Does this qualify to be equivalent to ABE protection ,as I find in the safe mode the root directories are completely OFF to the browser as is explained here

[Giorgio Maone]

I use a free firewall Online Armor ,using this I make FF run on the safe mode.Does this qualify to be equivalent to ABE protection

Nope. ABE's main target is preventing CSRF attacks: this can't be done at the firewall level, since the firewall is not aware of HTTP context (and especially origin).
At this moment the only places where you can effectively prevent CSRF are the web application (server side) and the browser.
The only browser technology similar to ABE that I know aiming at CSRF protection is the Request Policy extension, which is very easy to operate (modeled on NoScript's UI) but not as flexible as ABE.