CWE: Disrespectful to Session ID in URL

Mitre's Common Weakness Enumeration (CWE) is the most comprehensive and granular taxonomy for web application security vulnerabilities and weaknesses.  So why, may I ask, is there no CWE ID for Session ID Exposed in URL?

Am I missing something?

Sure, we have CWE-384 (Session Fixation), but that's not the issue.  Session fixation in my experience is much more rare (and dangerous) compared to a session ID exposed in a URL.

Some might suggest CWE-287 (Improper Authentication) is the best fit.  That's a tough sell.  I don't buy it.

The closest one in my opinion must be CWE-598 (Information Exposure Through Query Strings in GET Request).  It's not a perfect fit, but the consequences section does refer to "impersonating a legitimate user".  That's a true risk for sure.

At this stage of the game, we probably won't see a CWE ID specific to Session ID Exposed in URL.  It seems like a no-brainer, but oh well. 

A Case for HttpOnly

Last month the Apache Infrastructure Team fell victim to a common web application attack. Rather than keep the information secret, they were kind enough to explain how the attack occurred. The initial attack leveraged cross-site scripting to steal users' session IDs. This is something that could have been prevented if the web app's session cookie had been marked with the HttpOnly attribute. When a web app sets a cookie, the presence of HttpOnly instructs browsers to disallow client-side script from accessing the cookie.

You will sometimes hear or read that HttpOnly helps prevent XSS attacks. That is not quite true. It helps prevent session hijacking. Specifically, it helps guard against one attack vector, namely where session cookies are stolen via XSS. HttpOnly can be used for any sensitive cookie that you don't want falling into the hands of fraudsters. (I should use "fraudster" more often - it is a fun word)

There is one caveat to using HttpOnly. It might break your application if it was written in such a way that the functionality depends on JavaScript having access to the cookie. That is fairly uncommon however.

Tomcat and HttpOnly Session Cookies

Just wanted to let you know that Apache Tomcat can now be configured to use HttpOnly session cookies. I had forgotten about Jim Manico's crusade to get HttpOnly support in Tomcat. It is a shame that it took so long to happen. Microsoft had introduced the concept of HttpOnly cookies primarily as a defense against session hijacking where a cross-site scripting attack is used to steal a session cookie. If a web application sets a cookie with the HttpOnly attribute, web browsers do not allow client-side script to access the cookie. The first browser to support HttpOnly was Internet Explorer 6 SP1 and for a long while IE was the only browser that supported it. That has changed as Firefox and Opera, for example, now support HttpOnly as well.

In Tomcat, enabling HttpOnly for the JSESSIONID is done at the context level, which means it can be controlled for each individual web application. You simply need need to add the following attribute to the <context> element:

useHttpOnly="true"

The default is "false", so you must explicitly add the line above to implement an HttpOnly session cookie. This capability first appeared in Tomcat 6.0.19 (current version = 6.0.20) as well as Tomcat 5.5.28, which is currently the latest version in the 5.5 branch.

Session Fixation Example

I usually see session fixation vulnerabilities with Java web applications. Just recently I found a ColdFusion application vulnerable to session fixation. This nasty security hole greatly increases the risk that users will have their sessions hijacked. Once an attacker has hijacked a session, he can view any data or perform any action that the legitimate user can. 

Both HP WebInspect and Burp Pro's active scanner failed to find this vulnerability. Testing for session fixation is quite easy to do, so I ran a quick test for it manually.

When testing for session fixation, I normally use two different browsers: IE and Firefox in this example. If the login page for an application is https://someapp.com/login, testing for session fixation consists of the following steps:

1. Launch Firefox and navigate directly to the login page.

2. Inspect the cookie(s) assigned by the application. For a Java web app, a JSESSIONID cookie will normally be set. In the case of ColdFusion, you normally see CFID and CFTOKEN cookies.

3. Copy the session ID from the cookie.

4. Construct a special URL that contains the session ID.
For Java, it looks like this:
https://someapp.com/login.jsp;jsessionid=[sessid]
For ColdFusion, it looks like this:
https://someapp.com/login.cfm?cfid=[cfid]&cftoken=[cftoken]

5. Open IE and configure it to run through a proxy (Burp, Paros, Fiddler2, etc.).

6. Paste the special URL into the IE address bar and hit Enter (this step simulates a victim clicking on a link in an email or Internet post).

7. Observe the HTTP response from the server. Is there a "Set-Cookie" header? If so, what is the session ID? You have a problem if it's the same value that's in the URL. On the other hand, you're probably okay if the value is different.

The ColdFusion site I tested was handling the situation even more poorly than usual. It was not necessary to visit the site initially to obtain legitimate session IDs from the server, so steps 1-3 above weren't even needed. An attacker could make up *any* 6 digit value for "cfid" and *any* 8 digit value for "cftoken", then embed these made-up values in the malicious URL, and the application happily accepted them.

The server responded by assigning CFID and CFTOKEN cookies based on the made-up values as illustrated below.

The URL of the request was:
https://someapp.com/login.cfm?cfid=999555&cftoken=29292929

And the HTTP response contained the following headers:
Set-Cookie: CFID=999555; path=/; Secure
Set-Cookie: CFTOKEN=29292929; path=/; Secure

Simultaneous Sessions for a Single User

It's a common request or recommendation that a web application not allow a user to have more than one session active at a time. In other words, after a user logs into an application, he should not be permitted to open a different type of browser (or use another computer) to log in again until his first session has ended. I've recommended this myself, but it's always been kind of muddy as to why this should be done. It is not trivial to implement this feature in the code. Recently, one of our clients wanted to better understand the reasons behind this recommendation. I was given the task of explaining.

The bottom line is that I could not find one strong, clear-cut reason for disallowing simultaneous sessions for a single user. There are a number of scenarios where it might help. Listed below are the reasons I came up with for implementing this feature. Please let me know if you have other ideas on this subject.

• An application has a licensing scheme that allows only a limited number of concurrent users or requires users to pay for access or premium content. A technical control to prevent simultaneous sessions for a single user ID would limit the financial harm caused by users sharing login credentials.
• It is out of the ordinary for a user to be logged in from more than one location (or more than one type of browser) for a given point in time. Anything out of the ordinary should be assumed to be a potential security risk.
• An attacker somehow steals a user's credentials (perhaps by sniffing unencrypted HTTP traffic) while the user was authenticating to the application. The attacker immediately tries to log in with the stolen credentials. The application sees that the user is already logged in and returns an error to the attacker, thus temporarily protecting the account.
• An attacker shoulder surfs to obtain a valid username (but not the password). He then immediately proceeds to run a password guessing or dictionary attack hoping to determine the password. If his attack happens to be successful during the time the legitimate user is logged in, it would prevent the attacker from gaining access.
• An attacker and a victim log in such that their sessions overlap. The application displays an error message that alerts the victim that someone else is using his account. The victim may contact the site owner, spurring an investigation, which might uncover a compromised account.
• It could help ensure data integrity and non-repudiation. A user may have multiple authenticated sessions at the same time, and one of the sessions might be used to make a critical change. If a user claims he never made such a change, it could be a problem for the logs to show that two authenticated sessions existed and the user claims he was logged in only once.
• It could help defend against a malicious user who wishes to overload the server memory by creating an excessive number of authenticated sessions. Authenticated sessions typically use much more memory on the server than unauthenticated sessions. With valid credentials and no limit to simultaneous sessions, a user could potentially create a denial-of-service condition.

After my research, I came to the conclusion that disallowing simultaneous sessions often does not increase an application's security posture enough to justify the required development and implementation cost. Obviously there are some special situations, like the licensing issue, where it could make sense.

This feature may actually introduce new problems. Let's say a user logs into an application and his machine crashes or the power goes out. A few minutes later, when trying to log in again, the user is denied access and told he's already logged in. Of course, it's true from the server's perspective (his session is still active), but now there's an angry user shouting profanities at his computer. Unless the user knows his previous session ID (fat chance), there's nothing for him to do but wait until the session expires due to inactivity or call your customer service department and complain.