the-web-application-hackers-handbook

Chapter 21 n A Web Application Hacker’s Methodology 823
6.3.2 In your application mapping exercises that use a low-privileged account,
you may have identified the URLs for privileged functions such as
administrative interfaces. If these are not adequately protected, you will
probably already know about this.
6.3.3 Decompile all compiled clients that are present, and extract any references
to server-side functionality.
6.3.4 Most data that is subject to horizontal access controls is accessed using
an identifier, such as an account number or order reference. To test
whether access controls are effective using only a single account, you
must try to guess or discover the identifiers associated with other users’
data. If possible, generate a series of identifiers in quick succession
(for example, by creating several new orders). Attempt to identify any
patterns that may enable you to predict the identifiers issued to other
users. If there is no way to generate new identifiers, you are probably
restricted to analyzing those you already have and guessing on that
basis.
6.3.5 If you find a way to predict the identifiers issued to other users, use the
techniques described in Chapter 14 to mount an automated attack to
harvest interesting data belonging to other users. Use the Extract Grep
function in Burp Intruder to capture the relevant information from within
the application’s responses.
6.4 Test for Insecure Access Control Methods
6.4.1 Some applications implement access controls based on request
parameters in an inherently unsafe way. Look for parameters such
as edit=false or access=read in any key requests, and modify these
in line with their apparent role to try to interfere with the application’s
access control logic.
6.4.2 Some applications base access control decisions on the HTTP Referer
header. For example, an application may properly control access to
/admin.jsp and accept any request showing this as its Referer. To test
for this behavior, attempt to perform some privileged actions to which
you are authorized, and submit a missing or modified Referer header.
If this change causes the application to block your request, it may be
using the Referer header in an unsafe way. Try performing the same
action as an unauthorized user, but supply the original Referer header
and see whether the action succeeds.
6.4.3 If HEAD is an allowed method on the site, test for insecure containermanaged
access control to URLs. Make a request using the HEAD method
to determine whether the application permits it.