A3 Broken Authentication and Session Management

Problem and Protection

Roll your own sessions!

o  At [REDACTED], the powers that be nixed the use of Sessions because they require cookies to work and cookies can sometimes be disabled (or hijacked). So the developers rolled their own implementation of sessions. It worked in nearly the same way but resulting in many dollars spent and an even less-secure version of the built-in one

o  Used sequential session IDs

Broken Authentication and Session Management

o  Comprises many types of vulnerabilities, so it isn’t well-defined

o  Largest and most vulnerable point is Session IDs

What are sessions?

o  Part of the art of session management o  Storing of data on the server for later o  Need a session ID – Where to store it?

•  Cookies •  QueryStrings

Example

o  Login page with userid/password o  Another page with “Welcome, Chris” o  How does 2nd page know Chris is logged in? o  On login.aspx, we write a session object Session["Username"] = txtUsername.Text;

o  And on Page2.aspx, we read the session object

username = (Session["Username"] ?? "Guest").ToString();

But there’s a cookie!

o  The cookie will have ASP.NET_SessionId: 33irkjdmslkjeior9324jkdkj2039

o  And if we go cookieless, the url will look like: http://tic.com/(S(33irkjdmslkjeior932))/Page2.aspx

o  If the attacker can get the cookie or cookieless URL, he can impersonate a logged-in browser

How attackers do it

o  Hackers will intercept the session ID, either from the cookie or the request URL

o  They then replicate that session ID themselves

o  URLs are easy; they simply type it into their own browser

o  Cookies are tougher, but if they can write a cookie or inject the cookie into the HTTP Request header, they can trick the server

How we protect ourselves

o  Avoid cookieless sessions o  Avoid homegrown authentication schemes o  Look into IP checking o  Double-check passwords on certain activities o  Use SSL o  Expire sessions early and often

Avoiding cookieless sessions

o  In web.config, set cookieless=“False” o  This doesn’t completely solve the problem

but it makes it a whole lot tougher to crack

Don't use DIY authentication

o  Creating your own authentication methods can expose security issues too many to mention

o  The included .Net providers are secure and easy to use

Add IP checking

o  Store the original IP addy in session o  Add subsequent checks; if the IP from the HTTP

header is different, decline to show anything •  You can even delete the session itself

o  Not a fix-all, though. If the attacker is behind the same firewall, the public IP may be the same

o  Similarly, the legitimate surfer’s ISP may dynamically change the IP address during the session

Double-check sometimes

o  Certain activities are so critical that we should ask the user to re-enter his credentials before doing them

o  Put in another username/password validation before letting them into those activities

Use SSL with sessions

o  When using SSL, all communications (including cookies) are encrypted

o  Makes it nearly impossible to directly lift the cookies

o  Still can be stolen via: •  Physical access to cookie store •  XSS

o  So other methods are still needed

Expire sessions early and often

o  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()

Summary

o  If a hacker can find your Session ID, they can replicate it in a URL or cookie. They effectively become you without needing a username or password

o  We can protect ourselves by expiring sessions, double-checking passwords, using robust authentication schemes, and avoiding cookieless sessions

Further study

o  Firefox Cookie editor: •  http://bit.ly/FirefoxCookieEditor

o  Fiddler download: •  http://www.fiddler2.com