The Hypertext Transfer Protocol, popularly known as the HTTP is an application layer protocol used to access web resources over the internet.
There is a provider of the web resource, called “Server” and a receiver, called “Client”. The client initiates the communication by sending an HTTP request, “requesting” for the web resource. The server “responds” back with an HTTP response, providing the web resource (if available).
All good? One problem, HTTP is a stateless protocol.
You might have come across this line a hundred times but what does it actually means?
Well suppose there is a Client “A” which makes a request to the Server “B” over HTTP. The server then responds back with a response.
Now, “A” isn’t done yet, so it sends another request to “B”:
It’s a pretty big problem considering the advancements of today’s websites and web applications.
So how do we tackle this? How to make HTTP “act” stateful?
Before coming to that, there is one more question to ask. Why? Do we really need to make HTTP behave stateful? Can’t we just accept it for what it is?
Consider this, you want to access your Facebook profile. You open the website in your browser (the most well-known example of “Client”) and enter your credentials and submit, an HTTP request is generated and sent to the server:
The Facebook server verifies the credentials and provides you with your profile page in the response.
Now you’ve done with viewing your profile and want to access one of your albums. You click on the thumbnail and your browser sends an HTTP request to the Facebook server:
And it sends you the login form. Now you need to once again provide your credentials to watch your pictures. Not Cool!
Now we have answered the need to make HTTP act stateful. Let’s jump into how this is actually achieved.
In the world of HTTP there are 2 data formats:
Session
A web session or HTTP session is a sequence of HTTP request and response transactions with the same client. It is basically an “object” (OOPS!!). Each session has a unique “id”, called a session id or a session token.
This session object is stored (actually “maintained”) on the web server.
Now, when the client “A” send the first request to the server “B”, the latter generates a session, assigns this session a unique id, say “b9ed9698ofoulp3e0e3icc0810” and logs the request and response into it.
“B” expects to identify “A” on the basis of this session id “b9ed9698ofoulp3e0e3icc0810”.
This all happens on the server, so how will “A” ever come to know about the session id? How will it be able to use it as a mean to identify, technically “authenticate” itself to the server “B”???!!!
Cookie
Yup, the HTTP cookie.
An HTTP cookie is a small piece of data in “{name}={value}” pair which is stored on the client side (browser).
A website can “set” a cookie into the client using the “Set-Cookie” response header and the browser then sends this cookie to the server with each subsequent HTTP request using the “Cookie” request header.
Now, let’s elaborate the above example.
Well, this is how the real scenario looks like:
The following request is generated while accessing an URL [Note: This is the first time I’m visiting this site]
The following response is received, notice the Set-Cookie headers:
In the next request it is evident that the “cookies” are send to the server inside the value of “cookie” header:
So, when this request reaches the server it analyzes the “PHPSESSID” cookie and acts accordingly.
You may have noticed “Path=/” and “HTTPOnly” in Figure 5.2, these are a couple of cookie attributes. But more on that later.
In the forthcoming blogs I’ll explain these cookie attributes and the security threats that can be caused due to mishandling and mismanagement of session.
