1

There are several uses for a cookie, and I would like to offer some kind of guarantee that a cookie is being used for a specific, limited purpose and scope. In my case, I want to prove that a cookie is only used for authentication.

Question

Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee?

Example

In the example of a session cookie, I envision that the normal session parameters would apply

  • The scope would be restricted to a one, or a very limited set of URLs,
  • Set to HTTP only

Some added security requirements would look like this:

  • The client generates the cookie name and contents from a cryptographically random source
  • The client sends this preferred cookie to the server at the same time the credentials are sent
  • If the cookie doesn't conflict with an existing session, the server accepts it and uses it as a bearer token for the remainder of the session

Does a similar, or better solution exist for people who are concerned about cookies, tracking, and other aspects of privacy?

Community
  • 1
makerofthings7
  • 50,488
  • 54
  • 253
  • 542

2 Answers2

1

I don't think this will provide any benefit. On a secure web application, the less you depend on client data, the better.

I can see some issues:

  • This will surely create a vulnerability named Session Fixation: an attacker can create a session, lure your client to a special page, and have the session data on his hands.

  • The server has no means to know if a session sess12345678 is being cloned, or the client switched IP, or if the client is using a load balancing proxy. If you lock the session to an IP, mobile clients can have trouble.

  • If your client application token have not sufficient entropy, it's trivial to an attacker to bruteforce lots of possible values.

  • Any cookie created by your application can be read by Javascript, so an XSS can send them all to an attacker.

  • You are increasing substantially the complexity on the server side, because you will have to validate both the cookie name and value.

  • Creating a cryptographic secure cookie and value on the client can be hard, and the generation can be easily spoofed or bypassed by an attacker.

I would stick to secure cookies to authenticate the users.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • How is bullet #2 any different than a normal cookie? – makerofthings7 Aug 07 '15 at 19:13
  • Regarding the cookie being read by Javascript, and a XSS I was assuming that a plugin or other hypothetical change to a browser would prevent this from occurring. – makerofthings7 Aug 07 '15 at 19:14
  • On second thought Perhaps a random cookie name isn't required... but I do appreciate the feedback – makerofthings7 Aug 07 '15 at 19:15
  • bullet #2 is different because on a normal cookie, your server generates it, and you have more control over it than the vast amount of javascript engines present on your clients multiple browser and OS versions. – ThoriumBR Aug 07 '15 at 19:24
1

Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee?

I don't think you can provide such a guarantee, except by perhaps saying so in your privacy policy and then following that policy.

The scope would be restricted to a one, or a very limited set of URLs,

Setting scope can be done by the secure flag and by the domain and path attributes when the cookie is set. However, it is very hard for the end-user to track this using a normal browser; Say you restrict your cookie to the path /loggedIn. If the user visits your URL /information, on first glance it appears that your site won't be receiving the cookie for requests to this URL. However, the page may be making requests to /loggedIn using JavaScript or via resource requests, enabling the user to be stealthily tracked.

Yes, a privacy concerned user could check this. However, if they were that concerned about privacy they would simply clear their cookies anyway, making your complex cookie policy and implementation useless.

The client setting the cookie name and value doesn't solve this problem. You could be still tracking the user server side using the cookie name and value information. I disagree with ThoriumBR about Session Fixation because I don't think that this increases the risk of such an attack. If the attacker can set the cookie on the victim's browser, then it is irrelevant whether this cookie is a user chosen name and value or a sever chosen name or value. Also it doesn't change the risk level of another similar vulnerability - Login CSRF. Yes if the vulnerability exists then the attacker could log in the user into the attacker's account and set the cookie name and value, however setting the cookie name and value doesn't add any value in itself.

If you're concerned that using cookies will dissuade privacy conscious users from using your site then you do not need to use them at all in order to maintain client-side state. One way is to make your site work via post-backs only. That is, every site action and navigation causes a POST request to be made, and the POST data contains a token to server side state.

e.g.

<form method="post" action="/siteAction">

  <input type="hidden" name="token" value="aaaaaaaaaaaaaaaaaaaaaa" />
  <input type="hidden" name="action" value="navigateAccountPage" />
  <input type="hidden" name="params" value="{foo: 'bar'}" />

</form>

*params should be html encoded, however left out for simplicity's sake

This will allow you to store state client-side without the need for any cookies. The user knows they are not being tracked as they can simply check their browser cookies and storage (technically HTML5 storage, Flash and Silverlight to be thorough).

Community
  • 1
SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
  • Perhaps I should be more clear in my intent. I have a custom privacy preserving TCP client that mostly does HTTP/1.1 actions. Since this is residing in an EXE I want to redefine the authentication mechanism to be more private that what is currently available. Privacy is my key selling point. The problem I have with the POST and the cookie is that the SERVER assigns the value. When this assignment happens, it *might* correlate to other backend data. By the client choosing the bearer token value, then the client knows what it's carrying around in a blob.. – makerofthings7 Aug 14 '15 at 22:15
  • ... otherwise the client might be carrying around "system state" from ASPX days. https://msdn.microsoft.com/en-US/library/ms178581.aspx ... by the client choosing the data to post, they are in fact defining their existence to the server in its entirety – makerofthings7 Aug 14 '15 at 22:16
  • Even if the client sets the value the server could be storing data server side by using the name value pair as a unique token, unbeknownst to the client. – SilverlightFox Aug 19 '15 at 13:07