Session cookies constitute one of the main attack targets against client authentication on the Web. To counter these attacks, modern web browsers implement native cookie protection mechanisms based on the HttpOnly and Secure flags.
…
Our analysis of the Alexa-ranked top 1000 popular websites gives clear evidence that such risks are far from remote, as the HttpOnly and Secure flags appear as yet to be largely ignored by web developers.
– CookiExt: Patching the Browser Against Session Hijacking, Journal of Computer Security (2015).
Summary of Session-hijacking attacks
When you login into a website, the web-server creates a “session” to identify your identity by sending the client browser a session cookie. Cookies have functions other than sessions, but perhaps the most important use of cookies from a security perspective managing your “state” or “session-state”. This is because a single IP address may have many clients connecting to the server, so IP alone cannot identify an individual. The same goes for port. When connecting using HTTP Each browser / HTTP client selects a random port in the dynamic port range (49,152 – 65,535) and sends from / receives at that port. So, collisions are too likely to occur to use client source port as a unique identifier. Thus, every time a client sends data to the web-server, it includes cookies in the HTTP header, which allow the web-server to distinguish the client identity.
Session hijacking is a web-based attack where a bad actor is able to obtain the session cookie of a session between the user’s browser web-client and the web-server. Imagine you were visiting your bank website and someone was able to see all the data going in between. If that someone was able to extract your session identifier from the cookies being transferred, they would have the most critical piece of information needed to impersonate you to the bank’s web-server.
Session cookies are not persistent, meaning that they will change each time you log in and out of the bank website, but theft of your session cookie still gives the attacker some time to attempt to impersonate your session, and perhaps steal all your money.
XSRF and XSS
There are a few well know vectors of attack on session identifiers. Two of them include Cross-Site Scripting (XSS) and Cross-Site Request Forgery (XSRF). Both of these attacks operate by managing to inject Javascript into the client browser where it can access data and sent that data to the attacker. In the case of session hijacking, the Javascript injected would target your cookies. Client mitigation of XSS and XSRF depend heavily on the web administrator properly configuring their web-server and also being careful about installing browser plugins that may be malicious.
HTTPS Downgrade Attacks
A third method of targeting session data is to attempt to downgrade the protocol of a client / server connection from HTTPS which is encrypted to HTTP. This will allow all data, including HTTP headers that contain cookies to be sent in clear-text. As pointed out in the paper CookiExt: Patching the Browser Against Session Hijacking, Journal of Computer Security (2015), some websites are only partially encrypted, meaning that some pages or resources such as images are not sent over HTTP. This opens the door to session hijacking because when a client requests those non-HTTPS resources cookies are – by default – sent along with the request. Even getting a user to simply click on an http:// link instead of an https:// link to a server that only allows HTTPS can result in session cookies being exposed since the first request would be sent by the client using HTTP instead of HTTPS, before subsequently being redirected to reform the request using HTTPS.
Configuring Apache To Limit Cookie Access
As a web-server administrator you should want to limit the use of your session cookies, for many reasons. Firstly, the security of your clients. Secondly session hijacking can potentially increase your costs by forcing you to deal with remediation of your users accounts being hacked.
The method to Implement HTTPOnly and Secure Cookie in Apache is to add a line of code to your httpd.conf file. First let’s take a look at the output of a simple Javascript script that will print the session cookies. Remember that this script can also be used to send those cookies to a remote web-server owned by an attacker.
If you are not limiting the use of cookies in Javascript adding this simple script to a web-page can show you the cookies that are being transmitted between a browser and the web-server.
Accessing a page with this script will show your cookie on the screen, but these cookies can just as easily be sent to a remote server owned by the attacker.
Edit the httpd.conf file:
Add the following line of code to the bottom:
The following script commands will print the web-server’s HTTP-Headers to the terminal so you can inspect them and see that the HTTPOnly and Secure Cookie headers have been set properly.
You will see an output like this:
From this output you can see the headers are present:
Now check again to see if the page with the Javascript will allow access to the cookies… Nope.
Further Security Is Still Recommended
As internet users we cannot simply rely on web-server administrators to configure their servers properly. History has proven that web-admins too often do not apply the diligence they should. So, more robust security features built into our clients makes sense. For example, restricting our browser from ever making an HTTP request and instead demanding all requests be made with HTTPS will ensure not only that our sessions cannot be easily hijacked.
Leave a comment