2. INTRODUCTION
Proper authentication and session management
is critical to web application security.
Flaws in this area most frequently involve the
failure to protect credentials and session tokens
through their lifecycle. These flaws can lead to
the hijacking of user or administrative accounts,
undermine authorization and accountability
controls, and cause privacy violations.
OWASP 2
3. Account credentials and sessions tokens are often not
properly protected
A third can access to one's account
Attacker compromise password, keys or authentication token
Risks
Undermine authorization and accountability controls
Cause privacy violation
Identity Theft
Method of attack: use weaknesses in authentication
mechanism
Logout
Password Management
Timeout
Remember me
Secret question and account update
OWASP 3
5. Authentication
User authentication on the web typically involves the use
of a : UserID and Password.
Stronger methods of authentication (commercially)
Software and hardware based cryptographic tokens or
biometrics, but such mechanisms are cost prohibitive for
most web applications.
A wide array of account and session management flaws
can result in the compromise of user or system
administration accounts.
Development teams frequently underestimate the
complexity of designing an authentication and session
management scheme that adequately protects
credentials in all aspects of the site.
OWASP 5
6. What are sessions?
Part of the art of session management.
Storing of data on the server for later.
Need a session ID – Where to store it?
Cookies
Query Strings
OWASP 6
7. Example Scenario
Login page with UserID/Password.
Another page with “Welcome, user”
How does 2nd page know user is logged in?
On login.aspx, we write a session object.
Session["Username"] = txtUsername.Text;
And on Page2.aspx, we read the session object.
username = (Session["Username"] ??
"Guest").ToString();
OWASP 7
8. Cookies
The cookie will have
ASP.NET_SessionId:33irkjdmslkjeior9324jkdkj2039
And if we go cookieless, the url will look like:
http://tic.com/(S(33irkjdmslkjeior932))/Page2.aspx
If the attacker can get the cookie or cookieless
URL, he can impersonate a logged-in browser.
OWASP 8
9. Environments Affected
All known
web servers,
application servers and
web application environments
- are susceptible to broken authentication and
session management issues.
OWASP 9
10. How attackers do it
Hackers will intercept the session ID, either from
the cookie or the request URL.
They then replicate that session ID themselves.
URLs are easy; they simply type it into their own
browser.
Cookies are tougher, but if they can write a
cookie or inject the cookie into the HTTP
Request header, they can trick the server.
OWASP 10
11. How to Determine If You Are Vulnerable
Both code review and penetration testing can be used to
diagnose authentication and session management
problems.
Carefully review each aspect of your authentication
mechanisms to ensure that user's credentials are
protected at all times, while they are at rest (e.g., on
disk) and while they are in transit (e.g., during login).
Review every available mechanism for changing a user's
credentials to ensure that only an authorized user can
change them.
Review your session management mechanism to ensure
that session identifiers are always protected and are
used in such a way as to minimize the likelihood of
accidental or hostile exposure.
OWASP 11
12. Protection
Avoid cookieless sessions
Avoid homegrown authentication schemes
Look into IP checking
Double-check passwords on certain activities
Use SSL (Security Socket Layer)
Expire sessions early and often
OWASP 12
13. Avoiding cookieless sessions
In web.config, set cookieless=“False”
This doesn’t completely solve the problem
but it makes it a whole lot tougher to crack.
<sessionState cookieless=“false" />
OWASP 13
14. Add IP checking
Store the original IP add in session.
Add subsequent checks; if the IP from the HTTP
header is different, decline to show anything.
You can even delete the session itself.
If the attacker is behind the same firewall, the
public IP may be the same.
Similarly, the legitimate surfer’s ISP may
dynamically change the IP address during the
session.
OWASP 14
15. Use SSL with sessions
When using SSL, all communications (including
cookies) are encrypted.
Makes it nearly impossible to directly lift the
cookies.
Still can be stolen via:
Physical access to cookie store.
So other methods are still needed
OWASP 15
16. Expire sessions early and often
You can’t hijack what isn’t there!
Get rid of sessions quickly.
Set the timeout as small as possible.
<system.web>
<sessionState timeout= "8" />
</system.web>
Have a logout button.
Session.Abandon()
OWASP 16
17. Preventing authentication flaws
- careful planning so important considerations are
(conclusion):
• Implementing a decent audit logging for
authentication and authorization controls.
Questions?:
Who logged on?
When?
From where?
What transactions did the user start?
What data was accessed?
OWASP 17
18. Solution
• Only use the inbuilt session management mechanism.
• Do not accept new, preset or invalid session identifiers from
the URL or in the request.
• Limit or rid your code of custom cookies for authentication or
session management purposes, such as “remember me” Use
the session management of the application server.
• Use a single authentication mechanism with appropriate
strength and number of factors.
• Implement a strong password policy when allowing
passwords.
• Don not allow the login process to start from an unencrypted
page.
• Ensure that every page has a logout link. Logout should
destroy all server side session state and client side cookies.
OWASP 18
19. • Use a timeout period that automatically logs out an
inactive session as per the value of the data being
protected (shorter is always better)
• Use only strong ancillary authentication functions
(questions and answers, password reset)
• Require the user to enter the old password when the user
changes to a new password
• Do not rely upon spoofable credentials as the sole form of
authentication, such as IP addresses or address range
masks, DNS or reverse DNS lookups, referrer headers or
similar…
• Be careful of sending secrets to registered e-mail
addresses as a mechanism for password resets.
OWASP 19
20. Resources
1. OWASP
http://www.owasp.org/
2. Top 10 Web Application Security Vunerabilities
http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A3.php
3. CodeIdol
http://codeidol.com/community/security/a3-broken-authentication-and-
session-management/22604/
OWASP 20