4.0

73
Web Application Penetration Testing
Tools
• WebScarab
• WebGoat
• OWASP Zed Attack Proxy (ZAP)
References
Whitepapers
• Mark Roxberry: “PHPBB 2.0.13 vulnerability”
• David Endler: “Session ID Brute Force Exploitation and Prediction”
- http: /www.cgisecurity.com/lib/SessionIDs.pdf
Testing for Vulnerable Remember Password
(OTG-AUTHN-005)
Summary
Browsers will sometimes ask a user if they wish to remember the
password that they just entered. The browser will then store the
password, and automatically enter it whenever the same authentication
form is visited. This is a convenience for the user.
Additionally some websites will offer custom “remember me”
functionality to allow users to persist log ins on a specific client
system.
Having the browser store passwords is not only a convenience
for end-users, but also for an attacker. If an attacker can gain access
to the victim’s browser (e.g. through a Cross Site Scripting
attack, or through a shared computer), then they can retrieve the
stored passwords. It is not uncommon for browsers to store these
passwords in an easily retrievable manner, but even if the browser
were to store the passwords encrypted and only retrievable
through the use of a master password, an attacker could retrieve
the password by visiting the target web application’s authentication
form, entering the victim’s username, and letting the browser
to enter the password.
Additionally where custom “remember me” functions are put in
place weaknesses in how the token is stored on the client PC (for
example using base64 encoded credentials as the token) could
expose the users passwords. Since early 2014 most major browsers
will override any use of autocomplete=”off” with regards to
password forms and as a result previous checks for this are not
required and recommendations should not commonly be given for
disabling this feature. However this can still apply to things like
secondary secrets which may be stored in the browser inadvertently.
How to Test
• Look for passwords being stored in a cookie.
Examine the cookies stored by the application.
Verify that the credentials are not stored in clear text, but are
hashed.
• Examine the hashing mechanism: if it is a common, well-known
algorithm, check for its strength; in homegrown hash functions,
attempt several usernames to check whether the hash function
is easily guessable.
• Verify that the credentials are only sent during the log
in phase, and not sent together with every request
to the application.
• Consider other sensitive form fields (e.g. an answer to a secret
question that must be entered in a password recovery
or account unlock form).
Remediation
Ensure that no credentials are stored in clear text or are easily retrievable
in encoded or encrypted forms in cookies.
Testing for Browser cache weakness
(OTG-AUTHN-006)
Summary
In this phase the tester checks that the application correctly instructs
the browser to not remember sensitive data.
Browsers can store information for purposes of caching and history.
Caching is used to improve performance, so that previously
displayed information doesn’t need to be downloaded again.
History mechanisms are used for user convenience, so the user
can see exactly what they saw at the time when the resource was
retrieved. If sensitive information is displayed to the user (such
as their address, credit card details, Social Security Number, or
username), then this information could be stored for purposes of
caching or history, and therefore retrievable through examining
the browser’s cache or by simply pressing the browser’s “Back”
button.
How to Test
Browser History
Technically, the “Back” button is a history and not a cache (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13).
The cache and the history are two different entities.
However, they share the same weakness of presenting previously
displayed sensitive information.
The first and simplest test consists of entering sensitive information
into the application and logging out. Then the tester clicks
the “Back” button of the browser to check whether previously
displayed sensitive information can be accessed whilst unauthenticated.
If by pressing the “Back” button the tester can access previous
pages but not access new ones, then it is not an authentication
issue, but a browser history issue. If these pages contain sensitive
data, it means that the application did not forbid the browser from
storing it.
Authentication does not necessarily need to be involved in the
testing. For example, when a user enters their email address in
order to sign up to a newsletter, this information could be retrievable
if not properly handled.
The “Back” button can be stopped from showing sensitive data.
This can be done by:
• Delivering the page over HTTPS.
• Setting Cache-Control: must-re-validate
Browser Cache
Here testers check that the application does not leak any sensitive
data into the browser cache. In order to do that, they can
use a proxy (such as WebScarab) and search through the server
responses that belong to the session, checking that for every
page that contains sensitive information the server instructed the
browser not to cache any data. Such a directive can be issued in
the HTTP response headers: