WebApp Sec mailing list archives

RE: Defining scope of web application pentest


From: "Debasis Mohanty" <debasis.mohanty.listmails () gmail com>
Date: Sat, 15 Dec 2007 02:52:59 +0530

I always wanted to write something on this topic and was hoping to see
someone ask this question. 

many people follow different approach towards scoping and estimating efforts
required for assessing web-apps. Two most widely followed approaches are: 

I) based on the app size (small, medium or large) follow a standard estimate
(like 40-50hr for small sized app, 80-100hr for medium sized app etc). 

II) Random estimation of hours purely based on the tester's skills,
efficiency and experience. For example: one tester may quote 50hrs for an
assessment while another may quote 80 hrs for the same app. 

However, the above two approaches are subjective. They are never consistent
and do not guarantee maximum coverage of security assessment. I have my own
approach towards estimation which I used to use during my old days of
pentesting webapps. This approach is purely quantitative and every single
hour estimated can be justified. I'll assume here that your websecurity
assessment will be a hybrid approach using both manual methods and tools
based testing. 

Below are few list of important parameters which impacts the estimation /
scoping: 

a) No. of crawlable (reachable) links withing the app
b) No. of GET & POST parameters
c) No. of roles and privileges in the app
d) Authentication / Authorisation
e) No. of functional areas (admin functions, users functions etc)
f) Underlying technologies (AJAX, SWING, HIBERNATE etc)
g) Web Services (if any?)
f) ... etc ... etc

Just to give an example, lets take point (b). From The count of GET and POST
parameters, you would come to know how many SQL Injection, XSS or parameters
tampering tests you can perform. Let say the count of POST parameters is 140
and GET is 60, then assuming you have to run 5 different variants of XSS for
all these parameters, it will turn out to be 1000 (=5*(140+60)). It would be
a tedious job to try all tests manually so you may like to write a quick
script in perl/python to automate theses tests to speed it up. Hence, you
may reduce on time. 

Note: to get a count of GET or POST paramters, you may have to use a good
crawler which will have option for authenticating to the app and then crawl
for the urls and parameters. Almost all decent crawlers has this options.

another example, let say for estimating for privilege escalation tests you
need to have a well defined matrix of roles v/s privileges matrix (point #c)
from that you can derive how many tests you have to perform for testing
priviledge escalation. 

Once you get a count of number of tests to be performed then you can easily
estimate nearly accurate time required to perform those tests. For example,
in case of performing xss test the above count came to 1000. If I use an
automated script, it may take around 20 - 30 mins where as if I perform all
manual it may take one man day (8hrs). One can optimise it and do further
time slicing to reduce the number of hours for test.
 
Besides the above paramters for estimation there are other parameters like -

- Report compilation
- Other tests (not listed above)
- Buffers etc... 

I developed a tool sometime back in 2004 to do such estimation which i have
kept very much private to myself (an USP for my consulting). However, I
thought it is a good opportunity to throw some light on this topic when
someone has brought up this question. Possibly, I'll put up a paper sometime
next month with more details about it. 


hope it helps... -d



Vishal Garg wrote:

Hi,

Can anyone please tell what needs to be considered while defining the 
scope of a web application penetration test. Here I am concerned only 
about the web application and the web server that would exclude every 
other bit related to the infrastructure (such as firewall or a proxy 
etc). Also how do we calculate the effort required to test a web 
application. The things which I think may be considered are the number 
of static and dynamic pages and types of users involved etc. But what 
else can be considered?

Any inputs would be highly appreciated.

Cheers
Vishal


-------------------------------------------------------------------------
Sponsored by: Watchfire 
Methodologies & Tools for Web Application Security Assessment 
With the rapid rise in the number and types of security threats, web application security assessments should be 
considered a crucial phase in the development of any web application. What methodology should be followed? What tools 
can accelerate the assessment process? Download this Whitepaper today! 

https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------


Current thread: