18 a3 broken authentication and session management.pptx
DESCRIPTION
Part of the Web Application Security CourseTRANSCRIPT
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