Javascript - Security of document.cookie

Question

I have an application that creates Cloud Front cookies using the AWS CloudFront API and Lambda. Unfortunately I can't set cookies using the standard HTTP response format and have to use document.cookie to set cookies to my users' browsers from an HTML page. The cookie includes a policy to grant access to content, a signature to confirm authenticity of the cookie, and key-pair ID. A back-end script on Lambda creates the cookie and sends it to the requester as a payload, which then gets passed as a variable to document.cookie.

I've read a lot about securing cookies (HttpOnly, session cookie, secure flag, etc.) and I'm trying to understand the security risks of document.cookie. Is there a difference between setting cookies through Http response and document.cookie in the context of security? Would it be possible for a malicious user to insert their own policy into the cookie as the cookie is created client-side, giving them access to other content despite the page being read only?

Here's some code for reference:

payload = data["Payload"]
jsoned = JSON.parse(payload)
cookie = jsoned['cookie']
redirectUrl = jsoned['redirectUrl']

document.cookie = 'CloudFront-Policy' + "=" + cookie['CloudFront-Policy'] + "; path=/mydirectory";
document.cookie = 'CloudFront-Key-Pair-Id' + "=" + cookie['CloudFront-Key-Pair-Id'] + "; path=/mydirectory"
document.cookie = 'CloudFront-Signature' + "=" + cookie['CloudFront-Signature'] + "; path=/mydirectory"

My first time posting to this. Thanks for the help in advance.

-Ken

Answer 1

Is there a difference between setting cookies through Http response and document.cookie in the context of security?

Not really. An HTTP cookie can be set with httponly , but that's a only very weak mitigation against XSS, not really a proper security measure in itself.

Would it be possible for a malicious user to insert their own policy into the cookie as the cookie is created client-side

Yes, but it already was for the HTTP cookie; they're both stored client-side and thus within reach of an untrusted client.

This is what the signature is for, right? If it's correctly implemented it should prevent tampering with the content it signs.

Answer 2

Nothing of "direct" value should ever be stored in a cookie, period.

All validation / processing of the cookie's value should occur server-side (regarding any sensitive information) and the only thing a cookie should contain is some sort of guid (or perhaps a couple of guid's.) And all "client-side" id's that are stored in a cookie, should be encoded in a manner to both prevent tampering & detect tampering on the server side.

In reference to the comments, I stand by this statement ...

• "Any information given to the client, should be considered compromised."

... and will expand my answer ... You have no idea what "client application" will be used as it doesn't have to be a "browser" (Postman / custom apps can interact with your website directly, with the intention of directly examining everything you send) as well as proxies (or worse malicious man-in-the-middle apps), network sniffers, etc ... so that being said, both the "client side application / 'loaded page'" && any other data (including cookies) should be considered compromised from the perspective that you should 'not' consider any aspect guaranteed with respect to a future client response.

ie Here is an example of a vulnerability...

• you have a site that uses the value in a cookie to restrict (using client-side javascript) the options in a drop-down list (or some other functionality)
• this would be a bad practice, as the user can attack this many different ways...
  • "modify" the cookie values
  • "edit" the client side javascript in many ways
  • "manually" submit any "response" to your web application endpoints
    • essentially spoof any value to any input

So in summary, anything given to the client should be considered "insecure", and you need to handle any "return values" from the client as "compromised / malicious".