Java Reference
In-Depth Information
he above example shows an HTTP response header that has the Pragma set to “no-cache,” which
means that the page is not cached in the browser. herefore any sensitive information is not cached
and stored in the user's browser.
12.2.2.5 Testing for Weak or Nonsecure Session Identiiers
Session identiiers are used extensively by Web applications to keep track of state. he user's activi-
ties across an otherwise-static Web application are only kept alive because of session and session
tracking. However, improper implementation of session management has rendered them suscep-
tible to compromise, thereby having deadly consequences on the Web application. One of the
simplest and most devastating attacks against sessions is the manipulation of nonsecure session
identiiers in the Web application. Certain Web applications generate easily guessable or non-
random session identiiers to users. he attacker could identify the pattern of session identiiers
being issued by the Web server to the user, and based on the pattern, the attacker can increment
or decrement the value of the session identiier and gain access to the user's session. For instance,
the Web application issues session IDs of 1001 and is then incremented for every user session in
the Web application. he attacker or the tester can guess a random session identiier like 1023 and
gain access to the user's session. After having gained access to the user's session, the attacker can
gain access to sensitive information and compromise the Web application. Testing for nonsecure
session identiiers may be done by tampering session parameter values with a Web application
proxy or by entering it in the URL itself. Browsers may also be used to tamper with session values.
Certain browser extensions like Firefox's Add N Edit Cookies allow the users to edit cookie values
that are saved in the browser. BurpSuite also has a feature called Burp Sequencer where it extracts
several hundreds of session ids from the application and tests them for randomness. Several calcu-
lations are performed to yield metrics of randomness and strength of the session ids.
12.2.2.6 Testing for Session Fixation
Session ixation occurs when the Web application fails to invalidate the session of an already
authenticated user and uses the already existing session ID to track user sessions in the Web appli-
cation. he attacker or tester should simulate a session ixation attack to test the Web application
for improper session management. he tester should log in to the said Web application, which
issues him/her a session identiier. he user should try to authenticate to the Web application with
the same session ID, and if the application logs the user in without invalidating and issuing a new
session, then the application is vulnerable to session ixation.
12.2.2.7 Testing for Path Traversal
Path traversal is an attack where the attacker tries to gain access to certain sensitive iles in the
server hosting the Web application that are not meant to be viewed by individuals in the public
domain. Web servers and Web applications are ideally conigured to give users access to iles in
the Web document root folder. However, due to improper implementation of access control by the
Web application, the attacker is able to browse other iles and folders outside the Web document
root like the /etc/passwd ile, which contains passwords for accessing the server/Web application.
To test path traversal, the tester must try certain vectors to gain access to sensitive iles on the
server/application. hey are as follows:
Search WWH ::
Custom Search