CODEWITHSUNDEEP
javasecuritytomcatcookies
petrus
petrus

Reputation: 31

setting secure cookie through proxy servlet

I have a web application which is accessible to users through proxy sevlet - part of bigger web application. Communication between browser and bigger application is encrypted by ssl. From my embedded application I would like to set a secure cookie which indicates users' session. Communication between proxy servlet and my web application is not encrypted, so when I set session id cookie it doesn't have secure flag. My application is running on tomcat and response from this tomcat is proxy'ied to client's browser by proxy servlet.

Will this cookie be secure and unable to hijacked by others, despite the fact that is not indicated as secure? Can browser send back cookie in not secured connection in that situation?

edit:

I will specify a little bit more architecture of that sollution to make it clear:

There are 2 web applications, each one has its own session: 1) one is accesible directly to users and communication between it and browser is encrypted by SSL. (application X) 2) second is not accesible to users, but is proxy'ied by servlet from application X (application Y) Servlet is also proxy'ing http headers.

Architecture looks like on this diagram:

client browser| <-SSL-> |Application X (proxy servlet) | <-internal network, no SSL -> |application Y

I would like to set cookie in client browser from application Y that indicates session. Cookie header is taken from application Y to X and set into the client's browser, but unfortunately this header doesn't have secure flag. I'm not sure wheter it will be send back by browser in secure connection or not.

Upvotes: 2

Views: 1966

Answers (2)

Marcus Adams
Marcus Adams

Reputation: 53870

It seems like the user's web browser connects to your web proxy server remotely via HTTPS, and your web proxy server connects to your application locally via HTTP.

You may still be able to set the cookie as secure by manually setting the secure option for the cookie, or manually creating the cookie header. Generally, a web/application server ignores settings on outgoing cookies. Instead, it's generally up to the browser to enforce the rules.

It's important to send the cookie with the secure option to the browser, so the browser knows not to send the cookie back unless it's over HTTPS, thus preventing eavesdropping. You should also include the httponly option for the cookie.

Adding a nonce would not provide any additional protection here because if the victim can be convinced to send the request out unencrypted, the attacker will be able to capture both the cookie and the nonce.

This is not to say that nonce's aren't good on their own to prevent replay attacks, even over HTTPS, but it wont prevent session hijacking.

Upvotes: 1

Mike Thomsen
Mike Thomsen

Reputation: 37526

This really isn't a good way to secure your web app because the most important area of communication (between the browser and however they get to your app) is not encrypted. That is the area most likely to be snooped on by others. Cookies are inherently insecure without SSL because without SSL there is no way to encrypt them. They're just part of the HTTP transaction (and thus are only as secure as the rest of it).

Sessions are pretty much inherently safe from tampering if the HTTP transactions happen over SSL because the cookie only contains a fairly unique ID code pointing to a storage compartment on the server for the user's information in the servlet container.The only way someone can hijack that is they can intercept the cookie and make their browser use that cookie. Again, SSL is your best bet there.

Now, you could use something like a nonce to add additional security on top of SSL. There are plenty of apps out there that use them if you want to look at live examples.

Upvotes: 1

Related Questions