[Owasp-access-control-rules-tester-project] Access Control Rules Tester review

OWASP Access Control Rules Tester Project owasp-access-control-rules-tester-project at lists.owasp.org
Thu Oct 9 09:54:33 EDT 2008

Hi All,

This is a good start. The algorithm, design, and the tool are in good shape. Well done Andrew.

It's not uncommon to change the design or requirement during the implementation phase, it would be nice to update the project requirement to reflect the real implementation.


----- Original Message ----
From: Andrew Petukhov <petand at lvk.cs.msu.su>
To: Min Chen <mg_chen at yahoo.com>
Cc: owasp-access-control-rules-tester-project at lists.owasp.org
Sent: Wednesday, October 8, 2008 12:16:23 PM
Subject: Re: Access Control Rules Tester review

 Min Chen wrote:

Two things seem missing:

1. The document does not clearly answer "Is it possible to build precise access control matrix for a web application and how"

2. I can't find Rhino library or source code in the tool, did I miss somthing?


1. The model, which I utilize is built on the concept of resource.
Resource is URI, and actions are read (GET) and execute/write (POST).
This scope of view is induced from the black box testing requirement. 
In this terms, the access control matrix in CURRENT web application
state is the mapping USER * URI * {GET, POST} -> {allow, deny}
Of course, this matrix can change.
My document gives procedures how to record use case dependency graph
for a group of users (one user per role). 
But in the terms stated above these recordings form a sequence of the
access control matrices perceived by users. 
The question is - how to obtain the sequence of real access
control matrices? The answer is:
- union all perceived matrices;
- probe for all resources from current user at current state.
My tool gives in the report the set of resources that are included in
the real access matrix that are not contained in the percieved access matrix.

Do I speak clear? 
Maybe I should add this remarks at the end of my formal document?

2. Rhino. This was intended as a JavaScript processing part of web
spider that I was going to develop. Initially, I was going to include
web spider as a part of my tool. However, the spider part appeared to
be too complex. As a result a combination of existing tools
was chosen that is able to perform the Sitemap generation according to
the developed method. Thus, the Spider module was not developed: it saved time and effort, and another Spider-clone with the
same functionality was not set free. However, AJAX and Javascript web
application still require manual navigation (if they contain resource
that are not accessible via static links). The development of
fully-enabled Javascript spider appeared to be a significant work.
However, the initial P022 proposal did not contain the strict
requirement for a spider: http://www.owasp.org/index.php/OWASP_Request_for_Proposal_List#P022_-_OWASP_Access_Control_Rules_Tester

After my experience, I would say that AcCoRuTe should not be integrated
with the spider. But, the javascript-enabled spider should be developed
instead of Burp Spider currently in use.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-access-control-rules-tester-project/attachments/20081009/045ecc89/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 9858 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-access-control-rules-tester-project/attachments/20081009/045ecc89/attachment-0001.jpe 

More information about the Owasp-access-control-rules-tester-project mailing list