This content has been marked as final. Show 6 replies
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?
I can't speak to what other people are doing but we have proposed a solution that id documented here: Protecting Against Session Hijacking (Doc ID 1369114.1).
I would be more than happy to discuss other ideas in the MOS Community: https://communities.oracle.com/portal/server.pt/community/atg_web_commerce/501
Hope all is well,