Has any implemented countermeasures against session hijacking for ATG web applications? If so, can you share your approach?
I've been looking at this periodically for a while. Ever since the fire sheep add-on came out for firefox, session hijacking has the tinker toy of every high schooler that wants to try his or her hand at hacking (the bad kind).
I opened an issue with Oracle support, but they indicated that they have nothing to offer. The product doesn't include session hijacking countermeasures. They also indicated that they have no sample or reference implementation for any mitigation. I haven't checked WebLogic to see whether any countermeasures are included with it, but nothing has come up during my searches.
So what are the rest of you doing? Going pure SSL and paying the performance penalty? Ignoring the issue?
At a minimum, I'd been considering just moving the site to SSL only pages. But that has a lot of negatives, particularly for consumers using Internet Explorer to browse the site. Even with SPDY, since IE has no committed plan to uptake the protocol. And then I have to start paying for premium services from third parties, like the enterprise license for the use of Google maps.
If we're going to continue to have a mixture of HTTP and HTTPS pages on a site, then several measures come to mind ...
1. We have to re-authenticate the consumer each time that s/he enters a sensitive page or section of pages. Checkout, my account, etc. That's not hard, but it's also not out of the box on ATG. (At least, it wasn't prior to release 10. I haven't validated that on the latest release.)
2. We have to change the session token frequently.
3. We have to avoid including the jsessionid in the URL.
4. Cookies must have secure and HTTPOnly flags set.
5. Sensitive data must never be written to browser local storage, even if encrypted.
What else? Maybe if we can define a complete solution, we can share pieces to bring together an implementation.
I think that purely going on HTTPS/SSL can probably be the best way to rule out any possibility of firesheep like sniffing. I guess you would have already gone through with these OWASP resources on the topic:
Form ATG standpoint, I know of one countermeasure which is provided OOB in ATG but it is targeted more towards cross-site scripting attacks. You may still want to consider it for including in your list. It involve setting the "requiresSessionConfirmation" attribute on the applicable <dsp:form> or <dsp:a> tag. When requiresSessionConfirmation is set to true in those tags, an additional dynSessConf parameter is included in the HTTP request. Its value is randomly set based on the current session-id and can be different each time server's response containing tag output is sent to the browser. The DAFDropletEventServlet in the ATG servlet pipeline then validates this dynSessConf value in the incoming request from the form or an anchor.
Another related point is the usage of <%=request.getRequestURI()%> commonly used in the ATG form action attribute. Instead of simply using this I think it would be better to escape the output if it contains other parameters and some ids using ATG's ServletUtils as:
Apart from these ATG specific pieces, one more approach can be to store a session variable that contains user's IP, user-agent etc. or may be a hash of all these and then check it in a filter for each request. Although it may not be a perfect solution but can help to some extent.
Yes, I'm intimately familiar with OWASP. But it's a good reference for others that might be following this thread.
For now, I'd like to stick to session hijacking mitigation. I know that other forms of attack, such as XSS, DDOS, etc. are possible, but those are different discussions and I'd rather not stray from the main topic.
As to the retrieval of the request URI, that's a good point but it doesn't really apply to hijacking either (unless I'm missing something here). Besides, I would never put inline java in my JSP's. I use custom tags or droplets instead, so any validation and escaping would be encapsulated there.
Now as to keeping session related things in session attributes and validating against them in an HTTP Request Pipeline processor, that's a good idea. I've been pursuing similar techniques for the load balancer (Foundry Big-IP), where that's easily done. But having similar countermeasures in an ATG processor makes sense. I'll include that in the list going forward.
I did some checking on what other large sites are doing. Of the 43 large ATG sites that I checked, only 1 is pure-SSL. The remaining 42 are all using a mixture of HTTP and HTTPS pages. Of the top Internet 100 sites, all are using a mixture.
So it's obvious to me that folks aren't following the pure-SSL dictate. For obvious reasons, impact to page rendering speed, impact to caching, necessitates more recent hardware (with onboard encryption support). Loss of speed == loss of income.
Given that, what are people doing?
I hope that this issue isn't being ignored in the mainstream. Because recent tools like fire sheep make it trivially easy to hack a session.
Come on, folks. Are you telling me that nobody is concerned with session hijacking? It's so easy that a high school hacker could grab your customer's session and use their data maliciously.
I've only come up with one mitigation that's built into ATG. I believe that you can configure it to use different sessions for SSL and non-SSL. But my understanding is that a side-effect of the implementation is that it will create a new non-SSL session for each non-SSL request. Which means that page performance and scalability would suffer tremendously. I haven't tested this yet, though, so don't take it as gospel.
Doesn't anybody from the ATG (or WebLogic) world in Oracle have anything that you can contribute?