OWASP TOP 10A2 - Broken Authentication and Session Management

Noppadol SongsakaewSenior Associate (PwC )

April 28 , 2016

What is OWASP TOP 10

• Powerful awareness document for web application security

• Represent the top 10 most critical web application flaws

OWASP TOP 10

• A1-Injection• A2-Broken Authentication and Session Management• A3-Cross-Site Scripting (XSS)• A4-Insecure Direct Object References• A5-Security Misconfiguration• A6-Sensitive Data Exposure• A7-Missing Function Level Access Control• A8-Cross-Site Request Forgery (CSRF)• A9-Using Components with Known Vulnerabilities• A10-Unvalidated Redirects and Forwards

Agenda

• Broken Authentication• Testing of Authentication • Broken Session Management• Testing of Session Management• Wrap-up

What is Authentication

“The process of verification that an individual, entity or website is who it claims to be.”

Placeholder for Title

Placeholderfor

Title

Why is it Broken

- Inadequate password policies- Sending credential over an insecure channel- Insecure password recovery mechanism- Information leakage on failed login- Unlimited logon attempt

Placeholder for Title

Placeholderfor

Title

Result of Broken Authentication

- By-pass authentication- Complete control of accounts- Account theft, sensitive end-user (customer)

data could be stolen- Reputational damage and revenue loss.

Placeholder for Title

Placeholderfor

Title

OWASP Testing Guide: Authentication

1. Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

2. Testing for default credentials (OTG-AUTHN-002)

3. Testing for Weak lock out mechanism (OTG-AUTHN-003)

4. Testing for bypassing authentication schema (OTG-AUTHN-004)

5. Test remember password functionality (OTG-AUTHN-005)

6. Testing for Browser cache weakness (OTG-AUTHN-006)

7. Testing for Weak password policy (OTG-AUTHN-007)

8. Testing for Weak security question/answer (OTG-AUTHN-008)

9. Testing for weak password change or reset functionalities (OTG-AUTHN-009)

10.Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

• Example 1: Sending data with POST method through HTTP

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

• Example 2: Sending data with POST method through HTTPS

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

• Example 3: sending data with POST method via HTTPS on a page reachable via HTTP

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

• Example 3: sending data with POST method via HTTPS on a page reachable via HTTP (SSL Stripping)1. A is intercepting all traffic on the network.2. B visits http://test.com3. http://test.com sends back a redirect to https://test.com4. A intercepts the redirect and acts as the other end of the TLS session with

https://test.com, sending an unencrypted version of the content back to B. A also makes all requests on B behalf over it's TLS connection with https://test.com.

5. As far as https://test.com is concerned, B is using the site over a TLS connection.6. As far as B is concerned, he's using the site over a regular HTTP connection. Mallory

is free to view and tamper with the content that B sees as she deems fit.

Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)

• Example 4: Sending data with GET method through HTTPS

Testing for default credentials (OTG-AUTHN-002)

Testing for default credentials of common applications• Try the following usernames - "admin",

"administrator", "root", "system", "guest", "operator", or "super".

Testing for default credentials (OTG-AUTHN-002)

Testing for default password of new accounts• It can also occur that when a new account is created

in an application the account is assigned a default password. This password could have some standard characteristics making it predictable.

Testing for Weak lock out mechanism (OTG-AUTHN-003)

Testing for account lock-out policy• To evaluate the account lockout mechanism's ability

to mitigate brute force password guessing, attempt an invalid log in by using the incorrect password a number of times, before using the correct password to verify that the account was locked out.

Testing for Bypassing Authentication Schema (OTG-AUTHN-004)

- bypass by simply skipping the log in page- directly calling an internal page- Parameter modification- Session ID prediction- SQL Injection (HTML Form Authentication)

Testing for Vulnerable Remember Password (OTG-AUTHN-005)

The "remember my password" mechanism can be implemented with one of the following methods:• Set autocomplete="off" for the username and

password field including captcha field• Storing the password in a permanent cookie. The

password must be hashed/encrypted and not sent in the clear.

Testing for Browser cache weakness (OTG-AUTHN-006)

Browse History• The first and simplest test consists of entering sensitive

information into the application and logging out. Then the tester clicks the "Back" button of the browser to check whether previously displayed sensitive information can be accessed whilst unauthenticated.

Testing for Browser cache weakness (OTG-AUTHN-006)

Browse Cache• The cache and the history are two different entities. However,

they share the same weakness of presenting previously displayed sensitive information.

• Using proxy (Burp, OWASP Zed Attack Proxy (ZAP), browser add-on) to check for every page that contains sensitive information the server instructed the browser not to cache any data.

Testing for Browser cache weakness (OTG-AUTHN-006)

Useful Cache-Control response headers include:

• max-age • s-maxage • public • private • no-cache • no-store • must-revalidate• proxy-revalidate

**Edited slide - Add info on Cache**

Testing for Weak password policy (OTG-AUTHN-007)

• Password complexity• Password history + password changing period• Password expires• Different between last password and next password• Prevent user to use username or other account in

formation as a password

Testing for Weak security question/answer (OTG-AUTHN-008)

Pre-generated questionsWhat is your favourite football team?What is your favourite colour?Self-generated questions: What is 1+1?What is your username?My password is *w00t!@$

Testing for Weak security question/answer (OTG-AUTHN-008)

Test Pre-generated questions- Try to obtain a list of security questionsTesting for weak self-generated questions- Try to obtain a list of security questionsTesting for brute-forcible answers- Determine if a number of incorrectly supplied security answers trigger a lockout mechanism

weak password change or reset functionalities (OTG-AUTHN-009)

• if users, other than administrators, can change or reset passwords for accounts other than their own.

• if users can manipulate or subvert the password change or reset process to change or reset the password of another user or administrator.

• if the password change or reset process is vulnerable to CSRF.

Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

Alternative authentication channels• Standard website• Mobile, or specific device, optimized website• Accessibility optimized website• Alternative country and language websites• Parallel websites that utilize the same user accounts (e.g. another

website offering different functionally of the same organization, a partner website with which user accounts are shared)

• Development, test, UAT and staging versions of the standard website

Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)

• Understand the primary mechanism• Identify other channels• Enumerate authentication functionality• Review and test (test case)

What is Session Management?

Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction.

Why is it Broken?

- Inadequate Session Management policies- Sending session cookie over an insecure

channel- Insecure session generation- Session fixation vulnerability- No protection of session cookie

Result of Broken Session Management

- By-pass authentication- Complete control of accounts- Account theft, sensitive end-user (customer)

data could be stolen- Reputational damage and revenue loss.

Placeholder for Title

Placeholderfor

Title

OWASP Testing Guide: Session Management

1. Testing for Bypassing Session Management Schema (OTG-SESS-001)

2. Testing for Cookies attributes (OTG-SESS-002)

3. Testing for Session Fixation (OTG-SESS-003)

4. Testing for Exposed Session Variables (OTG-SESS-004)

5. Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)

6. Testing for logout functionality (OTG-SESS-006)

7. Test Session Timeout (OTG-SESS-007)

8. Testing for Session puzzling (OTG-SESS-008)

Testing for Bypassing Session Management Schema (OTG-SESS-001)

• Cookie Analysis- How many cookies are used in the application- Which parts of the application generate and/or modify the

cookie?- Which parts of the application require this cookie in order

to be accessed and utilized?

Testing for Bypassing Session Management Schema (OTG-SESS-001)

• Session Analysis- Session ID Predictability and Randomness- Session Time-out- Is Session contains log-in information?- Do the same input conditions produce the same ID on a

subsequent run?- What elements of the Session IDs are time-linked?

Testing for cookies attributes (OTG-SESS-002)

• Secure Attribute – ";secure“ (Cookie will only be sent over SSL/TLS)

• HttpOnly– ";HttpOnly“ (JS cannot access cookie. Prevent client side script attack)

• Domain Attribute – "; domain=app.mysite.com" and NOT "; domain=.mysite.com"

• Path Attribute– "; path=/myapp/" and NOT "; path=/".

• Expires Attribute – "; expires=Sun, 31-Jul-2016 13:45:29 GMT"

Testing for Session Fixation (OTG-SESS-003)

Session fixation vulnerabilities occur when:

• A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.

• An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.

Testing for Session Fixation (OTG-SESS-003)

- Test by request a web page from a target site- GET www.example.com

- Look at the session ID that generate by the web page- Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/;

secure- Authenticate to website with valid username and password

- If the authentication is done and session ID is same as before, the site is vulnerable to Session Fixation

Testing for Exposed Session Variables (OTG-SESS-004)

- Each time Session ID data is passed between the client and the server, the protocol, cache, and privacy directives and body should be examined. Transport security here refers to Session IDs passed in GET or POST requests, message bodies, or other means over valid HTTP requests.

Testing for Exposed Session Variables (OTG-SESS-004)

• How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields)

• Are Session IDs always sent over encrypted transport by default?• Is it possible to manipulate the application to send Session IDs

unencrypted? e.g., by changing HTTP to HTTPS?• What cache-control directives are applied to requests/responses

passing Session IDs?• Are these directives always present? If not, where are the

exceptions?• Are GET requests incorporating the Session ID used?• If POST is used, can it be interchanged with GET?

Testing for CSRF (OTG-SESS-005)

• CSRF is an attack that forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email or chat), an attacker may force the users of a web application to execute actions of the attacker's choosing.

• A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.

Testing for CSRF (OTG-SESS-005)

• let u the URL being tested; for example, u = http://www.example.com/action

• build an html page containing the http request referencing URL u (specifying all relevant parameters; in the case of http GET this is straightforward, while to a POST request you need to resort to some Javascript);

• make sure that the valid user is logged on the application;• induce him into following the link pointing to the URL to be tested (social

engineering involved if you cannot impersonate the user yourself);• observe the result, i.e. check if the web server executed the request.

Testing for logout functionality (OTG-SESS-006)

A secure session termination requires at least the following components:• Availability of user interface controls that allow the user to

manually log out.• Session termination after a given amount of time without

activity (session timeout).• Proper invalidation of server-side session state.

Test Session Timeout (OTG-SESS-007)

• The log out function effectively destroys all session token, or at least renders them unusable

• The server performs proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers

• A timeout is enforced and it is properly enforced by the server. If the server uses an expiration time that is read from a session token that is sent by the client (but this is not advisable), then the token must be cryptographically protected from tampering.

Testing for Session puzzling (OTG-SESS-008)

The purpose of a session puzzling attack is to access application entry points (web pages, services, etc.) that populate the session memory with objects and values, in order to "compose" a collection of session objects that enables the attacker to impersonate valid users, bypass security restrictions, and cause unexpected behaviours

Wrap-up

- Broken Authentication and Session Management- OWASP Testing guide Authentication- OWASP Testing guide Session Management