Kochure is a module i developed as part of my final year project based on "Mitigating HTTP Session Hijacking", This article is a discussion of the module we came up with, the implementation of this model in the form of an apache module, and the testing and results of this module. Whe
After Extensive Research on session hijacking attacks and several proposed solutions, we have decided to use a combination of a client’s IP Address, session identifier and user-agent string to mitigate session hijacking attacks.
Our model works by linking the user’s IP Address to that user’s session identifier and user-agent string. When a user first visits the website, their IP Address and user-agent string will also be stored; so when other requests are sent using that session identifier, it must come from a user with the same IP address and user-agent string. If the information doesn’t match, we can safely conclude that that user’s session has been spoofed, and reset the session identifier.
Our model also regenerates session identifiers after a specified time (set by the website’s administrator), so even if an attacker successfully carries out a session hijack on a user’s account, the session identifier will be regenerated after some time, and the attacker will lose access to that website as that user.
We can conclude that with our model utilized, the only way an attacker can carry out a successful session hijacking attack on a user session is if that attacker has the same user-agent string, IP address and Session Identifier as the user.
If attackers are on the same local area network as users, they can simply spoof all users’ information passed over the network. Therefore, our current solution will be useless, since an attacker can spoof a user’s IP address and user-agent string and use it as their own to fool the server that they are that user. Our model deals with this by implementing an Intrusion Prevention System (IPS) on local area networks. An IPS will protect users from session sidejacking attacks over local area networks. Below is a diagram of how our model will be implemented.
The developed apache module was implemented on a web server which hosted a website on it. Note that this website had no mechanism in place to prevent session hijacking, and did not implement secure connections. Our testing shows that the website without the module installed on its server, was prone to session hijacking attacks. On the other hand, the website with the module installed on its web-server was almost 100% secure against session hijacking; several methods of session hijacking were tested, none was successful although with the use of some of the methods, we did manage to steal session identifiers, but since the module also authenticates users based on IP address and User-Agent string, stealing just the session identifier is not sufficient.
An automated testing environment was needed to test the performance of server with this module installed to test the feasibility of using this module, apache benchmarking tool was used to test the performance of the server without the module installed and the performance of the server with the module installed. The following results were obtained.
The above results are from requests sent to the server over a sixty (60) second period. The above results show the amount of requests completed over this period, the amount of requests per second, and the time per request. By comparison, it can be seen that the server with our module installed (Server 1) completed approximately 0.2% less requests than a server without the module installed; Requests to the server with the module installed also took approximately 0.3% more time to complete, and the time per request for a server with the module installed is approximately 0.26% more than that of a server without our module installed. It can be noted that this module was tested on a simple web server that is very low on system resources; therefore, this module may perform better if it is used on high performance web-servers.
Based on the Development, implementation and testing of the model developed (in the form of a web server module) to protect users against session hijacking attacks, we can make several conclusions:
With this module implemented on a website’s web-server, the only way an attacker can gain access to a user’s session on a website is if the attacker has the same IP address, session identifier and user-agent string as that user. This is not very probable due to the facts:
o IP addresses are almost unique, IP spoofing, as discussed earlier, is not a feasible attack, unless the attacker is on the same LAN.
o User-Agent Strings are almost unique, and is very difficult to spoof unless the attacker is on the same LAN.
o An IPS would be implemented on LAN networks which would prevent all man in the middle attacks including IP spoofing and user-agent spoofing.
It can therefore be concluded that this module is very effective in preventing session hijacking.
From the results shown and discussed earlier, it can be concluded that this module is feasible to be used on a web-server since there would be only approximately 0.25% degradation in the performance of the web-server. This performance degradation may be less for high-performance web-servers. This module also helps to mitigate all types of session hijacking attacks, and is not limited to any of the attacks.