HTTP is a “stateless” protocol. Which means there is no “built-in” standard to keep track of interrelated requests. Each request is treated as independent. Currently, most of the web applications are using HTTP 1.1 which was released in 1996. These web applications are very advanced and usually handle complex operations which take more than one pair of request/response to complete, this requires something to track the present state of operation. These apps also present tailored content to each user. This requires identifying a user across multiple requests. So there must be something that adds an “enhancement” to HTTP.
There are solutions that are the results of clever thinking by web programmers.
HTTP uses client-server architecture and uses TCP as its transmission protocol and multiple requests can be sent over just one TCP connection, but these are also considered independent by both client and server. There are two aspects of session in HTTP as discussed above. There are mainly two ways to achieve tracking across requests.
1. Request Parameters :
The token that represents the current state of a multistep process or identifies a user can be stored by the server on the web page in a form field, which will be auto-submitted each time user performs an action. The token is contained as a value of an input field. This token can be submitted as either a GET request parameter or a POST request parameter. The request parameters in a GET request are embedded in the URL and these are recorded in the browser history. While POST submits the parameters as request body so it doesn’t get embedded in URL and doesn’t show up in browser history either. Obviously, for submitting sensitive information POST requests should be used, while GET requests can be used for information that is sensitive. For example, if the token is an identifier for a user it must always be sent in POST request. Non-sensitive examples of tokens include state identifiers, referrer values etc.
There is another way of sending identifiers in GET requests. Which uses path name instead of parameters.
Cookies are name-value pairs that are stored on the browser and submitted automatically in subsequent requests. The server generates them and sends them to the client by using “set-cookie” HTTP header. A cookie is submitted using “cookie” header.
The cookie header sends name-value pairs separated by semicolons. The set-cookie header contains extra directives and parameters for cookies. These help browser in understanding how and when to submit them.
The most common parameters are- domain, path and expires while the directives are – “secure” and “httponly”. The domain parameter specifies the domain for which cookie is valid, the cookie will also be valid for all its subdomains. The path parameter specifies the URL path. Expires is self-explanatory.
Tracking sessions require generation, transmission and storage of sensitive tokens. Any misconfiguration at any stage may put the security of users’ data at risk. There are some points that should be kept in mind while developing an application that maintains user sessions.
- Never send any token over an unencrypted channel(HTTP).
- Invalidate tokens on server side when user logs out, just clearing cookies on user’s browser is insufficient and may lead to permanent account takeover.
- Always implement CSRF protection on sensitive actions that require authentication.
- Never submit anti CSRF tokens in GET request (and don’t even think about submitting session tokens in a GET request)
- Always use nonce and padding while generating sensitive tokens and avoid using reversible encoding schemes like Base64.
- Do not store passwords on the server in plaintext. Always hash them and store the hash. This will protect user’s from an unfortunate event of a data breach.