4.0

85
Web Application Penetration Testing
In this case, the value of the user parameter is used to tell the
application for which user it should change the password. In many
cases this step will be a part of a wizard, or a multi-step operation.
In the first step the application will get a request stating for which
user’s password is to be changed, and in the next step the user
will provide a new password (without asking for the current one).
The user parameter is used to directly reference the object of the
user for whom the password change operation will be performed.
To test for this case the tester should attempt to provide a different
test username than the one currently logged in, and check
whether it is possible to modify the password of another user.
The value of a parameter is used directly to retrieve a file system
resource
Sample request:
http: /foo.bar/showImage?img=img00011
In this case, the value of the file parameter is used to tell the application
what file the user intends to retrieve. By providing the
name or identifier of a different file (for example file=image00012.
jpg) the attacker will be able to retrieve objects belonging to other
users.
To test for this case, the tester should obtain a reference the user
is not supposed to be able to access and attempt to access it by
using it as the value of file parameter. Note: This vulnerability is
often exploited in conjunction with a directory/path traversal vulnerability
(see Testing for Path Traversal)
The value of a parameter is used directly to access application
functionality
Sample request:
http: /foo.bar/accessPage?menuitem=12
In this case, the value of the menuitem parameter is used to tell
the application which menu item (and therefore which application
functionality) the user is attempting to access. Assume the user is
supposed to be restricted and therefore has links available only to
access to menu items 1, 2 and 3. By modifying the value of menuitem
parameter it is possible to bypass authorization and access
additional application functionality. To test for this case the tester
identifies a location where application functionality is determined
by reference to a menu item, maps the values of menu items the
given test user can access, and then attempts other menu items.
In the above examples the modification of a single parameter is
sufficient. However, sometimes the object reference may be split
between more than one parameter, and testing should be adjusted
accordingly.
References
Top 10 2013-A4-Insecure Direct Object References
Session Management Testing
One of the core components of any web-based application is the
mechanism by which it controls and maintains the state for a user in-
teracting with it. This is referred to this as Session Management and
is defined as the set of all controls governing state-full interaction between
a user and the web-based application. This broadly covers anything
from how user authentication is performed, to what happens
upon them logging out.
HTTP is a stateless protocol, meaning that web servers respond to
client requests without linking them to each other. Even simple application
logic requires a user’s multiple requests to be associated with
each other across a “session”. This necessitates third party solutions
– through either Off-The-Shelf (OTS) middleware and web server
solutions, or bespoke developer implementations. Most popular web
application environments, such as ASP and PHP, provide developers
with built-in session handling routines. Some kind of identification token
will typically be issued, which will be referred to as a “Session ID”
or Cookie.
There are a number of ways in which a web application may interact
with a user. Each is dependent upon the nature of the site, the security,
and availability requirements of the application. Whilst there are
accepted best practices for application development, such as those
outlined in the OWASP Guide to Building Secure Web Applications, it
is important that application security is considered within the context
of the provider’s requirements and expectations.
Testing for Session Management Schema
(OTG-SESS-001)
Summary
In order to avoid continuous authentication for each page of a website
or service, web applications implement various mechanisms to
store and validate credentials for a pre-determined timespan. These
mechanisms are known as Session Management and while they are
important in order to increase the ease of use and user-friendliness
of the application, they can be exploited by a penetration tester to
gain access to a user account, without the need to provide correct
credentials.
In this test, the tester wants to check that cookies and other session
tokens are created in a secure and unpredictable way. An attacker
who is able to predict and forge a weak cookie can easily hijack the
sessions of legitimate users.
Cookies are used to implement session management and are described
in detail in RFC 2965. In a nutshell, when a user accesses an
application which needs to keep track of the actions and identity of
that user across multiple requests, a cookie (or cookies) is generated
by the server and sent to the client. The client will then send the
cookie back to the server in all following connections until the cookie
expires or is destroyed. The data stored in the cookie can provide
to the server a large spectrum of information about who the user is,
what actions he has performed so far, what his preferences are, etc.
therefore providing a state to a stateless protocol like HTTP.
A typical example is provided by an online shopping cart. Throughout
the session of a user, the application must keep track of his identity,
his profile, the products that he has chosen to buy, the quantity, the
individual prices, the discounts, etc. Cookies are an efficient way to
store and pass this information back and forth (other methods are
URL parameters and hidden fields).
Due to the importance of the data that they store, cookies are there-