Broken authentication and Session management
Authentication is the process of verifying who you are. It is a security procedure that ensures and verifies the identity of the user.
What is a Session?
Session is the server-side storage of user information to maintain user interaction with the web site. Servers typically generate a unique token for each connection, which is known as session ID. The session ID should be stored on the server-side and not on the client-side.
Broken authentication :
Authentication is “broken” when the application allows an attacker to identify or bypass the authentication mechanism. Broken Authentication is in one of the OWASP Top 10 Vulnerabilities. Broken authentication is caused by poorly implemented authentication and session management mechanisms. It allows an attacker to compromise passwords, keys, session ID's or to exploit other implementation flaws to take over a victim’s account.Common risk factors includes:
Default account -
It is also called as
Credentials stuffing. If the application permits publicly known default
credentials, it could quickly result in compromise. An attacker can create a
list of default accounts and perform brute force attack to gain access to a
legitimate account.
How to test
:
1.
Identify all the components of the website that may require credentials.
2.
Search for the default password for that particular component. for example -
tomcat-tomcat, admin-password, root-toor etc.
3. Try to login using default credentials.
Inadequate password policy -
Password represents
an important aspect of the authentication system. A simple password can be
easily guessed. Generally, if the password doesn’t adhere to a strong password
policy, an attacker can use brute force and dictionary attacks to discover the
passwords.
Two solutions are recommended to reduce the risk of easily guessed
passwords :
- Enforce Strong Password policy.
- Implement two-factor
authentication
User enumeration -
- Typically, web application authentication mechanism accepts a user identifier (user ID, username, email ID) and a secret (PIN, password).
- A badly configured system can reveal sensitive information if someone enters the wrong credential. For example, a web app could reveal info about the existing user
(1) Wrong username +
wrong password. If wrong username and wrong password is given, it will show the
"This user does not exist" error message.
(2) Wrong username +
wrong password. If the wrong username and wrong password is given, it will show
the "This user does not exist" error message.
- It indicates that entered username is valid and an attacker/malicious user can guess/ brute-force the associated password.
- Note that we are looking for differences in response between the two different cases (including web page’s visible content but also the URL, cookies or web page source )
The application should return normalize messages such as “Login failed, invalid username and password”. It doesn’t inform the attacker which part of the credential is incorrect and makes the calculation more difficult.
Missing Account lock out –
Account lockout prevents anyone from guessing the username and password. When your account is locked, you must wait for a set time before you are able to log in to your account again. The absence of a detection mechanism permits brute-force or
other automated attacks against legitimate accounts.
Limit failed login attempts.
Misconfigured Session -
Session ID is often used to log the user into the website. If not configured correctly, it can be used to gain potential privileges by hijacking a user's session.
It includes the following vulnerable objects:
üSession IDs that are not rotated after a successful login are vulnerable to session fixation attacks.
üAn attacker may deduce/predict another user’s session ID if it is predictable and/or weakly encrypted.
üSession IDs that are not properly invalidated during logout.
üSession IDs that are not invalidated/expired after a period of inactivity.
üSession IDs exposed
on the URL can lead to session fixation attack.
üUser session isn’t
properly invalidated during logout
üInsecure session handling methods.
Unencrypted communication –
If the application is
not implemented with HTTPS, Passwords, session IDs, and other credentials sent
over an unencrypted channel. If a server communicates sensitive
information, then it should only be exchanged via a secure SSL/TLS connection.
Thanks for reading :)
Keep Learning. Keep Growing :)
Awesome. This is really helpful.
ReplyDeleteKeep doing this great job