Authentication:
Authentication is any process by which a system verifies the identity of a User who wishes to access it. Web applications authentication may be implemented using Credentials, each of which is composed of a User ID and Password.
For additional security, Authentication may be implemented using Public Key Infrastructure (PKI). PKI uses digital certificates issued and verified by a Certificate Authority (CA).
For additional security, Authentication may be implemented using Public Key Infrastructure (PKI). PKI uses digital certificates issued and verified by a Certificate Authority (CA).
Authentication Bypass:
Introduction: Applications require authentication for gaining access to private information. Not every authentication method is able to provide adequate security. A flaw in the application that allows users to access application resources without authentication is referred as’ Authentication Bypass’.
Authentication bypass vulnerability is generally caused when it is assumed that users will behave in a certain way and failing to foresee the consequences of users doing the unexpected.
Authentication bypass vulnerability is generally caused when it is assumed that users will behave in a certain way and failing to foresee the consequences of users doing the unexpected.
Methods to bypass the authentication schema:
There are several methods to bypass the authentication schema in use by a web application. Here are some of the common ways to bypass authentication:
- Direct page request (Forced Browsing)
- Parameter Modification
- Session ID Prediction
- SQL Injection
Direct Page Request:
If a web application implements access control only on the login page, the authentication schema could be bypassed.
Examples:
1) For instance, an user attempts to directly access a protected page through the address bar. The user may get access if the page does not check the credentials of the user before granting access.
Login Page: http://www.example.com/login.php
Forceful Browsing to the following internal application pages without authentication could be successful.
This method of authentication bypass could allow an attacker to view static web pages (i.e., pages that do not have dynamic user content but have only static text).
2) Access to pages with user data could be obtained using the following method:
Suppose an application sets session cookies for a user id before validating password. Entering a valid user id and an invalid password in login page gives ‘Invalid credentials’ error message. However, as the session is already set for the user id entered, navigating to internal application pages (Eg:http://www.example.com/ViewPersonal Info.php) could reveal personal information of a user.
Parameter Modification:
Ineffective authentication checks implemented in the application could lead to Authentication Bypass.
Examples:
1) Imagine a system that uses a parameter “auth” to signify if a user has been authenticated, and prompts for the ‘log in’ procedure if auth=0. As long as auth=1, the user remains authenticated and able to access restricted pages.
While trying to get to a restricted page, a user’s browser might submit the below URL:http://www.mycorporatewebapp.com/remotemanagement.asp?auth=0
Bypassing this authentication might then be as simple as changing auth=0 to auth=1.
Bypassing this authentication might then be as simple as changing auth=0 to auth=1.
Session ID prediction:
Most common way of authenticating a user on every page is to send the user a session ID that allows the server to recognize the user as one who has been recently authenticated and entitled to view restricted pages.
Session IDs should be random, making them impossible to predict, and this is often achieved by passing some more unpredictable value through a hashing function to produce a session ID that is entirely unrelated to the previous ones that have been generated.
A mistake that some applications make is to use session IDs that are predictable – perhaps by incrementing them sequentially – or to randomise only a part of session IDs, making the short random part susceptible to a brute force attack.
If a hacker can get access to a valid session ID then they can carry out authentication bypassing by doing a session hijack attack – essentially providing the server with the session ID of someone who has already been authenticated, thereby impersonating them.
Session IDs should be random, making them impossible to predict, and this is often achieved by passing some more unpredictable value through a hashing function to produce a session ID that is entirely unrelated to the previous ones that have been generated.
A mistake that some applications make is to use session IDs that are predictable – perhaps by incrementing them sequentially – or to randomise only a part of session IDs, making the short random part susceptible to a brute force attack.
If a hacker can get access to a valid session ID then they can carry out authentication bypassing by doing a session hijack attack – essentially providing the server with the session ID of someone who has already been authenticated, thereby impersonating them.
Example: Suppose an application sends [application name] +[a sequential number] as session cookie. If a user’s session cookie is generated as ‘example123’, he could access application pages of other active users, by tampering cookie value to ‘example122’ or ‘example124’ etc.
SQL Injection:
SQL injection can be used to bypass authentication by fooling a login page into evaluating a Database expression that is always true instead of checking that a login name and password is valid.
For example, the authentication mechanism might involve an expression like:
(Authorise a user) WHERE Password=’$password’
Using a Web interface, when prompted for his password, a malicious user might enter:
ABC’ or ‘1’ = ‘1
Resulting in the query:
(Authorize a user) WHERE Password=’ABC’ OR ‘1’ = ‘1’
The hacker has effectively injected a whole OR condition into the authentication process. Worse, the condition ‘1’ = ‘1’ is always true, so this SQL query will always result in the authentication process being bypassed.
(Authorise a user) WHERE Password=’$password’
Using a Web interface, when prompted for his password, a malicious user might enter:
ABC’ or ‘1’ = ‘1
Resulting in the query:
(Authorize a user) WHERE Password=’ABC’ OR ‘1’ = ‘1’
The hacker has effectively injected a whole OR condition into the authentication process. Worse, the condition ‘1’ = ‘1’ is always true, so this SQL query will always result in the authentication process being bypassed.
Causes of Authentication Bypass Vulnerability:
Authentication Bypass is a result of improper or no authentication mechanism implemented for application resources. Unauthenticated access to dynamic content could result from improper access control and session management or improper input validation (SQL Injection).
Remediation Measures:
– Authenticate each application resource.
– Manage session cookies appropriately.
– Take extra care while validating authentication parameters to prevent SQL injection attacks. Use parametrized SQL queries or DB stored procedures for database calls.
– Manage session cookies appropriately.
– Take extra care while validating authentication parameters to prevent SQL injection attacks. Use parametrized SQL queries or DB stored procedures for database calls.
Risk Assessment:
Likelihood: Likelihood of authentication bypass exploit using forceful browsing technique or URL parameter tampering is ‘High’ as any normal internet user could launch this attack.
Authentication Bypass using ‘POST’ parameter or session cookies tampering or SQL injection may require tools like web proxy and little knowledge on hacking techniques. Hence, Likelihood of vulnerability in this case may be rated as ‘Medium/High’.
Authentication Bypass using ‘POST’ parameter or session cookies tampering or SQL injection may require tools like web proxy and little knowledge on hacking techniques. Hence, Likelihood of vulnerability in this case may be rated as ‘Medium/High’.
Impact: If an attacker could obtain sensitive personal data of a user, then impact of the vulnerability could be rated as ‘High’
If an attacker could gain access only to static pages, then impact of the vulnerability could be rated as ‘Medium’.
If an attacker could gain access only to static pages, then impact of the vulnerability could be rated as ‘Medium’.
Risk: Overall risk of the vulnerability is ‘Critical/High’
Note: Overall risk rating of a vulnerability also depends on the sensitive data dealt by the application.
Note: Overall risk rating of a vulnerability also depends on the sensitive data dealt by the application.
No comments:
Post a Comment