Session ID Transmitted Insecurely

A session id may be sent via an insecure mechanism. This occurs when using HTTP rather than HTTPS and when the cookie is sent in the request. In case the cookie is sent by the server in the response (when the URL is modified by setting the named parameter field to NULL), the ‘secure’ flag is not set, which allows the cookie to be sent later via HTTP rather than HTTPS.

This makes the possibility for an eavesdropper to get access to the session ID passively on the network path and gain full access to the victim’s session (Session Fixation attack[link to Session Fixation]). With such information the adversary is able to perform further attacks impersonating the authenticated user.

1. Use the latest available version of SSL/TLS (for HTTPS) for all pages where a session id is communicated between the browser and the web server.
2. Do not allow the communication to be forced down to the unencrypted HTTP protocol.
3. Use the 'secure' flag when setting a cookie containing a session id, to prevent its subsequent transmission by an insecure mechanism.
4. Forward non-secure HTTP page requests to the secure HTTPS equivalent page.

ScanRepeat validates the existence of a ‘secure’ flag on session cookies and checks the protocol used for the transmission of session ID. It reports every occurrence of such a vulnerability providing the URL of an issue found along with the cookie identifier and its value.