Clickjacking and HttpOnly JSESSIONID cookies

[Dave Briccetti]

Here are two security issues that I wish to better understand:

Clickjacking: https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)

JSESSIONID not marked as "HttpOnly", allowing access to malicious JavaScript

Thoughts? Does Lift have a role in preventing related attacks?

Dave Briccetti

[Dave Briccetti]

This is interesting. In August, 2011, I added a context.xml to an application specifically to set useHttpOnly OFF. My commit comment doesn’t say why, and I can’t find any discussion of it here. I seem to recall it was interfering with something. Comet, Ajax, REST? Any ideas?

[Antonio Salazar Cardozo]

X-Frame-Options is set to SAMEORIGIN by default since Lift 2.6, I believe. Not quite DENY, but

SAMEORIGIN is a better compromise for a framework, since you sometimes do want to embed

things on your domain.

In Lift 3.0-SNAPSHOT, we’ve introduced SecurityRules, which includes things like X-Frame-Options,

Strict-Transport-Security, and Content-Security-Policy.

The session cookie is typically the domain of the container, so you should be able to tweak your

jetty.xml or web.xml (for Servlet 3.0). We could add some hack code to make sure that’s always

done… It’d go with the secure by default principle, but it would be pretty nasty IMO.

Certainly we should have our default web.xml in our starting apps include the http-only flag.

As for setting it explicitly to off, I don't believe HttpOnly should be interfering with anything;

if it does, we should attend to it ASAP. At a glance, I don't see anything accessing

document.cookie in the repo, at least in 3.0, so I don't think we care.

Thanks,

Antonio