This chapter is from the book
This chapter is from the book
This chapter is from the book
Authorization
The Authorization section covers attacks that target a web site’s method of determining if a user, service, or application has the necessary permissions to perform a requested action. For example, many web sites should only allow certain users to access specific content or functionality. Other times, a user’s access to different resources might be restricted. Using various techniques, an attacker can fool a web site into increasing their privileges to protected areas.
Credential/Session Prediction
Credential/Session Prediction is a method of hijacking or impersonating a web site user. Deducing or guessing the unique value that identifies a particular session or user accomplishes the attack. Also known as Session Hijacking, the consequences could allow attackers the ability to issue web site requests with the compromised user’s privileges.
Many web sites are designed to authenticate and track a user when communication is first established. To do this, users must prove their identity to the web site, typically by supplying a username/password (credentials) combination. Rather than passing these confidential credentials back and forth with each transaction, web sites will generate a unique "session ID" to identify the user session as authenticated. Subsequent communication between the user and the web site is tagged with the session ID as "proof" of the authenticated session. If an attacker is able to predict or guess the session ID of another user, fraudulent activity is possible.
Credential/Session Prediction Example
Many web sites attempt to generate session IDs using proprietary algorithms. These custom methodologies might generate session IDs by simply incrementing static numbers. Or there could be more complex procedures such as factoring in time and other computer-specific variables.
The session ID is then stored in a cookie, hidden form-field, or URL. If an attacker can determine the algorithm used to generate the session ID, an attack can be mounted as follows:
- Attacker connects to the web application acquiring the current session ID.
- Attacker calculates or Brute Forces the next session ID.
- Attacker switches the current value in the cookie/hidden form-field/URL and assumes the identity of the next user.
Apache Countermeasures for Credential/Session Prediction Attacks
There are several protective measures that should be taken to ensure adequate protection of session IDs.
- Make sure to use SSL to prevent network sniffing of valid credentials.
- Add both the "secure" and "httponly" tokens to all SessionID cookies. These two cookie options will help to secure the credentials by forcing the user’s browser to only send this sensitive data over an SSL tunnel and also prevent scripts from accessing this data. The best solution for implementing this is to have the application developers update the code to include this parameter when generating/sending cookies to clients. It is possible, however, to have Apache add this token into the outbound cookie if you utilize Mod_Perl. You could implement a perl handler that can hook into the output filter of Apache with code such as this:
- Also with Mod_Perl, you can implement the Apache::TicketAccess module that was highlighted in the book Writing Apache Modules with Perl and C by Lincoln Stein and Doug MacEachern. This module was designed to have the client authenticate once, and then it issued a hashed "ticket" that is checked on subsequent requests. The hash is generated based on the following data: the user’s name, IP address, an expiration date, and a cryptographic signature. This system provides increased security due to its use of the cryptographic signature and use of the client’s IP address for validation. Due to the popularity of proxy servers these days, you could also update the IP address token to only check the Class C range of the data instead of the full address or you could substitute the X_FORWARDED_FOR client header that is added by many proxies.
# read the cookie and append the secure parameter
my $r = Apache->request;
my $cookie = $r->header_in('Cookie'};
$cookie =~ s/SESSION_ID=(\w*)/$1; secure; httponly/;
Beyond Apache mitigations, session IDs should meet the following criteria:
- Session IDs are random. Methods used to create secure session credentials should rely on cryptographically secure algorithms.
- Session IDs are large enough to thwart Brute Force attacks.
- Session IDs will expire after a certain length of time. (1–2 days).
- Session IDs are invalidated by both the client and server during log-out.
By following these guidelines, the risk to session ID guessing can be eliminated or minimized. Other ways to strengthen defenses against session prediction are as follows:
- Require users to re-authenticate before performing critical web site operations.
- Tying the session credential to the user’s specific IP addresses or partial IP range. Note: This may not be practical, particularly when Network Address Translation is in use.
- It is generally best to use the session IDs generated by the JSP or ASP engine you are using. These engines have typically been scrutinized for security weaknesses, and they are not impervious to attacks; they do provide random, large session IDs. This is done in Java by using the Session object to maintain state, as shown here:
HttpSession session=request.getSession();
References
"iDefense: Brute-Force Exploitation of Web Application Session ID's" By David Endler—iDEFENSE Labs http://www.cgisecurity.com/lib/SessionIDs.pdf
"Best Practices in Managing HTTP-Based Client Sessions" By Gunter Ollmann—X-Force Security Assessment Services EMEA http://www.itsecurity.com/papers/iss9.htm
"A Guide to Web Authentication Alternatives" By Jan Wolter http://www.unixpapa.com/auth/homebuilt.html
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:
<LocationMatch "^/admin/"> SSLRequireSSL AuthType Digest AuthName "Admin Area" AuthDigestfile /usr/local/apache/conf/passwd_digest Require user admin Order Allow,Deny Allow from .internal.domain.com Deny from all </LocationMatch>
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 http://www.imperva.com/application_defense_center/glossary/brute_force.html
"iDefense: Brute-Force Exploitation of Web Application Session ID's" By David Endler—iDEFENSE Labs http://www.cgisecurity.com/lib/SessionIDs.pdf
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: http://jakarta.apache.org/tomcat. With Tomcat, you could utilize Java to manage/track user sessions.
References
"Dos and Don’ts of Client Authentication on the Web" By Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster—MIT Laboratory for Computer Science http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf
Session Fixation
Session Fixation is an attack technique that forces a user’s session ID to an explicit value. Depending on the functionality of the target web site, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-site Scripting exploits to peppering the web site with previously made HTTP requests. After a user’s session ID has been fixed, the attacker will wait for them to login. Once the user does so, the attacker uses the predefined session ID value to assume their online identity.
Generally speaking, there are two types of session management systems for ID values. The first type is "permissive" systems that allow web browsers to specify any ID. The second type is "strict" systems that only accept server-side generated values. With permissive systems, arbitrary session IDs are maintained without contact with the web site. Strict systems require the attacker to maintain the "trap-session" with periodic web site contact, preventing inactivity timeouts.
Without active protection against Session Fixation, the attack can be mounted against any web site that uses sessions to identify authenticated users. Web sites using session IDs are normally cookie-based, but URLs and hidden form-fields are used as well. Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.
In contrast to stealing a user’s session ID after they have logged into a web site, Session Fixation provides a much wider window of opportunity. The active part of the attack takes place before the user logs in.
Session Fixation Example
The Session Fixation attack is normally a three-step process:
- Session set-up.
- Session fixation.
- Session entrance.
The attacker sets up a "trap-session" for the target web site and obtains that session's ID. Or, the attacker may select an arbitrary session ID used in the attack. In some cases, the established trap session value must be maintained (kept alive) with repeated web site contact.
The attacker introduces the trap session value into the user's browser and fixes the user's session ID.
The attacker waits until the user logs into the target web site. When the user does so, the fixed session ID value will be used and the attacker may take over.
Fixing a user's session ID value can be achieved with the techniques described in the following sections.
Issuing a New Session ID CookieValue Using a Client-Side Script
A Cross-site Scripting vulnerability present on any web site in the domain can be used to modify the current cookie value, as shown in the following code snippet:
Issuing a Cookie Using the META Tag
This method is similar to the previous one, but also effective when Cross-site Scripting countermeasures prevent the injection of HTML script tags, but not meta tags. This can be seen in the following code snippet.
http://example/<meta%20http-equiv=Set-Cookie%20 content="sessionid=1234;%20domain=.example.dom">.idc
Issuing a Cookie Using an HTTP Response Header
The attacker forces either the target web site, or any other site in the domain, to issue a session ID cookie. This can be achieved in the following ways:
- Breaking into a web server in the domain (e.g., a poorly maintained WAP server).
- Poisoning a user’s DNS server, effectively adding the attacker’s web server to the domain.
- Setting up a malicious web server in the domain (e.g., on a workstation in Windows 2000 domain; all workstations are also in the DNS domain).
- Exploiting an HTTP response splitting attack.
Apache Countermeasures for Session Fixation Attacks
There are three different approaches to take for mitigating Session Fixation attacks:
- Session set-up.
- Session fixation.
- Session entrance.
Session Set-Up
In this phase, the attacker needs to obtain a valid session ID from the web application. If the application only sends this session ID information after successfully logging in, then the pool of possible attackers can be reduced to those who already have an account.
If the web application does provide a session ID prior to successful login, then it may still be possible to identify an attacker who is enumerating the session ID characteristics. In this circumstance, the attacker usually will try to gather a large number of session IDs for evaluation purposes to see if they can potentially predict a future value. During this gathering phase, their scanning applications will most likely trigger Mod_Dosevasive, thus alerting security personnel.
Session Fixation
During this phase, the attacker needs to somehow inject the desired session ID into the victim’s browser. We can mitigate these issues by implementing a few Mod_Security filters, which will block these injection attacks:
# Weaker XSS protection but allows common HTML tags SecFilter "<[[:space:]]*script" # Prevent XSS atacks (HTML/Javascript injection) SecFilter "<.+>" # Block passing Cookie/SessionIDs in the URL
SecFilterSelective THE_REQUEST "(document\.cookie|Set-Cookie|SessionID=)"
Session Entrance
When a client accesses the login URL, any session ID token provided by the client's browser should be ignored, as the web application should generate a new one. You can add the following Apache RequestHeader directive to remove these un-trusted tokens:
<Directory /path/to/apache/htdocs/protected/> RequestHeader unset SessionID </Directory>
The session ID that is generated by the web application should include a token that identifies the client's IP address. If the client IP address does not match what is stored in the session ID, then the client should be forced to re-authenticate.
References
- "Session Fixation Vulnerability in Web-based Applications" By Mitja Kolsek—Acros Security http://www.acrossecurity.com/papers/session_fixation.pdf
- "Divide and Conquer" By Amit Klein—Sanctum http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf