5. What is Authentication
“The process of verification that an individual,
entity or website is who it claims to be.”
Placeholder
for
Title
Placeholder
for
Title
6. 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
Placeholder
for
Title
7. 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
Placeholder
for
Title
8. 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)
9. Testing for Credentials Transported over an
Encrypted Channel (OTG-AUTHN-001)
• Example 1: Sending data with POST method
through HTTP
10. Testing for Credentials Transported over an Encrypted
Channel (OTG-AUTHN-001)
• Example 2: Sending data with POST method
through HTTPS
11. 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
12. 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.com
3. http://test.com sends back a redirect to https://test.com
4. 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.
13. Testing for Credentials Transported over an Encrypted
Channel (OTG-AUTHN-001)
• Example 4: Sending data with GET method through
HTTPS
14. 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".
15. 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.
16. 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.
17. 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)
18. 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.
19. 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.
20. 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.
21. 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**
22. 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
23. Testing for Weak security question/answer
(OTG-AUTHN-008)
Pre-generated questions
What 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!@$
24. Testing for Weak security question/answer
(OTG-AUTHN-008)
Test Pre-generated questions
- Try to obtain a list of security questions
Testing for weak self-generated questions
- Try to obtain a list of security questions
Testing for brute-forcible answers
- Determine if a number of incorrectly supplied
security answers trigger a lockout mechanism
25. 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.
26. 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
27. 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)
28. 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.
29. 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
30. 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
Placeholder
for
Title
31. 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)
32. 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?
33. 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?
34. 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"
35. 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.
36. 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
37. 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.
38. 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?
39. 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.
40. 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.
41. 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.
42. 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.
43. 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