Mitigating the WASC Web Security Threat Classification with Apache: Part 2/Page 2

[previous] [next]

Mitigating the WASC Web Security Threat Classification with Apache: Part 2

Insufficient Authorization

Insufficient Authorization is when a web site permits access to sensitive content or functionality that should require increased access control restrictions. When a user is authenticated to a web site, it does not necessarily mean that he should have full access to all content and that functionality should be granted arbitrarily.

Authorization procedures are performed after authentication, enforcing what a user, service, or application is permitted to do. Thoughtful restrictions should govern particular web site activity according to policy. Sensitive portions of a web site may need to be restricted to only allow an administrator.

Insufficient Authorization Example

In the past, many web sites have stored administrative content and/or functionality in hidden directories such as /admin or /logs. If an attacker were to directly request these directories, he would be allowed access. He may thus be able to reconfigure the web server, access sensitive information, or compromise the web site.

Apache Countermeasures for Insufficient Authentication

Similar to the issues raised in the previous section entitled "Insufficient Authentication," you should implement authorization access controls in addition to the authentication restrictions. One way to restrict access to URLs is to implement host-based ACLs that will deny access attempts unless the client is coming from an approved domain or IP address range. We can update the ACL created previously for the "/admin/" directory like this:

This would only allow connections from the ".internal.domain.com" name space. If an Internet client attempted to connect to this URL, they would be denied with a 403 Forbidden. Implementing these types of authorization restrictions is not difficult; however, the trick is identifying all of these sensitive locations. It is for this reason that you should run web vulnerability scanning software to help enumerate this data.

References

Brute Force Attack, Imperva Glossary iDefense: Brute-Force Exploitation of Web Application Session ID's [PDF] by David Endler—iDEFENSE Labs

Insufficient Session Expiration

Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a web site's exposure to attacks that steal or impersonate other users. Because HTTP is a stateless protocol (meaning that it cannot natively associate different requests together), web sites commonly use session IDs to uniquely identify a user from request to request. Consequently, each session ID's confidentiality must be maintained in order to prevent multiple users from accessing the same account. A stolen session ID can be used to view another user's account or perform a fraudulent transaction. The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim.

A long expiration time increases an attacker's chance of successfully guessing a valid session ID. The long length of time increases the number of concurrent and open sessions, which enlarges the pool of numbers an attacker might guess.

Insufficient Session Expiration Example

In a shared computing environment (more than one person has unrestricted physical access to a computer), Insufficient Session Expiration can be exploited to view another user's web activity. If a web site's logout function merely sends the victim to the site's home page without ending the session, another user could go through the browser's page history and view pages accessed by the victim. Because the victim's session ID has not been expired, the attacker would be able to see the victim's session without being required to supply authentication credentials.

Apache Countermeasures Against Insufficient Session Expiration

There are three main scenarios where session expiration should occur:

Forcefully expire a session token after a predefined period of time that is appropriate. The time could range from 30 minutes for a banking application to a few hours for email applications. At the end of this period, the user must be required to re-authenticate. Forcefully expire a session token after a predefined period of inactivity. If a session has not received any activity during a specific period, then the session should be ended. This value should be less than or equal to the period of time mentioned in the previous step. This limits the window of opportunity available to an attacker to guess token values. Forcefully expire a session token when the user actuates the log-out function. The browser's session cookies should be deleted and the user's session object on the server should be destroyed (this removes all data associated with the session, it does not delete the user's data). This prevents "back button" attacks and ensures that a user's session is closed when explicitly requested.

Apache has no built-in capability to control session expirations; therefore, you would need to implement a third-party module to handle this task. If you implement Mod_Perl, there are numerous modules available that may assist with this task. An example listing of a few modules are as follows:

Apache::TicketAccess Apache::Session CGI::Session

You could also make the move and use the Tomcat web server from the Apache Jakarta Project. With Tomcat, you could utilize Java to manage/track user sessions.

References

Dos and Don'ts of Client Authentication on the Web [PDF] by Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster—MIT Laboratory for Computer Science
[previous] [next]

URL: