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
------------------------------------------------------------------------
