1BO4r2U

71 72
Web Application Penetration Testing
Web Application Penetration Testing
The majority of pre-generated questions are fairly simplistic in nature
and can lead to insecure answers. For example:
• The answers may be known to family members or close friends of
the user, e.g. “What is your mother’s maiden name?”, “What is your
date of birth?”
• The answers may be easily guessable, e.g. “What is your favorite color?”,
“What is your favorite baseball team?”
• The answers may be brute forcible, e.g. “What is the first name of
your favorite high school teacher?” - the answer is probably on some
easily downloadable lists of popular first names, and therefore a simple
brute force attack can be scripted.
• The answers may be publicly discoverable, e.g. “What is your favorite
movie?” - the answer may easily be found on the user’s social media
profile page.
Self-generated questions:
The problem with having users to generate their own questions is that
it allows them to generate very insecure questions, or even bypass the
whole point of having a security question in the first place. Here are
some real world examples that illustrate this point:
• “What is 1+1?”
• “What is your username?”
• “My password is M3@t$p1N”
How to Test
Testing for weak pre-generated questions:
Try to obtain a list of security questions by creating a new account or
by following the “I don’t remember my password”-process. Try to generate
as many questions as possible to get a good idea of the type
of security questions that are asked. If any of the security questions
fall in the categories described above, they are vulnerable to being attacked
(guessed, brute-forced, available on social media, etc.).
Testing for weak self-generated questions:
Try to create security questions by creating a new account or by configuring
your existing account’s password recovery properties. If the
system allows the user to generate their own security questions, it is
vulnerable to having insecure questions created. If the system uses
the self-generated security questions during the forgotten password
functionality and if usernames can be enumerated (see Testing for Account
Enumeration and Guessable User Account (OTG-IDENT-004)),
then it should be easy for the tester to enumerate a number of
self-generated questions. It should be expected to find several weak
self-generated questions using this method.
Testing for brute-forcible answers:
Use the methods described in Testing for Weak lock out mechanism
(OTG-AUTHN-003) to determine if a number of incorrectly supplied
security answers trigger a lockout mechanism.
The first thing to take into consideration when trying to exploit security
questions is the number of questions that need to be answered.
The majority of applications only need the user to answer a single
question, whereas some critical applications may require the user to
answer two or even more questions.
The next step is to assess the strength of the security questions. Could
the answers be obtained by a simple Google search or with social engineering
attack? As a penetration tester, here is a step-by-step walkthrough
of exploiting a security question scheme:
[1] Does the application allow the end-user to choose the question
that needs to be answered? If so, focus on questions which have:
• A “public” answer; for example, something that could be find with a
simple search-engine query.
• A factual answer such as a “first school” or other facts which can be
looked up.
• Few possible answers, such as “what model was your first car”.
These questions would present the attacker with a short list of possible
answers, and based on statistics the attacker could rank answers
from most to least likely.
[2] Determine how many guesses you have if possible.
• Does the password reset allow unlimited attempts?
• Is there a lockout period after X incorrect answers? Keep in mind that
a lockout system can be a security problem in itself, as it can be exploited
by an attacker to launch a Denial of Service against legitimate
users.
[3] Pick the appropriate question based on analysis from the above
points, and do research to determine the most likely answers.
The key to successfully exploiting and bypassing a weak security
question scheme is to find a question or set of questions which give
the possibility of easily finding the answers. Always look for questions
which can give you the greatest statistical chance of guessing the correct
answer, if you are completely unsure of any of the answers. In
the end, a security question scheme is only as strong as the weakest
question.
References
The Curse of the Secret Question
Testing for weak password change or reset
functionalities (OTG-AUTHN-009)
Summary
The password change and reset function of an application is a self-service
password change or reset mechanism for users. This self-service
mechanism allows users to quickly change or reset their password
without an administrator intervening. When passwords are changed
they are typically changed within the application. When passwords are
reset they are either rendered within the application or emailed to the
user. This may indicate that the passwords are stored in plain text or
in a decryptable format.
Test objectives
[1] Determine the resistance of the application to subversion of the
account change process allowing someone to change the password
of an account.
[2] Determine the resistance of the passwords reset functionality
against guessing or bypassing.
How to Test
For both password change and password reset it is important to check:
[1] if users, other than administrators, can change or reset passwords
for accounts other than their own.
[2] if users can manipulate or subvert the password change or reset
process to change or reset the password of another user or administrator.
[3] if the password change or reset process is vulnerable to CSRF.
Test Password Reset
In addition to the previous checks it is important to verify the following:
• What information is required to reset the password?
The first step is to check whether secret questions are required.
Sending the password (or a password reset link) to the user email
address without first asking for a secret question means relying
100% on the security of that email address, which is not suitable if
the application needs a high level of security.
On the other hand, if secret questions are used, the next step is to
assess their strength. This specific test is discussed in detail in the
Testing for Weak security question/answer paragraph of this guide.
• How are reset passwords communicated to the user?
The most insecure scenario here is if the password reset tool shows
you the password; this gives the attacker the ability to log into the
account, and unless the application provides information about the
last log in the victim would not know that their account has been
compromised.
A less insecure scenario is if the password reset tool forces the user
to immediately change their password. While not as stealthy as the
first case, it allows the attacker to gain access and locks the real
user out.
The best security is achieved if the password reset is done via an
email to the address the user initially registered with, or some other
email address; this forces the attacker to not only guess at which
email account the password reset was sent to (unless the application
show this information) but also to compromise that email account
in order to obtain the temporary password or the password
reset link.
• Are reset passwords generated randomly?
The most insecure scenario here is if the application sends or visualizes
the old password in clear text because this means that passwords
are not stored in a hashed form, which is a security issue in itself.
The best security is achieved if passwords are randomly generated
with a secure algorithm that cannot be derived.
• Is the reset password functionality requesting confirmation before
changing the password?
To limit denial-of-service attacks the application should email a link
to the user with a random token, and only if the user visits the link
then the reset procedure is completed. This ensures that the current
password will still be valid until the reset has been confirmed.
Test Password Change
In addition to the previous test it is important to verify:
• Is the old password requested to complete the change?
The most insecure scenario here is if the application permits the
change of the password without requesting the current password.
Indeed if an attacker is able to take control of a valid session they
could easily change the victim’s password.
See also Testing for Weak password policy paragraph of this guide.
References
• OWASP Forgot Password Cheat Sheet
• OWASP Periodic Table of Vulnerabilities - Insufficient Password
Recovery
Remediation
The password change or reset function is a sensitive function and
requires some form of protection, such as requiring users to re-authenticate
or presenting the user with confirmation screens during
the process.
Testing for Weaker authentication in alternative
channel (OTG-AUTHN-010)
Summary
Even if the primary authentication mechanisms do not include any
vulnerabilities, it may be that vulnerabilities exist in alternative legitimate
authentication user channels for the same user accounts.
Tests should be undertaken to identify alternative channels and,
subject to test scoping, identify vulnerabilities.
The alternative user interaction channels could be utilized to circumvent
the primary channel, or expose information that can then
be used to assist an attack against the primary channel. Some of
these channels may themselves be separate web applications using
different host names or paths. For example:
• Standard website
• Mobile, or specific device, optimized website
• Accessibility optimized website
• Alternative country and language websites
• Parallel websites that utilize the same user accounts (e.g. another
website offering different functionally of the same organization, a
partner website with which user accounts are shared)
• Development, test, UAT and staging versions of the standard
website
But they could also be other types of application or business processes:
• Mobile device app
• Desktop application
• Call center operators
• Interactive voice response or phone tree systems
Note that the focus of this test is on alternative channels; some
authentication alternatives might appear as different content delivered
via the same website and would almost certainly be in scope
for testing. These are not discussed further here, and should have
been identified during information gathering and primary authentication
testing. For example:
• Progressive enrichment and graceful degradation that change
functionality
• Site use without cookies
• Site use without JavaScript
• Site use without plugins such as for Flash and Java
Even if the scope of the test does not allow the alternative channels
to be tested, their existence should be documented. These may undermine
the degree of assurance in the authentication mechanisms
and may be a precursor to additional testing.
Example