1BO4r2U
1BO4r2U
1BO4r2U
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
81 82<br />
Web Application Penetration Testing<br />
Web Application Penetration Testing<br />
different objects (such as purchase information, private messages,<br />
etc.), and (if relevant) users with different privileges (for example<br />
administrator users) to see whether there are direct references to<br />
application functionality. By having multiple users the tester saves<br />
valuable testing time in guessing different object names as he can<br />
attempt to access objects that belong to the other user.<br />
Below are several typical scenarios for this vulnerability and the<br />
methods to test for each:<br />
The value of a parameter is used directly to retrieve a database<br />
record<br />
Sample request:<br />
The value of a parameter is used directly to retrieve a file system<br />
resource<br />
Sample request:<br />
In this case, the value of the file parameter is used to tell the applihttp:/foo.bar/somepage?invoice=12345<br />
In this case, the value of the invoice parameter is used as an index<br />
in an invoices table in the database. The application takes the<br />
value of this parameter and uses it in a query to the database. The<br />
application then returns the invoice information to the user.<br />
Since the value of invoice goes directly into the query, by modifying<br />
the value of the parameter it is possible to retrieve any invoice<br />
object, regardless of the user to whom the invoice belongs.<br />
To test for this case the tester should obtain the identifier of an<br />
invoice belonging to a different test user (ensuring he is not supposed<br />
to view this information per application business logic), and<br />
then check whether it is possible to access objects without authorization.<br />
The value of a parameter is used directly to perform an operation<br />
in the system<br />
http:/foo.bar/changepassword?user=someuser<br />
Sample request:<br />
In this case, the value of the user parameter is used to tell the<br />
application for which user it should change the password. In many<br />
cases this step will be a part of a wizard, or a multi-step operation.<br />
In the first step the application will get a request stating for which<br />
user’s password is to be changed, and in the next step the user<br />
will provide a new password (without asking for the current one).<br />
The user parameter is used to directly reference the object of the<br />
user for whom the password change operation will be performed.<br />
To test for this case the tester should attempt to provide a different<br />
test username than the one currently logged in, and check<br />
whether it is possible to modify the password of another user.<br />
http:/foo.bar/showImage?img=img00011<br />
cation what file the user intends to retrieve. By providing the name<br />
or identifier of a different file (for example file=image00012.jpg) the<br />
attacker will be able to retrieve objects belonging to other users.<br />
To test for this case, the tester should obtain a reference the user is<br />
not supposed to be able to access and attempt to access it by using<br />
it as the value of file parameter. Note: This vulnerability is often exploited<br />
in conjunction with a directory/path traversal vulnerability (see<br />
Testing for Path Traversal)<br />
The value of a parameter is used directly to access application functionality<br />
Sample request:<br />
http:/foo.bar/accessPage?menuitem=12<br />
In this case, the value of the menuitem parameter is used to tell the<br />
application which menu item (and therefore which application functionality)<br />
the user is attempting to access. Assume the user is supposed<br />
to be restricted and therefore has links available only to access<br />
to menu items 1, 2 and 3. By modifying the value of menuitem parameter<br />
it is possible to bypass authorization and access additional application<br />
functionality. To test for this case the tester identifies a location<br />
where application functionality is determined by reference to a menu<br />
item, maps the values of menu items the given test user can access,<br />
and then attempts other menu items.<br />
In the above examples the modification of a single parameter is sufficient.<br />
However, sometimes the object reference may be split between<br />
more than one parameter, and testing should be adjusted accordingly.<br />
References<br />
Top 10 2013-A4-Insecure Direct Object References<br />
Session Management Testing<br />
One of the core components of any web-based application is the<br />
mechanism by which it controls and maintains the state for a user interacting<br />
with it. This is referred to this as Session Management and<br />
is defined as the set of all controls governing state-full interaction between<br />
a user and the web-based application. This broadly covers anything<br />
from how user authentication is performed, to what happens<br />
upon them logging out.<br />
HTTP is a stateless protocol, meaning that web servers respond to<br />
client requests without linking them to each other. Even simple application<br />
logic requires a user’s multiple requests to be associated with<br />
each other across a “session”. This necessitates third party solutions<br />
– through either Off-The-Shelf (OTS) middleware and web server<br />
solutions, or bespoke developer implementations. Most popular web<br />
application environments, such as ASP and PHP, provide developers<br />
with built-in session handling routines. Some kind of identification token<br />
will typically be issued, which will be referred to as a “Session ID”<br />
or Cookie.<br />
There are a number of ways in which a web application may interact<br />
with a user. Each is dependent upon the nature of the site, the security,<br />
and availability requirements of the application. Whilst there are<br />
accepted best practices for application development, such as those<br />
outlined in the OWASP Guide to Building Secure Web Applications, it<br />
is important that application security is considered within the context<br />
of the provider’s requirements and expectations.<br />
Testing for Session Management Schema<br />
(OTG-SESS-001)<br />
Summary<br />
In order to avoid continuous authentication for each page of a website<br />
or service, web applications implement various mechanisms to<br />
store and validate credentials for a pre-determined timespan. These<br />
mechanisms are known as Session Management and while they are<br />
important in order to increase the ease of use and user-friendliness<br />
of the application, they can be exploited by a penetration tester to<br />
gain access to a user account, without the need to provide correct<br />
credentials.<br />
In this test, the tester wants to check that cookies and other session<br />
tokens are created in a secure and unpredictable way. An attacker<br />
who is able to predict and forge a weak cookie can easily hijack the<br />
sessions of legitimate users.<br />
Cookies are used to implement session management and are described<br />
in detail in RFC 2965. In a nutshell, when a user accesses an<br />
application which needs to keep track of the actions and identity of<br />
that user across multiple requests, a cookie (or cookies) is generated<br />
by the server and sent to the client. The client will then send the<br />
cookie back to the server in all following connections until the cookie<br />
expires or is destroyed. The data stored in the cookie can provide<br />
to the server a large spectrum of information about who the user is,<br />
what actions he has performed so far, what his preferences are, etc.<br />
therefore providing a state to a stateless protocol like HTTP.<br />
A typical example is provided by an online shopping cart. Throughout<br />
the session of a user, the application must keep track of his identity,<br />
his profile, the products that he has chosen to buy, the quantity, the<br />
individual prices, the discounts, etc. Cookies are an efficient way to<br />
store and pass this information back and forth (other methods are<br />
URL parameters and hidden fields).<br />
Due to the importance of the data that they store, cookies are therefore<br />
vital in the overall security of the application. Being able to tamper<br />
with cookies may result in hijacking the sessions of legitimate<br />
users, gaining higher privileges in an active session, and in general<br />
influencing the operations of the application in an unauthorized way.<br />
In this test the tester has to check whether the cookies issued to clients<br />
can resist a wide range of attacks aimed to interfere with the<br />
sessions of legitimate users and with the application itself. The overall<br />
goal is to be able to forge a cookie that will be considered valid<br />
by the application and that will provide some kind of unauthorized<br />
access (session hijacking, privilege escalation, ...).<br />
Usually the main steps of the attack pattern are the following:<br />
• cookie collection: collection of a sufficient number of cookie samples;<br />
• cookie reverse engineering: analysis of the cookie generation algorithm;<br />
• cookie manipulation: forging of a valid cookie in order to perform the<br />
attack. This last step might require a large number of attempts, depending<br />
on how the cookie is created (cookie brute-force attack).<br />
Another pattern of attack consists of overflowing a cookie. Strictly<br />
speaking, this attack has a different nature, since here testers are not<br />
trying to recreate a perfectly valid cookie. Instead, the goal is to overflow<br />
a memory area, thereby interfering with the correct behavior of<br />
the application and possibly injecting (and remotely executing) malicious<br />
code.<br />
How to Test<br />
Black Box Testing and Examples<br />
All interaction between the client and application should be tested at<br />
least against the following criteria:<br />
• Are all Set-Cookie directives tagged as Secure?<br />
• Do any Cookie operations take place over unencrypted transport?<br />
• Can the Cookie be forced over unencrypted transport?<br />
• If so, how does the application maintain security?<br />
• Are any Cookies persistent?<br />
• What Expires= times are used on persistent cookies, and are they<br />
reasonable?<br />
• Are cookies that are expected to be transient configured as such?<br />
• What HTTP/1.1 Cache-Control settings are used to protect Cookies?<br />
• What HTTP/1.0 Cache-Control settings are used to protect Cookies?<br />
Cookie collection<br />
The first step required to manipulate the cookie is to understand how<br />
the application creates and manages cookies. For this task, testers<br />
have to try to answer the following questions:<br />
• How many cookies are used by the application?<br />
Surf the application. Note when cookies are created. Make a list of received<br />
cookies, the page that sets them (with the set-cookie directive),<br />
the domain for which they are valid, their value, and their characteristics.<br />
• Which parts of the the application generate and/or modify the cookie?<br />
Surfing the application, find which cookies remain constant and which<br />
get modified. What events modify the cookie?<br />
• Which parts of the application require this cookie in order to be accessed<br />
and utilized?<br />
Find out which parts of the application need a cookie. Access a page,<br />
then try again without the cookie, or with a modified value of it. Try to<br />
map which cookies are used where.<br />
A spreadsheet mapping each cookie to the corresponding application<br />
parts and the related information can be a valuable output of this<br />
phase.<br />
Session Analysis<br />
The session tokens (Cookie, SessionID or Hidden Field) themselves<br />
should be examined to ensure their quality from a security perspective.<br />
They should be tested against criteria such as their randomness,<br />
uniqueness, resistance to statistical and cryptographic analysis and<br />
information leakage.<br />
• Token Structure & Information Leakage<br />
The first stage is to examine the structure and content of a Session ID<br />
provided by the application. A common mistake is to include specific