Re: Pen testing techniques

[vtlists () wyae de]

Atif Azim writes:
> The client's website offers a place for legitimate users (I cannot
> become that legitimate user) to login and do their respective tasks.So
> what is available to me as a pen tester is only the user ID and
> password field to play with :)

Which "fields" - HTTP basic/digest authentication (the popup window) or an 
application web page?

If the authentication is application based, you should have a look at the 
HTTP source code and the HTTP headers exchanged. 

I've seen "authentication" that was JavaScript based, "authtentication" that 
just checked for the existence of a general cookie (if "logged_in" cookie 
set, then login - even one: deny access if "not_authenticated" cookie is 
set), but also tough authentication that simply was a plain HTTP form with 
two text fields plus a cryptographically sound session ID. 

Is there information leakage? Analyze "unauthorized" vs. "unknown 
user"/"wrong password" messages, the latter revealing whether you found
a known user account. 

Are there lockout routines which could be abused to let the application DoS 
itself?

Then you have HTTP request splitting and header manipulation attacks (ever 
tried to overwrite the login routine with "PUT"?) There can be a lot to play 
with even if only one page is visible... 
in the first step... 
;-)

But then again you run across the tough stuff. Plain input fields with no 
hint whatsoever, bastioned and well-maintained server, sane auto-lockouts, 
strict session-management, clean crypto, etc. - all you want to see. 
Well, except when you are the one trying to break in...

Bye

Volker



------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------