John Melton's Weblog
Java, Security and Technology
Java, Security and Technology
What is it and why do I care?
Session cookies (or the cookie containing the JSESSIONID to Java folks) are the cookies used to perform session management for web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session scoped data related to that session id. Since cookies are transmitted on every request, this is the most common mechanism used for session management in web applications.
The HttpOnly flag is an additional flag that is used to prevent an XSS (Cross-Site Scripting) exploit from gaining access to the session cookie. Since gaining access to the session cookie, and subsequently hijacking the victim’s session, is one of the most common results of an XSS attack, the HttpOnly flag is a useful prevention mechanism.
What should I do about it?
The resolution here is quite simple. You must add the HttpOnly flag to your session cookie (and preferably all cookies).
Here’s an example of how a session cookie might look without the HttpOnly flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;
And now, with the HttpOnly flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly;
And, if you were following along from last week, with both the secure and HttpOnly flags:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly; secure;
Not much to it. You can obviously manually do this, but if you’re working in a Servlet 3.0 or newer environment, there’s a simple configuration setting in the web.xml that takes care of this for you. You should add this snippet to your web.xml.
true
And, if you also use the secure flag, it looks like this:
true true
As you can see, resolving this issue is quite simple. It should be on everyone’s TODO list.
References
———–
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/
http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html
https://www.owasp.org/index.php/HttpOnly
What is it and why do I care?
Session cookies (or the cookie containing the JSESSIONID to Java folks) are the cookies used to perform session management for web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session scoped data related to that session id. Since cookies are transmitted on every request, this is the most common mechanism used for session management in web applications.
The secure flag is an additional flag you can set on a cookie that instructs the browser to ONLY send this cookie on HTTPS (encrypted) transmissions, and _not_ on HTTP (unencrypted) transmissions. This ensures your session cookie is not visible to an attacker in, say, a man in the middle attack (MITM). This is not a complete solution to secure session management, but is an important step.
What should I do about it?
The resolution here is quite simple. You must add the secure flag to your session cookie (and preferably all cookies as any requests to your site should be HTTPS if possible).
Here’s an example of how a session cookie might look without the secure flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;
And now, with the secure flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; secure;
Not much to it. You can obviously manually do this, but if you’re working in a Servlet 3.0 or newer environment, there’s a simple configuration setting in the web.xml that takes care of this for you. You should add this snippet to your web.xml.
true
As you can see, resolving this issue is quite simple. It should be on everyone’s //TODO list.
References
———–
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/
http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html
https://www.owasp.org/index.php/SecureFlag
This is usually a Java-only site, but I thought this paper was fairly interesting, so thought I’d do a quick post. The implementation is .NET, but the concepts are transferrable.
The good folks at Microsoft Research have come up with a clever new technique for XSS “prevention” called ScriptGard. The paper is located here. (Looks like there was a previous version of the paper in 2010, but this is the latest updated copy.) The paper is a good read, but I just wanted to summarize for folks with short attention spans like me :>.
Essentially, they’ve come up with a performant solution for runtime context-sensitive XSS protection in legacy applications, without requiring changes to the code. That’s quite an achievement, so how do they do it?
Here are the basic steps:
[Training phase]
1. Instrument the code and insert hooks to perform taint propagation
2. Apply a simulation algorithm to execute the code and see where tainted data reaches a sink
3. Evaluate whether or not the trace (flow) from source to sink is XSS’able (via a browser implementation that actually analyzes the output context)
4. Mark and cache any “bad” flows
[Runtime phase]
5. If any “bad” flows are executed, process the input and appropriately encode/sanitize the output.
There is a lot more that you can get from the paper, but that’s the gist as I read it.
There are several interesting points to consider from the paper:
- The proposed solution is meant to work on legacy code, in contrast to templating libraries which seem to be a good solution for new code. Templating libraries are good in that they help structure the code better and provide a better separation of code and data, but that doesn’t really help for legacy code, which is quite a challenge. [templating libraries such as OWASP jxt or Google AutoEscape are examples from Java]
- They initially tried doing all this work at runtime, but it was prohibitive from a performance perspective (one extreme example noted 175X – not %, 175 times – worse performance). This meant the process had to be broken up and some data carried over from testing and analysis to runtime.
- They found a significant number of examples in real tested code where a) the wrong encoding was used [bad, common], b) encoding was applied, but not necessary [ok, reasonably common], or c) the right encoders were applied, but in the wrong order [bad, becoming more common]. Lesson: applying encoding/sanitization is hard, even if you are paying attention and know what you’re doing. The rules can become somewhat esoteric, especially when browser bugs cause weird things to happen in corner cases and browser vendors don’t always agree on how things should be handled. Automation is your friend here.
- In order to figure out the context, they actually had to include a browser. I’ve been saying this was required for years now, but had no idea how to make it performant. Looks like they are smarter than I am (DOH!). This does have a certain issue, however, regarding browser implementation quirks. What if the internal browser implementation is wrong? Now the trained algorithm is wrong and the sanitization is wrong …
In conclusion, this paper is a good read if you have the time. XSS doesn’t appear to be going away anytime soon, but research like this gives me hope for novel ways of solving the problem.
Thanks to @securityninja for pointing this paper out.
What is it and why do I care?
I’ve already discussed this particular entry in more detail as it’s part of the OWASP Top 10, so you can find more detail here – http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/. In this article, I’ll just cover the important bits.
Error or exception handling is an important, often ignored, part of any application. There is a lot to be said about the topic in general, but for brevity’s sake, I’m only going to cover a couple of the most critical cases in J2EE web applications.
Essentially, one of the biggest worries about exception handling is that you don’t actually handle the exception. Instead your code or the code of some 3rd party library you’re using allows an exception to bubble up. At that point, once it’s at the boundary of your application and gets to the container, it depends on the specific container / application server you are using as to what semantics are applied in the handling of the exception. Often times, by default, there is a standard error page applied and the exception stack trace is simply printed on the screen in all it’s glory. This is clearly a problem in that it gives attackers a lot of information about the system, and can certainly lead to further attacks.
What should I do about it?
Handling this issue is fairly straightforward. The basic advice is to provide error handlers for at least java.lang.Throwable (catches any Java exceptions or errors) and provide more specific handlers for specific exceptions as well as http error codes, the most common being 404 and 500. An example snippet that can be applied to the web.xml is below:
Note: error.jsp page should be generic and provide a canned response message of some type with no detail that could help an attacker fingerprint the app in any way.
404 /error.jsp 500 /error.jsp java.lang.Throwable /error.jsp
There’s plenty more to handling exceptions in your application, but from a security perspective, catching Throwable’s and the specified error codes should do fairly well for you.
References
———–
http://software-security.sans.org/blog/2010/08/11/security-misconfigurations-java-webxml-files
http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/
What is it and why do I care?
Session fixation, by most definitions, is a subclass of session hijacking. The most common basic flow is:
1. attacker gets a valid session ID from an application
2. attacker forces the victim to use that same session ID
3. attacker knows the session ID that the victim is using and can gain access to the victim’s account.
Step 2 of forcing the session ID on the victim is the only real work involved in the attack. It’s often performed by simply sending a victim a link to a website with the session ID attached to the URL.
Obviously, one user being able to take over another user’s account is a serious issue, so …
What should I do about it?
Fortunately, resolving session fixation is usually fairly simple. The basic advice is:
Invalidate the user session once a successful login has occurred.
The usual basic flow to handle session fixation prevention looks like:
1. User enters correct credentials
2. System successfully authenticates user
3. Any existing session information that needs to be retained is moved to temporary location
4. Session is invalidated (HttpSession#invalidate())
5. New session is created (new session ID)
6. Any temporary data is restored to new session
7. User goes to successful login landing page using new session ID
A useful snippet of code is available from the ESAPI project that shows how to change the session identifier.
http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/reference/DefaultHTTPUtilities.java (look at the changeSessionIdentifier method)
There are other activities that you can perform to provide additional assurance against this issue. A few I thought of are listed below.
1. Check if a user tries to login using a session ID that has been specifically invalidated (requires maintaining this list in some type of LRU cache)
2. Check if a user tries to use an existing session ID already in use from another IP address (requires maintaining this data in some type of map)
3. If you see these types of obviously malicious behavior, consider using something like AppSensor (shameless plug) to protect your app, and to be aware of the attack.
As you can see, session fixation is a serious issue, but has a pretty simple solution. Your best bet if possible is to include an appropriate solution in some “enterprise” framework (like ESAPI) so this solution applies evenly to all your applications.
References
———–
https://www.owasp.org/index.php/Session_fixation
http://www.acros.si/papers/session_fixation.pdf
http://cwe.mitre.org/data/definitions/384.html
http://projects.webappsec.org/w/page/13246960/Session%20Fixation
Year Of Security for Java
This will serve as the introduction for a new series that will have roughly 1 article per week for a year. This series will be different from my last series (OWASP Top Ten – Java) in that each article will be pretty short and focused. There are several motivations for this series:
1. Get some old topics written down
2. Research some new technologies
3. Write
4. Learn
5. Answer questions from Java friends
It’s the last one that serves as the primary motivation. In my work with Java developers, I understandably get asked a lot of questions about security. These are pretty far-ranging from the “what is this thing I heard about” to “how do I do this very specific thing correctly”. Developers are sharp, but have a lot they are held accountable for, of which security is only one. In this series, I hope to highlight some of the common issues the developers I work with ask me about frequently, as well as point out a few things they probably should be asking about, but don’t know to just yet.
If you have specific suggestions for articles you’d like to see, feel free to email me at domain_name at gmail dot com or on twitter (_jtmelton).
Hope you enjoy.
