Secure Programming of Web Applications: Session-Hijacking

Added at 12/21/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book and online course "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers".

This article is about the programmatic safety of sessions of web applications - so the developer's point of view. A secure middleware configuration (like SSL/TLS), which is a basic requirement for this, is not part of this explanation.

Description

The essential goal of the attacker when attempting session-hijacking is copying or taking over a user session at a web application. Here, the authentication data of the users are not part of the attack.

After the successful login into a web application a session is created. That way, all further actions triggered from a certain client computer can be associated with a certain user. The common technology to link a session to a client is the creation and transmission of session IDs.

In practice, using cookies for this purpose is the most used technique which is generally regarded as most secure implementation (of course, in due consideration of corresponding security rules). An alternative would be the transmission as URL parameter (embedded into links or web forms) which has a couple of practical disadvantages and also leaves session data in the browser history.

As simple as the mechanism is - it is also simple for an attacker to hijack a session. Solely obtaining the session ID is all that is required. As a result, the attacker can access all transactions of the regular user - in case no authentication is required once again. This is why applications must not show passwords in cleartext or allow password changes without requiring entering the current password. In those cases, the damage would be even worse since an attacker might gain permanent control - maybe even undetected - over a user account.

Secure Programming:

For the secure implementation of sessions, one differentiates between measures and procedures on the one hand (1) and technical requirements on the other hand (2).

1) Measures/Procedures

1. A decision based on the business context (risk management) has to be made if sessions/cookies will not expire (permanent) or just be temporary. Then, session IDs and cookies have to be managed correspondingly.
   → Here, it has to be taken into account in which technical context the web application is used. For instance, an intranet application which is used in a shared computer environment should always remove all cookies when the browser is closed for security reasons (temporary cookies).
2. In case of long-term sessions, a re-authentification (at least entering password) is required for critical transactions to execute.
3. As soon as a session expires, session IDs and cookies have to be invalidated at the server- and the client-side.
4. The regular user has to have the option to log out and hence terminate a session at any time.
5. It has a positive impact on security if open sessions of users are displayed to them. Additionally, a function which enables users to terminate these other open sessions is very valuable.
   → In certain application scenarios it might be meaningful to allow only one session per account. This implicates a log out at every new login.
6. Linking client IP addresses and session IDs might be an additional security measure but is not mandatory. In some contexts this might even cause problems - for instance if mobile devices are used or scheduled IP address changes take place.

2) Technical Requirements

Session IDs have to meet the following requirements:

1. The session ID must have a minimum length of 120 bit
2. Session IDs should be stored in cookies
3. Session IDs have to be newly created for each login

When cookies are used to store session IDs, the following requirements apply:

1. The cookie flag "secure" must be set
   → Guarantees solely encrypted transmission
2. The cookie flag "httponly" must be set
   → Guarantees no access through JavaScript (e.g., in case of possible XSS vulnerabilities)
3. The cookie flag "path" must be set as restrictive as possible
   → In case multiple applications are on the same host but in different subdirectories
4. The cookie should be restricted to a single domain (header "Set-Cookie")
   → In case multiple applications are operated within subdomains

Keywords

Session-Hijacking, Session-Security, Cookie-Security, Secure Programming, Web Applications, Web Application Security, OWASP, Software Development, IT Security, Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram