Is it correct to use form field(hidden) for storing Session Token

Question

Is it correct to use form field(hidden) for storing Session Token instead of using Cookies? What is the security risk associated with it?

Answer 1

To be protected against CSRF while also hardening against XSS, store your session IDs in cookies (with httpOnly flag) and use separate session-bound form tokens that you validate upon POST. By combining these methods, you prevent an attacker that has found XSS from stealing session IDs, while you still protect against CSRF in a meaningful way. Using the session ID as form token enables an attacker to steal the session ID through XSS.

Answer 2

IMHO, by far the biggest disadvantage is that you need to explicitly add code to repopulate the session identifier into each and every page, potentially in multiple places. Using a form field is only going to work where you've got a form and that's the only way to navigate off the page.

So you also need to add code to parse every href on the page and add the session id (since you don't want to send your session id to other sites).

What about ajax requests? Javascript driven navigation?

You should also be change the session id at authentication - so you've also broken the behaviour of the back button.

Yes, you can solve all these problems by throwing code and effort - but more code = more bugs = less security.

Another consideration is that some applications use multiple session identifiers - managing this outside of cookies would be an even bigger PITA.

Answer 3

No, you should not use GET or POST parameters for session identifiers. Session ID should only be transmitted via HttpOnly cookies.

There are at least three reasons for doing so:

• Session Fixation attacks. The attacker can entice victim user to visit a page with a form containing his session id in a hidden field. Submitting the form will have the victim being authenticated as attacker (and any actions he later on performs on the target website will be done with attackers' credentials)

• any XSS flaw in your website will directly allow the attacker to hijack the session whereas storing session id in HttpOnly cookies prevents that from happening

• content extraction attacks - there are a few UI redressing techniques for extracting the HTML content of a target website, therefore leading to hijacking user's session. One example of such attack requiring user interaction is Facebook token access extraction, which involves displaying the HTML source of a victim website in an invisible IFRAME and enticing the user to select it and drag it out to attacker's textarea; if the session ID is included in the HTML document, then this reveals the session ID to the attacker. Also, when the website allows cross domain communication (e.g. with using permissive crossdomain.xml), content can also be retrieved via Flash without user interaction. Therefore, the session ID should never be displayed within the HTML page source.

To stop CSRF, it is important to also include a CSRF token in a hidden form field or in the URL of every POST request. However, the CSRF token does not need to contain the session ID, and it is safer if it does not contain or reveal the session ID. A safer choice is to use a random nonce or a one-way hash of the session ID as the CSRF token.

Answer 4

Three common approach for transfer of Session Identifier between Browser and Server

1. Cookie
2. Hidden Fields
3. URL

All have their advantages and disadvantages, but since you asked about Hiddel Fields only here are few advantages and disadvantages

• Adv: Less prone to CSRF as Session Identifier will not travel in Cookie and will not be implicitly sent by browser
• DisAdv: If developer uses a GET method or appends parameter to URL your session identifier would be exposed in browser history, proxy logs, web server logs etc.
• DisAdv: Session identifiers being cached along with the page if caching is not disabled
• Adv: Dont have to worry about marking cookie secure or HTTPOnly etc or worrying about expiry of cookie
  • DisAdv: you have to send it back in all responses, increasing size of your response
  • Adv: Don't have to worry about Cookies being disabled on user browsers

Thats what I can think of right away, may be others can point more advantages and disadvantages

And yes I am assuming you have your Server Side Session Tracking and management code and logout logic written correctly