4.0

65
Web Application Penetration Testing
- Analyzing URLs and URLs re-directions
For example:
As is seen above, when a tester provides a user ID and password
to the web application, they see a message indication that an error
has occurred in the URL. In the first case they have provided a
bad user ID and bad password. In the second, a good user ID and
a bad password, so they can identify a valid user ID.
- URI Probing
Sometimes a web server responds differently if it receives a request
for an existing directory or not. For instance in some portals
every user is associated with a directory. If testers try to access
an existing directory they could receive a web server error.
A very common error that is received from web server is:
and
http:/www.foo.com/err.jsp?User=baduser&Error=0
http:/www.foo.com/err.jsp?User=gooduser&Error=2
403 Forbidden error code
404 Not found error code
Example
http:/www.foo.com/account1 - we receive from web server:
403 Forbidden
http:/www.foo.com/account2 - we receive from web server:
404 file Not Found
In the first case the user exists, but the tester cannot view the
web page, in second case instead the user “account2” does not
exist. By collecting this information testers can enumerate the
users.
- Analyzing Web page Titles
Testers can receive useful information on Title of web page,
where they can obtain a specific error code or messages that reveal
if the problems are with the username or password.
For instance, if a user cannot authenticate to an application and
receives a web page whose title is similar to:
Invalid user
Invalid authentication
- Analyzing a message received from a recovery facility
When we use a recovery facility (i.e. a forgotten password func-
tion) a vulnerable application might return a message that reveals
if a username exists or not.
For example, message similar to the following:
Invalid username: e-mail address is not valid or the specified
user was not found.
Valid username: Your password has been successfully sent to
the email address you registered with.
- Friendly 404 Error Message
When we request a user within the directory that does not exist,
we don’t always receive 404 error code. Instead, we may receive
“200 ok” with an image, in this case we can assume that when
we receive the specific image the user does not exist. This logic
can be applied to other web server response; the trick is a good
analysis of web server and web application messages.
Guessing Users
In some cases the user IDs are created with specific policies of
administrator or company. For example we can view a user with
a user ID created in sequential order:
CN000100
CN000101
….
Sometimes the usernames are created with a REALM alias and
then a sequential numbers:
R1001 – user 001 for REALM1
R2001 – user 001 for REALM2
In the above sample we can create simple shell scripts that compose
user IDs and submit a request with tool like wget to automate
a web query to discern valid user IDs. To create a script we
can also use Perl and CURL.
Other possibilities are: - user IDs associated with credit card
numbers, or in general numbers with a pattern. - user IDs associated
with real names, e.g. if Freddie Mercury has a user ID of
“fmercury”, then you might guess Roger Taylor to have the user
ID of “rtaylor”.
Again, we can guess a username from the information received
from an LDAP query or from Google information gathering, for
example, from a specific domain. Google can help to find domain
users through specific queries or through a simple shell script or
tool.
Attention: by enumerating user accounts, you risk locking out
accounts after a predefined number of failed probes (based
on application policy). Also, sometimes, your IP address can be
banned by dynamic rules on the application firewall or Intrusion
Prevention System.
Gray Box testing
Testing for Authentication error messages
Verify that the application answers in the same manner for ev-