Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

Broken Authentication and Session Management

Vladimir Polumirace-mail: v.polumirac@sbb.rsblog: d0is.wordpress.comFB: facebook.com/vpolumiracTwitter twitter.com/d0is

23/07/2012

OWASP 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

Account credentials and sessions tokens are often not properly protected

A third can access to one's account Attacker compromise password, keys or authentication

tokenRisks

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

3

OWASP

WEB APPLICATION SECURITY

4

OWASP

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.

5

OWASP

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?

CookiesQuery Strings

6

OWASP

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.

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

7

Session["Username"] = txtUsername.Text;

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

OWASP

Cookies

The cookie will have

And if we go cookieless, the url will look like:

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

8

ASP.NET_SessionId:33irkjdmslkjeior9324jkdkj2039

http://tic.com/(S(33irkjdmslkjeior932))/Page2.aspx

OWASP

Environments Affected

All known web servers, application servers and web application environments

- are susceptible to broken authentication and session management issues.

9

OWASP

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.

10

OWASP

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.

11

OWASP

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

12

OWASP

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.

13

<sessionState cookieless=“false" />

OWASP

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.

14

OWASP

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

15

OWASP

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.

Have a logout button.

16

<system.web> <sessionState timeout= "8" /></system.web>

Session.Abandon()

OWASP

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? 

17

OWASP

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.

18

OWASP

• 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.

19

OWASP

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/

20

OWASP

Diskusija

21