The 'root' cause
Systems vulnerable to authentication bypass usually exhibit one of two problems: a failure to enumerate and enforce the access policy or a weak authentication system that allows a valid identity to be forged. In the former, either the Web access control system does not have the full set of URIs that enumerate the application or Web site under attack, or the access control system does not extend to the section of the site that needs protection.
For example, in the root folder of a new protected Web application, there are shared files that both protected and unprotected applications are using. The root folder also contains database connection scripts or other files that have sensitive information. An authentication bypass attack targets files that are in use by the protected application. The attacker looks to the unprotected files for information about the system and formulates a strategy to bypass the authentication
Furthermore, administrators often fail to include shared resource directories or files as part of the security policy. As Web servers grow with new content, applications and folders, so does the risk of leaking information that is useful for attacks.
The protected site's folders may also lack protection throughout their structure. For example, the application's main folder is protected, but subsequent folders are unprotected.
These attacks can be averted by creating a simple spreadsheet information management model (IMM). In one column, list all folders and objects. List the permissions, security policy and permissible users with permission to access it in another. Then test each object from a new Web session to ensure access without proper session tokens is denied. Most engineers do not perform such analysis and testing of their systems prior to release and therefore accidentally leave data or applications open to attack.
Another flavor of authentication bypass involves direct attacks on the authentication and authorization systems. Many Web sites use scripts and back-end databases to make authentication and authorization decisions. Unfortunately, the design and implementation of these systems is faulty. Some Web form-based systems do the credential checking in the client side Web browser scripts or through parameters posted through the Web browser. An attack against these systems usually involves manipulation of values contained in the Web forms or in the parameters posted to the server. Some attacks are as simple as posting basic true or false values to the Web server.
For example, /webapps/login?validUser=yes&isAutheticated=yes can be manually entered into the browser in an attempt to bypass the application server's authentication mechanism.
Avoid this type of weakness by not exposing the authentication state in URLs or in client-side scripts.
More sophisticated attacks involve the direct feeding of SQL and other commands to the Web server software or database. Thus, an attacker tries to access a valid user session. After successfully authenticating a user, many Web-based applications give the user a cookie or token to present to the application for every access attempt. The token is often associated with a server side session ID or, in some cases, the cookie is the session ID. The applications do simple logic operations to determine if the session ID or token is valid, or in the list of known sessions.
This can be prevented with strongly encrypted cookies or random session IDs, which make forging much more difficult. Also, validating all user input on the server side can prevent hostile attempts at accessing a session from succeeding.
More advanced attacks aim to bypass authentication systems by stealing either valid session IDs or cookies. An attacker tries to replay these cookies or session IDs to impersonate a valid user. Many mistakenly consider these attacks man-in-the-middle or session hijacking attacks. However, replaying a cookie or session ID is an authentication bypass attack because it bypasses the subsystems that mediate access to the application, making direct application access possible. To avert this attack, send all session and cookie data over an encrypted channel.
About the author:
George Wrenn, CISSP, ISSEP, is a technical editor for our sister publication Information Security magazine and a security director at a financial services firm. He's also a graduate fellow at the Massachusetts Institute of Technology.
This was first published in December 2005