The second article of this series is dedicated to hijacking flaws (ranked #2 on the Owasp Top 10). That term might sound quite familiar to you, maybe not, or perhaps you don’t exactly get what that vulnerability is about, but the way it works is quite easy to understand. Hijicking is about the possibility for a hacker to use other users’ identity on your website.
If we have a look at the statistics, we can see that this vulnerability is quite prevalent, which is a good reason to have a closer look at it, for both attackers and development teams. In terms of exploitability, this flaw can be considered as intermediate: detecting it is not extremely easy (though not hard to detect), and using it once discovered is relatively easy.
The impact of such a vulnerability will entirely depend on what your web application offers as services to its users. Once exploited, meaning once the attacker impersonated the victim, all functionalities the victim had access to can be used by the hacker. That simple.
As an example, exploiting the vulnerability on an commerce website will allow the attacker to order products on behalf of the victim. If the payment information has been remembered by the website during a previous order, or if it is possible to change the delivery postal address without re-logging in, the trick is even easier for the attacker.
Just imagine you give one of your users’ credentials to a hacker and you will get an idea of what the impact of such vulnerabilities can be. The possibilities are unlimited.
In which situations might a website be vulnerable to this kind of attacks?
First, if the authentication credentials (login / passwords) are badly secured inside the website itself. In a situation where a hacker can have access to the website’s database, no matter how he achieved that, he can then access the full list of logins and passwords. The good practice here is to properly hash of encrypt passwords in the database, to avoid any exploitation by the attacker.
The second possibility is to easily guess or modify the authentication credentials. A strong password policy must be adopted, to ensure users do not use weak passwords anyone could guess. Moreover, password recovery and password change features, if badly designed, will allow the attacker to change or recover the password on behalf of the victim!
The third possibility is a bit more technical and exploits the weaknesses of the mechanics that allows a web server to remember who you are, once you successfully logged in. By nature, the communication protocols between the web server and your web browser do not remember who you are. Some features therefore have to be implemented so that you can be remembered. That’s what we call the session management, and the famous “Session ID”. This “Session ID”, usually stored in the cookies of your browser or in the URLs, can have several weaknesses if poorly secured:
– easy to guess
– easy to attribute to the victim (by the attacker), hence exploitable
– without expiration system
– always the same for a given user account along visits
We will not go much more into the technical details here, but knowing the Session ID will in many cases allow the attacker to impersonate your users.
Last, but not least, if authentication credentials (including the Session ID) are sent back and forth between the server and browser without encryption over HTTPS (SSL/TLS), then they can potentially be intercepted by a hacker.
How can we avoid such vulnerabilities?
It is quite hard to create a strong authentication and session management mechanism from scratch (quite difficult and time-consuming). Moreover, if such a mechanism is not tested by several developers, it is likely that it will be vulnerable. Luckily, many ready-to-use and strong authentication and identity management modules are available!
Development frameworks like Microsoft .Net, of Java, or PHP have such built-in mechanisms that should be leveraged by developers.
Password recovery and password change feature must be carefully designed in order to avoid stupid logical flaws.
There is no industry standard for these mechanisms, hence the large variety of recovery logics you can find on the Internet.
Learn more about authentication and session management:
Other articles in this series:
- Understanding web vulnerabilities in 5 min – episode #1: injections!
- Understanding web vulnerabilities in 5 min – episode #2: Hijacking!
- Understanding web vulnerabilities in 5 min – episode #3: XSS, Cross Site Scripting!
- Understanding web vulnerabilities in 5 min – Episode #4 – Insecure Direct Object References
- Understanding web vulnerabilities in 5 min – Episode #5 – Security Misconfiguration
- Understanding web vulnerabilities in 5 min – Episode #6 – Sensitive Data Exposure
- Understanding web vulnerabilities in 5 min – Episode #7 – Missing Function Access Control
- Understanding web vulnerabilities in 5 min – Episode #8 – CSRF Cross Site Request Forgery
- Understanding web vulnerabilities in 5 min – Episode #9 – Using vulnerable third party components
- Understanding web vulnerabilities in 5 min – Episode #10 – Unvalidated redirects and forwards