rules.abe

Bug reports and enhancement requests
Post Reply
dhouwn
Bug Buster
Posts: 968
Joined: Thu Mar 19, 2009 12:51 pm

rules.abe

Post by dhouwn » Sun Jun 14, 2009 6:37 pm

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?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b99) Gecko/20090611 Firefox/3.5b99

User avatar
Giorgio Maone
Site Admin
Posts: 8802
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: rules.abe

Post by Giorgio Maone » Sun Jun 14, 2009 7:03 pm

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.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3343
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: rules.abe

Post by GµårÐïåñ » Mon Jun 15, 2009 8:49 am

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?
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

User avatar
Giorgio Maone
Site Admin
Posts: 8802
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: rules.abe

Post by Giorgio Maone » Mon Jun 15, 2009 9:19 am

GµårÐïåñ wrote: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.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3343
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: rules.abe

Post by GµårÐïåñ » Mon Jun 15, 2009 9:38 am

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. :oops:
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

nagan
Senior Member
Posts: 340
Joined: Thu Mar 26, 2009 11:05 am

Re: rules.abe

Post by nagan » Mon Jun 15, 2009 11:02 am

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
Dreams are REAL possibilities. Pursue them with zest and you can make them HAPPEN!
You are GOD.Realize THAT!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

User avatar
Giorgio Maone
Site Admin
Posts: 8802
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: rules.abe

Post by Giorgio Maone » Mon Jun 15, 2009 11:37 am

nagan wrote: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.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

Post Reply