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
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
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.
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:
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.