Usually with web applications, after the user has authenticated, the server will supply a session cookie to the browser, which is supplied with each subsequent request to the application in place of having the user supply their password with each request.
As such, if an attacker is able to steal a user's session cookie and make requests to the server, it is likely that the server will assume the request comes from the original user and provide access to the application, as long as that cookie remains valid.
All of this is speaking generally, in specific cases additional mechanisms might be used to mitigate the risk of cookie theft.
Multiple cookies can be issued by using multiple Set-Cookie headers in the server’s response. These are submitted back to the server in the same Cookie header, with a semicolon separating different individual cookies. In most cases, applications use HTTP cookies as the transmission mechanism for passing these session tokens between server and client. The server’s fi rst response to a new client contains an HTTP header like the following:
and subsequent requests from the client contain this header:
This standard session management mechanism is inherently vulnerable to various categories of attack. An attacker’s primary objective in targeting the mechanism is to somehow hijack the session of a legitimate user and thereby masquerade as that person