The Web Application Hacker's Handbook Second Edition. Chapter07. Attacking Session Management

1. Chapter.07 Attacking Session Management
KoreaTech
Web Application Hacking & Security Study
Presenter : Alchemic
(SoftTrack Administrator)
(KoreaTech Information Security Researcher)
(NLP Practitioner)

2. Index
0x01. The Need for State
1) Alternatives to Sessions
0x02. Weaknesses in Token Generation
1) Meaningful Tokens
2) Predictable Tokens
3) Encrypted Tokens
0x03. Weaknesses in Session Token Handling
1) Disclosure of Tokens on the Network
2) Disclosure of Tokens in Logs
3) Vulnerable Mapping of Tokens to Sessions
4) Vulnerable Session Termination
5) Client Exposure to Token Hijacking
6) Liberal Cookie Scope
212/15/2015 SoftTrack
0x04. Securing Session Management
1) Generate Strong Tokens
2) Protect Tokens Throughout Their Life Cycle
3) Log, Monitor, and Alert

3. Ch 7. Attacking Session Management
The session management mechanism is a fundamental security component
in the majority of web applications.
It is what enables the application to uniquely identify a given user across a
number of different requests and to handle the data that it accumulates about
the state of that user’s interaction with the application.
312/15/2015 SoftTrack
If an attacker can break an application’s session management, she can effect-
tively bypass its authentication controls and masquerade as other application
users without knowing their credentials.

4. 0x01. The Need for State
412/15/2015 SoftTrack

5. 12/15/2015 SoftTrack 5
0x01. The Need for State
The majority of web “sites” are in fact web applications.
They allow you to register and log in.
They let you buy and sell goods.
They remember your preferences the next time you visit.
They deliver rich multimedia experiences with content created dynamically
based on what you click and type.
To implement any of this functionality, web applications need to use the
concept of a session.

6. 12/15/2015 SoftTrack 6
0x01. The Need for State
The simplest and still most common means of implementing sessions is to
issue each user a unique session token or identifier.
In most cases, applications use HTTP cookies as the transmission mechanism
for passing these session tokens between server and client.
The server’s first response to a new client contains an HTTP header like the
following:
and subsequent requests from the client contain this header:

7. 12/15/2015 SoftTrack 7
0x01. The Need for State
This standard session management mechanism is inherently vulnerable to
various categories of attack.
An attacker’s primary objective in targeting the mechanism is to somehow
hijack the session of a legitimate user and thereby masquerade as that person.
If the user has been authenticated to the application, the attakcer may be able
to access private data belonging to the user or carry out unauthorized actions
on that person’s behalf.
If the user is unauthenticated the attacker may still be able to view sensitive
information submitted by the user during her session.

8. 12/15/2015 SoftTrack 8
0x01. The Need for State
The vulnerabilities that exist in session management mechanisms largely fall
into tow categories:
■ Weaknesses in the generation of session tokens
■ Weaknesses in the handling of session tokens throughout their life cycle

9. 12/15/2015 SoftTrack 9
0x01. The Need for State
Alternatives to Sessions
■ HTTP authentication
Applications using the various HTTP-based authentication technologies
(basic, digest, NTLM) sometimes avoid the need to use sessions.

10. 12/15/2015 SoftTrack 10
0x01. The Need for State
Alternatives to Sessions
■ Sessionless state mechanisms
Some applications do not issue session tokens to manage the state of a
user’s interaction with the application.
Instead, they transmit all data required to manage that state via the client,
usually in a cookie or a hidden form field.
In effect, this mechanism uses sessionless state much like the ASP.NET
ViewState does.
For this type of mechanism to be secure, the data transmitted via the client
must be properly protected.

11. 12/15/2015 SoftTrack 11
0x02. Weaknesses in Token Generation

12. 12/15/2015 SoftTrack 12
0x02. Weaknesses in Token Generation
Session management mechanisms are often vulnerable to attack because
tokens are generated in an unsafe manner that enables an attacker to
identify the values of tokens that have been issued to other users.
★ NOTE
There are numerous locations where an application’s security depends on
the unpredictability of tokens it generates. Here are som examples :
■ Password recovery tokens sent to the user’s registered e-mail address
■ Tokens placed in hidden form fields to prevent CSRF attacks
■ Tokens used to give one-time access to protected resources
■ Persistent tokens used in “remember me” functions
■ Tokens allowing customers of a shopping application that does not use
authentication to retrieve the current status of an existing order

13. 12/15/2015 SoftTrack 13
0x02. Weaknesses in Token Generation
Meaningful Tokens
Some session tokens are created using a transformation of the user’s username
or e-mail address, or other information associated with that person.
For example, the following token may initially appear to be a long random string:
However, on closer inspection, you can see that it contains only hexadecimal
characters.
Decoding…

14. 12/15/2015 SoftTrack 14
0x02. Weaknesses in Token Generation
Meaningful Tokens
Tokens that contain meaningful data often exhibit a structure.
In other words, they contain serveral components, often separated by
a delimiter, that can be extracted and analyzed separately to allow an
attacker to understand their function and means of generation.
■ The Account username
■ The numeric identifier that the application uses to distinguish between
accounts
■ The user’s first and last names
■ The user’s e-mail address
■ The user’s group or role within the application
■ A date/time stamp
■ An incrementing or predictable number
■ The client IP address

15. 12/15/2015 SoftTrack 15
0x02. Weaknesses in Token Generation
Meaningful Tokens
Encoding schemes that are commonly encountered include XOR, Base64, and
hexadecimal representation using ASCII characters.
It may be necessary to rest varous decodings on each component of a
structured token to unpack it to its original form.

16. 12/15/2015 SoftTrack 16
0x02. Weaknesses in Token Generation
Predictable Tokens
Some session tokens do not contain any meaningful data associating them
with a particular user. Nevertheless, they can be guessed because they contain
sequences or patterns that allow an attacker to extrapolate from a sample of
tokens to fi nd other valid tokens recently issued by the application.
In the simplest and most brazenly vulnerable cases, an application may use
a simple sequential number as the session token.
Predictable session tokens commonly arise from three different sources:
■ Concealed sequences
■ Time dependency
■ Weak random number generation

17. 12/15/2015 SoftTrack 17
0x02. Weaknesses in Token Generation
Predictable Tokens

18. 12/15/2015 SoftTrack 18
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Concealed sequences
It is common to encounter session tokens that cannot be easily predicted
when analyzed in their raw form but that contain sequences that reveal
themselves when the tokens are suitably decoded or unpacked.
Consider the following series of values, which form one component of a
structured session token:

19. 12/15/2015 SoftTrack 19
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Concealed sequences
No immediate pattern is discernible; however, a cursory inspection indicates
that the tokens may contain Base64-encoded data.
In addition to the mixed-case alphabetic and numeric characters, there is a
+ character, which is also valid in a Base64-encoded string.
Running the tokens a Base64 decoder reveals the following:

20. 12/15/2015 SoftTrack 20
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Concealed sequences
These strings appear to be gibberish and also contain nonprinting characters.
This normally indicates that you are dealing with binary data rather than
ASCII text.
Rendering the decoded data as hexadecimal numbers gives you the following:

21. 12/15/2015 SoftTrack 21
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Concealed sequences
There is still no visible pattern.
However, if you subtract each number from the previous one, you arrive
at the following:
which immediately reveals the concealed pattern.

22. 12/15/2015 SoftTrack 22
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Concealed sequences
The algorithm used to generate tokens adds 0x97C4EB6A to the previous
value, truncates the result to a 32-bit number, and Base64-encodes this
binary data to allow it to be transported using the text-based protocol
HTTP.
Value
+ 0x97C4EB6A
Value
Dividing… (32bit)
Value
Base64 Encoding…
Final
Value

23. 12/15/2015 SoftTrack 23
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
Some web servers and applications employ algorithms to generate
session tokens that use the time of generation as an input to the
token’s value.
If insuffi cient other entropy is incorporated into the algorithm, you
may be able to predict other users’ tokens.
In a busy application with a large number of sessions being created
each second, a scripted attack may succeed in identifying large numbers
of other users’ tokens.

24. 12/15/2015 SoftTrack 24
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
Each token is clearly composed of two separate numeric components.
The first number follows a simple incrementing sequence and is easy
to predict.
The second number increases by a varying amount each time.

25. 12/15/2015 SoftTrack 25
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
Calculating the differences between its value in each successive token
reveals the following:

26. 12/15/2015 SoftTrack 26
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
Comparing this second sequence of tokens with the fi rst, two points are
immediately obvious:

27. 12/15/2015 SoftTrack 27
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
1) The fi rst numeric sequence continues to progress incrementally;
however, five values have been skipped since the end of the first
sequence. This is presumably because the missing values have been
issued to other users who logged in to the application in the window
between the two tests.
2) The second numeric sequence continues to progress by similar
intervals as before; however, the first value we obtain is a massive
539,578 greater than the previous value.
This second observation immediately alerts us to the role played by
time in generating session tokens.

28. 12/15/2015 SoftTrack 28
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Time Dependency
Indeed, our hunch is correct. In a subsequent phase of our testing we
perform a code review, which reveals the following token-generation
algorithm:

29. 12/15/2015 SoftTrack 29
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Weak Random Number Generation
Very little that occurs inside a computer is random.
Therefore, when randomness is required for some purpose, software uses
various techniques to generate numbers in a pseudorandom manner.
An attacker who obtains a single session token from the server can obtain
the tokens of all current and future sessions.

30. 12/15/2015 SoftTrack 30
0x02. Weaknesses in Token Generation
Predictable Tokens
■ Testing the Quality of Randomness
Please read the book…
Next…

31. 12/15/2015 SoftTrack 31
0x02. Weaknesses in Token Generation
Encrypted Tokens
In some situations, depending on the encryption algorithm used and the
manner in which the application processes the tokens, it may nonetheless be
possible for users to tamper with the tokens’ meaningful contents without
actually decrypting them.
Bizarre as it may sound, these are actually viable attacks that are sometimes
easy to deliver, and numerous real-world applications have proven vulnerable
to them.
The kinds of attacks that are applicable depend on the exact cryptographic
algorithm that is being used.

32. 12/15/2015 SoftTrack 32
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
Applications that employ encrypted tokens use a symmetric encryption
algorithm so that tokens received from users can be decrypted to recover
their meaningful contents.
Some symmetric encryption algorithms use an “electronic codebook”
(ECB) cipher.
Consider an application whose tokens contain several different meaningful
components, including a numeric user identifier:

33. 12/15/2015 SoftTrack 33
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
When this token is encrypted, it is apparently meaningless and is likely to
pass all standard statistical tests for randomness:
The ECB cipher being employed operates on 8-byte blocks of data, and
the blocks of plaintext map to the corresponding blocks of ciphertext as
follows:

34. 12/15/2015 SoftTrack 34
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
Now, because each block of ciphertext will always decrypt into the same
block of plaintext, it is possible for an attacker to manipulate the sequence
of ciphertext blocks so as to modify the corresponding plaintext in meanin-
gful ways.
For example, if the second block is duplicated following the fourth block,
the sequence of blocks will be as follows:

35. 12/15/2015 SoftTrack 35
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
The decrypted token now contains a modified uid value, and also a
duplicated app value.
Exactly what happens depends on how the application processes the
decrypted token. Often, applications using tokens in this way inspect
only certain parts of the decrypted token, such as the user identifier.
If the application behaves like this, then it will process the request in the
context of the user who has a uid of 992, rather than the original 218.

36. 12/15/2015 SoftTrack 36
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
Suppose you register the username daf1, and are issued with the
following token:
The blocks of plaintext and ciphertext for this token are as follows:

37. 12/15/2015 SoftTrack 37
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
If you then duplicate the seventh block following the fourth block, your
decrypted token will contain a uid value of 1:

38. 12/15/2015 SoftTrack 38
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ ECB Ciphers
By registering a suitable range of usernames and reperforming this attack,
you could potentially cycle through the entire range of valid uid values, and
so masquerade as every user of the application.

39. 12/15/2015 SoftTrack 39
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers
The way in which CBC-encrypted tokens are often employed in web
applications means that an attacker may be able to manipulate parts of
the decrypted tokens without knowing the secret key.

40. 12/15/2015 SoftTrack 40
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers
Consider a variation on the preceding application whose tokens contain
several different meaningful components, including a numeric user identifier:
As before, when this information is encrypted, it results in an apparently
meaningless token:
By manipulating a single individual block of the token, the attacker can
systematically modify the decrypted contents of the block that follows it.
Depending on how the application processes the resulting decrypted token,
this may enable the attacker to switch to a different user or escalate
privileges.

41. 12/15/2015 SoftTrack 41
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers
Let’s see how.
The attacker works through the encrypted token, changing one character
at a time in arbitrary ways and sending each modifi ed token to the
application.
This involves a large number of requests.
The following is a selection of the values that result when the application
decrypts each modifi ed token:

42. 12/15/2015 SoftTrack 42
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers
In each case, the block that the attacker has modifi ed decrypts into junk,
as expected (indicated by ????????).
However, the following block decrypts into meaningful text that differs
slightly from the original token.
Although the attacker does not see the decrypted values, the application
attempts to process them, and the attacker sees the results in the
application’s responses.
Often applications using tokens in this way inspect only certain parts of
the decrypted token, such as the user identifi er. If the application behaves
like this, then the eighth example shown in the preceding list succeeds, and
the application processes the request in the context of the user who has a
uid of 226, rather than the original 216.

43. 12/15/2015 SoftTrack 43
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers

44. 12/15/2015 SoftTrack 44
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers

45. 12/15/2015 SoftTrack 45
0x02. Weaknesses in Token Generation
Encrypted Tokens
■ CBC Ciphers

46. 12/15/2015 SoftTrack 46
0x03. Weaknesses in Session Token Handling

47. 12/15/2015 SoftTrack 47
0x03. Weaknesses in Session Token Handling
Disclosure of Tokens on the Network
This area of vulnerability arises when the session token is transmitted across
the network in unencrypted form, enabling a suitably positioned eavesdropper
to obtain the token and therefore masquerade as the legitimate user.
Suitable positions for eavesdropping include the user’s local network, within
the user’s IT department, within the user’s ISP, on the Internet backbone, within
the application’s ISP, and within the IT department of the organization hosting
the application.
In each case, this includes both authorized personnel of the relevant organ-
Ization and any external attackers who have compromised the infrastructure
concerned.

48. 12/15/2015 SoftTrack 48
0x03. Weaknesses in Session Token Handling
Disclosure of Tokens on the Network
This weakness may occur in various ways, many of which can arise specifically
when HTTP cookies are used as the transmission mechanism for session tokens:
■ Some applications elect to use HTTPS to protect the user’s credentials during
login but then revert to HTTP for the remainder of the user’s session.
■ Some applications use HTTP for preauthenticated areas of the site, such as
the site’s front page, but switch to HTTPS from the login page onward.
■ Even if the application issues a fresh token following successful login, and
uses HTTPS from the login page onward, the token for the user’s authent-
icated session may still be disclosed. This can happen if the user revisits a
preauthentication page (such as Help or About), either by following links
within the authenticated area, by using the back button, or by typing the
URL directly.

49. 12/15/2015 SoftTrack 49
0x03. Weaknesses in Session Token Handling
Disclosure of Tokens on the Network
This weakness may occur in various ways, many of which can arise specifically
when HTTP cookies are used as the transmission mechanism for session tokens:
■ In a variation on the preceding case, the application may attempt to switch
to HTTPS when the user clicks the Login link.
■ Some applications use HTTP for all static content within the application, such
as images, scripts, style sheets, and page templates.
■ Even if an application uses HTTPS for every page, including unauthenticated
areas of the site and static content, there may still be circumstances in which
users’ tokens are transmitted over HTTP.

50. 12/15/2015 SoftTrack 50
0x03. Weaknesses in Session Token Handling
Disclosure of Tokens in Logs
Aside from the clear-text transmission of session tokens in network communi-
cations, the most common place where tokens are simply disclosed to unauth-
orized view is in system logs of various kinds.
Although it is a rarer occurrence, the consequences of this kind of disclosure
are usually more serious.
When applications transmit their session tokens in this way, it is likely that
their session tokens will appear in various system logs to which unauthorized
parties may have access:
■ User’s browser logs
■ Web server logs
■ Losg of corporate or ISP proxy servers
■ Logs of any reverse proxies employed within the application’s hosting
environment
■ The Referer logs of any servers that application users visit by following off-
site links, as shown in next Figure

51. 12/15/2015 SoftTrack 51
0x03. Weaknesses in Session Token Handling
Disclosure of Tokens in Logs

52. 12/15/2015 SoftTrack 52
0x03. Weaknesses in Session Token Handling
Vulnerable Mapping of Tokens to Sessions
Base64 Decoding….

53. 12/15/2015 SoftTrack 53
0x03. Weaknesses in Session Token Handling
Vulnerable Session Termination
Proper termination of sessions is important for two reasons.
First, keeping the life span of a session as short as is necessary reduces the
window of opportunity within which an attacker may capture, guess, or misuse
a valid session token.
Second, it provides users with a means of invalidating an existing session when
they no longer require it.
■ In some cases, a logout function is simply not implemented. Users have
no means of causing the application to invalidate their session.
■ In some cases, the logout function does not actually cause the server to
invalidate the session. The server removes the token from the user’s browser
(for example, by issuing a Set-Cookie instruction to blank the token).
However, if the user continues to submit the token, the server still accepts it.
■ In the worst cases, when a user clicks Logout, this fact is not communicated
to the server, so the server performs no action.

54. 12/15/2015 SoftTrack 54
0x03. Weaknesses in Session Token Handling
Client Expowure to Token Hijacking
An attacker can target other users of the application in an attempt to capture
or misuse the victim’s session token in various ways:
■ An obvious payload for cross-site scripting attacks is to query the user’s
cookies to obtain her session token, which can then be transmitted to an
arbitrary server controlled by the attacker.
■ Various other attacks against users can be used to hijack the user’s session
in different ways. With session fi xation vulnerabilities, an attacker feeds
a known session token to a user, waits for her to log in, and then hijacks
her session. With cross-site request forgery attacks, an attacker makes
a crafted request to an application from a web site he controls, and he
exploits the fact that the user’s browser automatically submits her current
cookie with this request.

55. 12/15/2015 SoftTrack 55
0x03. Weaknesses in Session Token Handling
Liberal Cookie Scope
The usual simple summary of how cookies work is that the server issues a
cookie using the HTTP response header Set-cookie, and the browser then
resubmits this cookie in subsequent requests to the same server using the
Cookie header.
In fact, matters are rather more subtle than this.
- Cookie Domain Restrictions
- Cookie Path Restrictions
Please read the book…
Next…

56. 12/15/2015 SoftTrack 56
0x04. Securing Session Management

57. 12/15/2015 SoftTrack 57
0x04. Securing Session Management
Generate Strong Tokens
The most effective token generation mechanisms are those that:
■ Use an extremely large set of possible values
■ Contain a strong source of pseudorandomness, ensuring an even and
unpredictable spread of tokens across the range of possible values
The objective of designing a mechanism to generate strong tokens is that it
should be extremely unlikely that a determined attacker with large amounts
of bandwidth and processing resources should be successful in guessing a
single valid token within the life span of its validity.
Here are some examples of information that may be incorporated:
■ The source IP address and port number from which the request was received
■ The User-Agent header in the request
■ The time of the request in milliseconds

58. 12/15/2015 SoftTrack 58
0x04. Securing Session Management
Generate Strong Tokens
A highly effective formula for incorporating this entropy is to construct a string
that concatenates a pseudorandom number, a variety of request-specific data as
listed, and a secret string known only to the server and generated afresh on
each reboot.

59. 12/15/2015 SoftTrack 59
0x04. Securing Session Management
Protect Tokens Throughout Their Life Cycle
Now that you’ve created a robust token whose value cannot be predicted, this
token needs to be protected throughout its life cycle from creation to disposal,
to ensure that it is not disclosed to anyone other than the user to whom it is
issued:
■ The token should only be transmitted over HTTPS.
■ Session tokens should never be transmitted in the URL, because this
provides a simple vehicle for session fi xation attacks and results in tokens
appearing in numerous logging mechanisms.
■ Logout functionality should be implemented.
■ Session expiration should be implemented after a suitable period of inactivity
(such as 10 minutes). This should result in the same behavior as if the user
had explicitly logged out.

60. 12/15/2015 SoftTrack 60
0x04. Securing Session Management
Protect Tokens Throughout Their Life Cycle
■ Concurrent logins should be prevented. Each time a user logs in, a different
session token should be issued, and any existing session belonging to the
user should be disposed of as if she had logged out from it.
■ If the application contains any administrative or diagnostic functionality that
enables session tokens to be viewed, this functionality should be robustly
defended against unauthorized access.
■ The domain and path scope of an application’s session cookies should be
set as restrictively as possible.
Specific measures should be taken to defend the session management
mechanism against the variety of attacks that the application’s users may find
themselves targets of:

61. 12/15/2015 SoftTrack 61
0x04. Securing Session Management
Protect Tokens Throughout Their Life Cycle
■ The application’s codebase should be rigorously audited to identify and
remove any cross-site scripting vulnerabilities.
■ Arbitrary tokens submitted by users the server does not recognize should
not be accepted.
■ Cross-site request forgery and other session attacks can be made more diffi-
cult by requiring two-step confi rmation and/or reauthentication before
critical actions such as funds transfers are carried out.
■ Cross-site request forgery attacks can be defended against by not relying
solely on HTTP cookies to transmit session tokens.
■ A fresh session should always be created after successful authentication, to
mitigate the effects of session fi xation attacks.

62. 12/15/2015 SoftTrack 62
0x04. Securing Session Management
Per-Page Tokens
Finer-grained control over sessions can be achieved, and many kinds of session
attacks can be made more diffi cult or impossible, by using per-page tokens in
addition to session tokens.

63. 12/15/2015 SoftTrack 63
0x04. Securing Session Management
Log, Monitor, and Alert
The application’s session management functionality should be closely integrated
with its mechanisms for logging, monitoring, and alerting to provide suitable
records of anomalous activity and to enable administrators to take defensive
actions where necessary:
■ The application should monitor requests that contain invalid tokens.
■ Brute-force attacks against session tokens are diffi cult to block altogether,
because no particular user account or session can be disabled to stop the
attack.
■ Even if brute-force attacks against sessions cannot be effectively prevented
in real time, keeping detailed logs and alerting administrators enables them
to investigate the attack and take appropriate action where they can.
■ Wherever possible, users should be alerted to anomalous events relating to
their session, such as concurrent logins or apparent hijacking (detected using
per-page tokens).

64. Thank you !
KoreaTech
Web Application Hacking & Security Study
Presenter : Alchemic
(SoftTrack Administrator)
(KoreaTech Information Security Researcher)
(NLP Practitioner)