5. Broken Authentication & Session
Management Attack
Authentication is the process of verification that an individual.
Identification must be unique.
To access user need to provide private information along with it.
example: password or secret answer.
Session Management is a process by which a server maintains the state of
an entity interacting with it.
Broken Authentication and Session Management attacks are anonymous
attacks with the intention to try and retrieve personal information.
Reason: Account credentials and sessions tokens are often not properly
protected.
6. Broken Authentication & Session
Management
Risks
Undermine authorization and accountability controls
cause privacy violation
Identity Theft
Method of attack: use weaknesses in authentication
mechanism
Logout
Password Management
Timeout
Remember me
Etc.
10. Brute Force Attack
Automatic process to get access.
An attacker configure predetermined values, making requests to a server using
those values, and then analyzing the response.
System sends a value and waits for the response, then tries another value, and so
on. Attacker keep trying different values until they get access. It can take one
minute, one day, one month or one year and so on.
Easy to gain access which doesn’t decrypt the request.
Many systems allow the use of weak passwords
Cycle through a dictionary (word by word).
Try commonly use passwords.
Same techniques can use to guess encryption keys as well.
To prevent password cracking by using a brute-force-attack one should always use
long and complex passwords.
11. Brute Force Attack (cont.)
Brute Force Attacks not only use to get access of passwords. It can use for
various stuffs.
Examples:
Cracks Offline Software Passwords or License Key
Discover Hidden Pages (if page response ok it will reply 200 if not then
response is 404)
12. Brute Force Attack (cont.)
Normal Brute Force
For one username,
Attacker tests many passwords
Username = priam
Passwords = 1234567, qwertz, asdfgh, abcd, ....
[pet names], [birthdays], [car names], [dictionary]
13. Brute Force Attack (cont.)
Reverse Brute Force
In Reverse Brute Force Attacks attacker tries one password against multiple
usernames. Think if you know a password but do not have any idea of the
usernames.
For one password,
Attacker tests many usernames
Efficient if the system has millions of users
The chance that many users use the same weak password dramatically increases.
Usernames= Priam, Jane, Eric, Guenter,...
Password = 12345678
14. Prevent Brute Force Attacks
Account Lock
Use Captcha
Use Authentication (oAuth or oAuth2)
OpenId
16. Session Spotting Attack
Attacker has possibility to listen to the traffic via IP level (sniffer)
Client connects to the HTTP server www.mysite.com
Visits a page containing a login form (url is HTTPS)
Receives a cookie containing his session ID
Sends his credentials encrypted (HTTPS)
Attacker receives following information
Session ID
Sees that the user has sent his credentials (using an encrypted connection to the
server)
Attacker can use the cookie to be recognized as the legitimate user!
18. Replay Attack
A replay attack is a form of network attack in which a valid data
transmission is maliciously or fraudulently repeated or delayed.
Example:
The Victim wants to log on a web site. Victim sends username and password. Web
Site verifies the couple. If an attacker can listen to the information transferred
Sniffer (unencrypted) / Trojan (encrypted).He can log-in the system using
Username and Password.
Another Example:
Alice wants to prove her identity to Bob. Bob requests her password as proof of
identity, which Alice dutifully; meanwhile, Eve is sniffing on the conversation and
keeps the password. After the interchange is over, Eve (posing as Alice) connects
to Bob; when asked for a proof of identity, Eve sends Alice's password read from
the last session which Bob accepts, thus granting Eve access.
19. Prevent Replay Attack
Two factor authentication device can fix it.
Brac Bank Hardware Token login system
User receives a 2FA Device from bank.
when the user wants to log in, he first need to be recognized by the 2FA Device.
Types a PIN on the 2FA Device.
User receives a OTP (One Time Password) sent by 2FA Device.
The 2FA computes a response (OTP) (can be used only one time)
The user types the response of the system on the screen
User is logged in!
No replay Attack is possible here, since the information transferring on the
network is only usable once.
21. Session Fixation Attack
Session fixation attacks attempts a system which allows one person to fixate
(find or set) another person's session identifier.
Most session fixation attacks are web based, and most rely on session
identifiers being accepted from URLs (query string) or POST data.
Attacker use some common technique for Session Fixation
URL Parameter
Hidden Form Field
Cookie
23. Session Fixation Example
Attacker creates a session on a web server
Sends a Request,
Get a Response containing a cookie
(SESSION ID=1234abcd5678)
Attacker needs to maintain this session alive (send requests
regularly)
Attacker sends this Session ID to the victim
Can be included in a phishing.
He sends an email containing the reference to the following
URL : http://www.gmail.com/?page=...&SESSION_ID=1234abcd.
Can be just a reference to an image on the targeted site:
<img src="http://www.gmail.com/?SESSION_ID=1234abcd">
24. Prevent Session Fixation
Do not accept session identifiers from GET / POST variables
Identity confirmation
Regenerate Session ID on each request
Timeout IDs
26. Session Hijacking
The Session Hijacking attack consists of the exploitation of the web session control
mechanism, which is normally managed for a session token.
Because http communication uses many different TCP connections, the web server
needs a method to recognize every user’s connections.
The most useful method depends on a token that the Web Server sends to the
client browser after a successful client authentication.
A session token is normally composed of a string of variable width and it could be
used in different ways, like
in the URL
in the header of the http requisition as a cookie
in other parts of the header of the http request
or yet in the body of the http requisition.
27. Session Hijacking (cont.)
The session token could be compromised in different ways, the most common
are:
Predictable session token
Session Sniffing
Client-side attacks (XSS, malicious JavaScript Codes, Trojans, etc)
30. Session Hijacking (cont.)
Many web sites generate session ID with proprietary algorithms
Increment static numbers
Can be more complicated (factoring in time and other computer specific variables)
Session ID is sent to the client
An attack can be:
Attacker connects to the web site and gets a session ID
Attacker calculates or Brute Forces the next session ID
Attacker switches the value of the cookie and assumes the identity of the next
user!
32. Insufficient Session Expiration
Insufficient Session Expiration occurs when a web application permits an
attacker to reuse old session credentials or session IDs for authorization.
Session expiration is comprised of two timeout types: inactivity and absolute.
An absolute timeout is defined by the total amount of time a session can be valid
without re-authentication.
An inactivity timeout is the amount of idle time allowed before the session is
invalid.
Suppose logout function sends the victim to site’s home-page without deleting
the session Or more likely, that the user just closed the window without
logging-out.
34. Prevention: General Guidelines
User Id or name must be unique.
Email address can be use as user id.
Password Complexity.
Password Topologies: ban commonly used, force different passwords, or require
user to change their password in a require period.
Authentication relies on secure communication and credential storage. Try to use
SSL (Security Socket Layers) – https for such type authentication otherwise
listening to credentials are possible.
All credentials should be stored in hashed or encrypted form
Attack on the database or file system should not compromise credentials
password should systematically be hashed
Private keys should never be stored clear text
35. Prevention: General Guidelines (cont.)
Don’t use Self-made session or SSO systems.
Try to avoid remember me option where possible.
Try to avoid using single sign-ons like One click login.
Start login process from an encrypted page.
Take care of logout process. Make sure all sessions are closed as soon as user
logged out from your application.
Use One Time Password or 2 Factor Authentication before accessing sensible
data.
Use timeout for handling sessions. Select time duration as less as possible.
Be careful with phishing emails.
Use Strong Captcha on application and many more.
36. Reference
OSWAP – Mobile Security Top 10
OSWAP – Mobile Security Checklist
OWASP - Authentication and Session Management
OWASP - Authentication and Session Management (What is and How to)
Hackingloops – Authentication and Session Management
Brac Bank Hardware Token Manual
Brute Force Attacks - http://resources.infosecinstitute.com/populartoolsforbrute-
forceattacks/
Brute Force Attacks – Wikipedia
Sitepoint – Replay Attacks by (Ben Dickson
(https://www.sitepoint.com/author/bdickson/)
Preventive Measures for Securing Web Applications using Broken Authentication and
Session Management Attacks: a Study by Bharti Nagpal
Session Fixation Vulnerability in Web-based Applications by acros
