Sending session cookie inside the HTTP response body

Question

It's known that the secure practice of setting a session cookie is using Set-Cookie header with Secure and HttpOnly flags. But is there any security issues with sending cookie inside the HTTP response (and request) body? For instance, like this:

HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 09:23:37 GMT
.........
.........
.........

sessioncookie=abcdefgh

And what if I set cookie using Set-cookie AND also send in the HTTP response body in the same HTTP response, would that lower security somehow?

Answer 1

Setting cookies in the body

You cannot set cookies in the response body (browsers don't look there for cookies), nor can your browser present cookies in the request body (the server won't look there). Cookies by definition are carried in the HTTP header (see RFC 6265).

Putting secure data in the body

You can certainly send other session data or tokens in the request or response body (e.g. it is common to pass a CSRF token in the body), but if you do so they are not cookies. Whether this is a good idea is a different question.

Most data is OK in the body, after all that is the only part that the user can see and sometimes the user needs to be shown sensitive data.

However, some data is not OK in the body. Anything that you wish to make unavailable to an XSS attack, for example, must not be in the body, and should only be contained in an Http-only cookie so that it cannot be read from the DOM.

That being said, some data is better off in the body! For example, anything that you don't want to show up default IIS logs should be placed in the body. Anything you do not want included in a session riding forged request (a.k.a. CSRF) should be included in the body and not as a cookie.

Setting data in both

It is not necessarily a security problem to set a token in both a cookie and the body. In fact this is exactly the pattern required by the Double Submit Cookie CSRF mitigation.

On the other hand, if you are just passing the session ID in the body for the heck of it, and it is a duplicate of an HttpOnly cookie, then you have just nullified any benefit of using the HttpOnly flag, since the same value can be read from the DOM.

Also, here's something really fun: If the site sets an HttpOnly cookie from the server side, and the same cookie value is passed via the page body and set via client script, your browser will end up with two cookies with the same name! This condition should be avoided because there is no HTTP specification that states which cookie should be presented in this case, and browser behavior will vary.