This document provides an overview of securing session management and discusses vulnerabilities in session tokens. It describes how session tokens can be attacked by predicting, modifying, or stealing them. It also discusses weaknesses related to how tokens are generated, transmitted, handled by applications, and terminated. The document recommends generating strong, unpredictable tokens and protecting them throughout their lifecycle to help secure session management.

1. CNIT 129S: Securing
Web Applications
Ch 7: Attacking Sessio
n
Management
Updated 3-3-21

2. Session Management
• Enables application to identify a given user over
a number of different request
s
• Ex: login, then later request
s
• Fundamental security componen
t
• A prime target for attackers

3. Session Management
• Potential consequences of session
management attack
s
• A user can masquerade as another use
r
• Privilege escalation to administrator, owning
the entire applicatio
n
• Can be as simple as incrementing the value of a
token

4. Wall of Sheep
• My Gmail was
hacked at
Defco
n
• By stealing
and replaying
my session
cooki
e
• Using Hamster
and Ferret

5. The Need for State

6. Web 1.0
• Stateles
s
• Static page
s
• No custom conten
t
• No logging in

7. Logging In
• Allow user to register and log i
n
• Require a session to maintain the "state" of
being authenticate
d
• Otherwise user would have to log in to each
page

8. No Login
• Application with no login function still use
session
s
• Shopping basket

9. Session Token
• Server's
fi
rst response contains a Set-Cookie:
heade
r
• Each subsequent request from the client
contains the Cookie: header

10. Vulnerabilities
• Two categorie
s
• Weakness in generation of session token
s
• Weakness in handling session tokens
throughout their life cycle

11. Finding the Real Session
Token
• Sometimes a platform like ASP.NET generates a
token but the app doesn't really use i
t
• To
fi
nd a token, establish a session and then
replay a reques
t
• Systematically remove each item you suspect
of being the real toke
n
• Wait till response is no longer customized for
your sessio
n
• Burp Repeater is good for this

12. Demonstration
Copy to Repeater

13. Modify & Go

14. Demonstration
Amazon.com

15. Original Request

16. Minimal Request

17. Alternatives to Sessions

18. HTTP Authentication
• Basic, Digest, NTL
M
• Pass credentials with every request in HTTP
header
s
• Not via application-speci
fi
c cod
e
• Rarely used on Internet-based applications

19. Sessionless State
Mechanisms
• Application doesn't issue session tokens or
manage the state
• Transmit all data required to manage the state
via the client in a cookie or hidden form
fi
el
d
• Ex: ASP.NET ViewStat
e
• Link Ch 7a

22. Securing View State
• Data must be protected, usually as a binary blob
that is encrypted or signe
d
• To prevent re-use on another machin
e
• ASP.NET View State uses Base64 and a hash
made from a Machine Authentication Cod
e
• Includes the machine's MAC addres
s
• Expiration time enforces session timeouts

23. Indicators of Sessionless
State Mechanisms
• Token-like data items >=100 bytes lon
g
• New token-like item in response to every
reques
t
• Data is encrypted (structureless) or signed
(structured accompanied by a few random
bytes
)
• Application rejects attempts to submit the same
item with more than one request

24. Weaknesses in Token
Generation

25. Link Ch 7k

26. Token Use Cases
• Password recovery tokens sent to user's
email addres
s
• Tokens in hidden form
fi
elds to prevent
cross-site forgery attack
s
• Tokens used to grant one-time access to
protected resource
s
• Persistent tokens used to "remember me
"
• Tokens used to allow customers of shopping
application to see the status of an order

27. Unpredictability
• The security of the application depends on all
those tokens being unpredictable

28. Meaningful Tokens
• It's just hexadecimal ASCII fo
r
• Easy to guess other token values, like
user=admin

29. ASCII
• 75 73 65 72
• u s e r

30. Components in Structured
Tokens

31. Common Encoding
Schemes
• XO
R
• Base6
4
• Hexadecimal ASCII codes

32. Hack Steps
• Obtain a single toke
n
• Modify it in systematic way
s
• Change it one byte at a time, or one bit at a tim
e
• Resubmit it to see if it's still accepte
d
• Some
fi
elds may be ignore
d
• Burp Intruder's "char frobber" function

33. Hack Steps
• Log in as several users at different time
s
• Record the token
s
• If you can, register similar usernames like A,
AA, AAA, AAAB, etc
.
• Try similar series for other data, such as email
addresses

34. Hack Steps
• Analyze the tokens for correlation
s
• Look for encoding or obfuscatio
n
• A series of repeating letters like AAA will
produce repeating encoded characters like zzz if
XOR is use
d
• Base64 often ends in = or ==

35. Hack Steps
• Use the patterns you've found to try guessing
tokens of other user
s
• Find a page that is session-dependen
t
• Use Burp Intruder to send many requests using
guessed token
s
• Monitor results to see if any pages load
correctly

36. A

37. Predictable Tokens

38. Patterns
• From a sample of tokens, it may be
possible to predict valid token
s
• Commercial implementations such as
web servers or application platforms may
be more vulnerabl
e
• Because it's easier to gather a large
sample of tokens, from your own test
system

39. Sequential Tokens
• Burp trying
sequential
payload
s
• Winners
shown at to
the top

40. Three Sources of
Predictable Session Tokens
• Concealed sequence
s
• Time dependenc
y
• Weak random number generation

41. Concealed Sequences
• This sequence
appears to be
Base64-encode
d
• Decodes to the
gibberish on the
right

42. Hexadecimal Form
• Render the tokens as
hexadecimal
number
s
• Calculate difference
between sequential
token
s
• For negative
differences, add
0x10000000000 so it
starts with FF

43. Script to Decode

44. Generate Valid Tokens

45. Time Dependency
• Left number simply
increments by 1
each tim
e
• Right number
moves up by a
varying value, as
shown on the right

46. Another Sample
• Ten minutes late
r
• First number has jumped
by
6
• Second number has
jumped by 53957
8
• Ten minutes = 600 sec =
600,000 milliseconds

47. Attack Steps
• Poll the server frequently to gather session
token
s
• When
fi
rst number increases by more than 1,
there's another user in betwee
n
• We know the second number will be between
the two numbers we hav
e
• Simply brute-force the value

48. Weak Random Number
Generation
• Jetty is a Java-based Web serve
r
• Calculates pseudorandom session tokens
with a "linear congruential generator
"
• Multiplies previous number by a constant,
adds another constant, truncates to 48 bit
s
• Given one value, all others can be predicted

49. PHP 5.3.2 and Earlier
• Session token generated fro
m
• Client's IP addres
s
• Epoch time at token creatio
n
• Microseconds at token creatio
n
• Linear congruential generator

50. phpwn
• The vulnerability was
found in 200
1
• But no one wrote a
practical attack tool until
Samy Kamkar in 201
0
• Link Ch 7b

51. Testing the Quality of
Randomness

52. Algorithm

53. Burp Sequencer

54. Results: Red Bits are Non-
Random

55. Encrypted Tokens

56. Design Goal
• Token built from meaningful content,
such as usernam
e
• Encrypted with a secret key not known to
the attacke
r
• Sounds good, but sometimes the
attacker can tamper with token's
meaningful values without decrypting
them

57. ECB Ciphers
• Electronic Code Boo
k
• Input broken up into blocks, often 8 bytes lon
g
• Symmetric encryption, no randomnes
s
• Each input block encodes to a single output
bloc
k
• This preserves patterns in input

58. Image Encrypted with ECB
• Patterns preserved in output

59. Example of ECB
• Token contains several meaningful
fi
elds,
including numeric user i
d
• Encrypted form appears meaningless

60. 8-Byte Blocks

61. Copy a Whole Block
• Token is
now for
user 992

62. Register a New User "daf1"
• Now attacker can target uid=1

63. CBC Ciphers
• Cipher Block Chain mode
• XORs each block of plaintext with the
preceding block of ciphertext

64. CBC Ciphers
• Removes all visible
patterns from the apple
logo

65. Example: CBC
• Token contains uid and other
fi
eld
s
• Encrypted version appears random

66. Modify a Single Byte of
Ciphertext

67. Modify a Single Byte of
Ciphertext
• That block will decrypt to jun
k
• But the next block will remain meaningful, only
slightly altered by the XO
R
• Some of the altered blocks will have valid uid
values

68. Example Altered Values

69. Modify a Session Token

70. Flip Each Bit

71. Fast Method
• 8 requests per byt
e
• Won't take long to try all single bit
fl
ip
s
• Will con
fi
rm whether application is vulnerable

72. Results
• Some
fl
ips
change user id
to "invalid
"
• Others reach
real accounts
for other users!

73. Information Leakage
• Application may re-use the encryption code
elsewher
e
• It may allow user to submit arbitrary input and
see the ciphertex
t
• Such as to create a download link for an
uploaded
fi
l
e
• Submit desired plaintext as a
fi
lename, such a
s
• uid=1

74. B

75. Weaknesses in Session
Token Handling

76. Common Myths
• "SSL protects tokens in transmission
"
• Some attacks still work, such as XS
S
• "Our platform uses mature, sound
cryptography so the token is not
vulnerable
"
• But cookie may be stolen in transit

77. Disclosure on the Network
• Tokens transmitted without encryptio
n
• Can be sniffed from many location
s
• User's local networ
k
• Within IS
P
• Within IT department of server hosting the
application

78. Credential Theft v.
Token Theft
• Stealing a user's password may not wor
k
• Two-factor authentication, requiring a
PIN in addition to the passwor
d
• Login performed over HTTP
S
• Stealing a session token and hijacking
an authenticated session may still wor
k
• And the user won't be noti
fi
ed of a
extra successful login

79. Not Always HTTPS
• An app may use HTTPS during logi
n
• But use HTTP after login to see authorized
conten
t
• Gmail did this until 201
2
• Eavesdropper cannot steal password, but can
steal session token

80. Upgradeable Token
• App may use HTTP for preauthenticated page
s
• Such as the site's front pag
e
• And use HTTPS for login and all subsequent
page
s
• But continue to use the same token; upgrade
to an authenticated sessio
n
• Attacker can steal the token before login

81. Back Button
• App uses HTTPS for login and all subsequent
page
s
• With a new toke
n
• But user navigates back to an HTTP page with
the Back butto
n
• Exposing the token

82. sslstrip
• "Log In" link goes to an HTTPS pag
e
• Attacker in the middle alters the page to use
HTTP instea
d
• And forwards requests to the server via HTTP
S
• User won't see any obvious difference in the
page

83. Mixed Content
• HTTPS page with some HTTP conten
t
• Such as images, style sheets, etc
.
• This can send the session token over HTT
P
• Browsers now block some mixed-content by
default

84. Social Engineering
• App uses HTTPS for every pag
e
• Send user an HTTP link via email or IM, or
added to some page the user view
s
• To http://target.com or http://target.com:44
3
• Clicking that link may send a session token over
HTTP

85. Hack Steps
• Walk through the app, from start page, through
login, and all its functionalit
y
• Record every URL and note every session token
you receiv
e
• Note transitions between HTTP and HTTPS

86. Burp's HTTP History

87. Secure Cookies
• If secure
fl
ag is set on a cookie, browser will
only send it via HTTP
S
• If the connection is only HTTP, that cookie won't
be sent

90. Setting Secure Cookie

91. Transmitting Secure Cookie
• http session, so "username" is NOT sent

92. Welcome Page Can't See
Username

93. Try a Secure Connection
• Go to https://attack.samsclass.info/token.ht
m
• Add an exception to allow Burp to proxy traf
fi
c

94. • Cookie sen
t
• Welcome page
knows my name

95. httponly
• httponly cookie
cannot be used
by JavaScript

97. >15% of Websites use HSTS
• Link Ch 7h

98. Disclosure of Tokens in Logs
• Less common as unencrypted network traf
fi
c
but more seriou
s
• Logs often visible to more attackers

99. Google:
inurl:jsessionid

103. Where SessionIDs in URL
Will Appear

105. Referer Attack
• A web mail application transmits session tokens
in the UR
L
• Send email to targets containing a URL on the
attacker's Web serve
r
• The Referer headers from people who click will
appear in the server logs

106. Vulnerable Mapping of
Tokens to Sessions
• Allowing users to have two sessions open at the
same tim
e
• Using static tokens (same token is sent to the
user each time they log in
)
• Misunderstanding of what a session is

107. Flawed Logic
• Token valu
e
• But app accepts the same "r1" with a different
"user"

108. Vulnerable Session
Termination
• A session may remain valid for days after the
last request is receive
d
• Ineffective logout functionalit
y
• Logout merely deletes cookie but does not
invalidate i
t
• Logout merely runs a client-side script, server
doesn't know a logout has occurred

110. Token Hijacking
• Cookie thef
t
• Session
fi
xation: attacker feeds a token to the
user, then user logs in, then attacker hijacks the
sessio
n
• Cross-Site Request Forgery (CSRF
)
• Tricks user into submitting a request
containing a cookie that goes to an attacker's
server

111. Liberal Cookie Scope
• When a cookie is set, the server can set the
domain and url (path) the cookie is used fo
r
• By default, all subdomains are include
d
• Cookie set by games.samsclass.info
• Will be sent to foo.games.samsclass.inf
o
• But NOT to samsclass.info

112. Specifying the Domain
• App at foo.wahh-app.com sets this cookie
:
• A domain can only set a cookie for the same
domain or a parent domai
n
• And not a top-level domain like .com

113. Example
• blogs.com sets a cookie for each use
r
• Each user can create blog
s
• joe.blogs.co
m
• sally.blogs.co
m
• A blog with JavaScript can steal tokens of other
users who read the attacker's blog

114. Fix
• There is no way to prevent cookies for an
application from being sent to subdomain
s
• Solution: use a different domain name for main
app, and scope the domain to this fully quali
fi
ed
nam
e
• www.blogs.co
m
• Cookie won't be sent to joe.blogs.com

115. Path
• Application returns this HTTP header
:
• Much stricter than same-origin polic
y
• Easily defeated by getting a handle to a
JavaScript window (Link Ch 7f)

116. Securing Session
Management

117. Securing Session
Management
• Generate Strong Token
s
• Protect them throughout life cycle, from
creation to disposal

118. Strong Tokens

119. Strong Tokens
• Tokens should contain no meaning or structur
e
• All data about the session's owner and status
should be stored on the server in a session
objec
t
• Some random functions, like java.util.Random,
are predictable from a single value

120. Sources of Entropy
(Randomness)
• Good method
:
• Add a secret known only to the server, then
hash it al
l
• Change the secret on each reboot

121. Protecting Tokens
Throughout Their Life Cycle
• Only transmit over HTTP
S
• secure, httponl
y
• Use HTTPS for every page in applicatio
n
• Don't put session tokens in the UR
L
• Implement a logout function that invalidates
session token on the server

122. Protecting Tokens
Throughout Their Life Cycle
• Session should expire after a brief period of
inactivity, such as 10 minute
s
• Don't allow concurrent login
s
• If a user starts a new session, a new token
should be generated, and the old one
invalidate
d
• Protect diagnostic or administrative functions
that save token
s
• Or don't save tokens in them

123. Protecting Tokens
Throughout Their Life Cycle
• Restrict domain and path for session cookie
s
• Audit codebase and remove XSS vulnerabilitie
s
• Don't accept tokens submitted by unrecognized
user
s
• Cancel tokens after such a request

124. Protecting Tokens
Throughout Their Life Cycle
• Use two-factor authenticatio
n
• Makes cross-site request forgery and other
session-hijacking methods more dif
fi
cul
t
• Use hidden
fi
elds rather than session cookie
s
• More dif
fi
cult to steal because they aren't sent in
every request

125. Protecting Tokens
Throughout Their Life Cycle
• Create a fresh session after every authenticatio
n
• To prevent session
fi
xation attacks

126. Per-Page Tokens
• A new page token is created every time the user
requests an application pag
e
• Page token veri
fi
ed on every reques
t
• If it doesn't match, the session is terminate
d
• Prevents pages being used out of orde
r
• And blocks an attacker from using a page at the
same time as a real user

128. Log, Monitor, and Alert
• Requests with invalid tokens should raise IDS
alert
s
• Alert users of incidents relating to their
sessions

129. Reactive Session
Termination
• Terminate session if a request ha
s
• Modi
fi
ed hidden form
fi
eld or URL query
string paramete
r
• Strings associated with SQL injection or XS
S
• Input that violates validation checks, such as
length restrictions

130. C