2

I've been doing some reading here about session ID handling, and have learned that it's generally a bad idea to include a session ID in the HTML source code, and/or on the query string. For example Is it correct to use form field(hidden) for storing Session Token and Why is passing the session id as url parameter insecure?

With that in mind, is there a secure way to handle sessions if cookies are disabled?

As an example, I noticed my company's shopping cart puts session ID's in a hidden form field (for the add to cart action), and if cookies are disabled they're also appended to query strings for all links. I checked a cached google page and sure enough google had cached its own session ID. I then grabbed that session ID and visited google's shopping cart - it was expired by this time. Still, I'm obviously not a fan of this being possible in the first place.

On a related note, when I pasted the first link above, it originally included ?newreg=XXXXXXX (looked like a session ID of some sort). I had just registered for security.stackexchange.com and was brought back to that URL. Maybe it's not a problem but I thought it was a nice coincidental example of how session ID's can accidentally be shared.

Community
  • 1
Mike Willis
  • 131
  • 4

2 Answers2

2

I'd say that it depends on your use case. If you look at an HTTP POST request there are essentially three areas where data can be placed, the headers, the URL and the request body.

If we're ruling out putting the token in the request body or in the URL, that leaves us with the request headers as a place to put the authentication token.

There are existing schemes that make use of this, for example HTTP Basic Auth, Digest Auth and NTLM Auth .

However each of those has got downsides and whether they're appropriate/secure for your application would depend on the application, the threat model and the user population.

If, for example, you're talking about an internal corporate Application where all the client machines are running variants of Windows, then NTLM auth would likely be a good idea.

If however you're looking at a general e-commerce set-up with a variety of end user Operating systems, it wouldn't be.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
0

There is a secure way which you've touched upon: Placing Session IDs in hidden form fields. However, they must be submitted by POST (i.e. in the request body).

The downside of this approach is that every navigation action is required to submit a form.

For example we could have a form to handle navigation on each page constructed like so:

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

    <input type="hidden" name="navigationPage" />
    <input type="hidden" name="sessionId" value="12345678" />

</form>

Upon a click within the navigation JavaScript will execute and set navigationPage to the appropriate value (e.g. myAccount, orderHistory, etc) and then submit the form. The /navigate URI will verify the sessionId and then navigate to the page specified in navigationPage if the session is valid. Using this method every page within your logged in session will have the same URI (www.example.com/navigate in this case).

This is secure in that the Session ID will not be leaked in referer headers in the case of any external links. External links can simply link directly to the resource and will not be the form POST that internal navigation uses.

Many banking systems employ a similar technique for extra protection against session hijacking within the session. In these scenarios sessionId in the hidden form field will be regenerated on each page load which ensures that only a single web browser is navigating at one time. However, this will prevent the use of the back button because it forces a resubmission of POST data, or of opening links in separate browser tabs because the rolling ID will not be updated in both places. This is often used in combination with session cookies but it can be used in isolation. Actions that require additional information like money transfers can simply include extra form fields to be submitted with the main form.

Another advantage of this approach is that it is inherently secure against CSRF. If another page makes a cross site request it will be missing the sessionId because it will not be automatically submitted the same way that cookies are.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178