Authentication and Session Handling

Many web applications use some form of session management in order to create an environment that suits the user. The information linked with the session ID is an attractive target for attackers. The following offers information on attack techniques like session prediction, session interception, session fixation or brute force attacks and how to ward them off. The topics of authentication and authorization play a leading role here.

The HTTP protocol is stateless, which means that the individual queries to the web server, even the embedded images on a website, are requested by means of independent queries on the web server. In the beginnings of the web it was essentially made up of static HTML pages with embedded images. For this scenario a stateless use is of great advantage. The web servers were built simply, queries could be distributed independently across several web servers (load balancing) as well as cached on proxy servers. However, the web has further developed, and today the implementation of sessions is essential for all modern web applications.

A session is a sequence of associated HTTP requests of the user of a web application. A status is managed within a session, e.g. the contents of the shopping cart in a shop system. What interests us particularly from a security point of view is linking sessions with authentication and authorization. If an attacker manages to effect an HTTP request and, in doing so, is recognized incorrectly as a different user and can therefore trigger actions, then we’ve a serious problem on our hands.

On the web there are different variants of combinations of authentication and session; however, for most web applications a standard procedure has now been developed. The web server generates a unique session ID and generally sends this as a cookie to the browser. The browser will then return this cookie in each following request. This way, associated queries of the same user can be recognized. In doing so, the status of the session is stored on the web server and can be queried via the session ID.

The authentication of a user is carried out by entering the username and password on the website. If this data belongs to a known user, then the server assigns the known session ID to the username as a successfully authenticated user. In all the following requests with the same session ID, on the server side it’s then assumed that the query has been triggered by the known user. This however means that the status of the session and the integrity of the session ID is given considerable significance. The following considers the most frequent attacks on the integrity of the session.

Time and time again there are systems that save the status of a session with the client and not on the server. E.g. the content of the shopping cart when shopping is sent to the client by means of a URL or in a cookie.

This approach does offer advantages, e.g. easier implementation of load-balancing on the server site. Unfortunately, we increasingly see errors in the implementation. A virtually classic example, and, unfortunately, one that we still see today, is the online shop that saves the contents of the shopping basket and the prices of the products on the client site. If an attacker then manipulates the prices, the server hasn’t built in a plausibility test and the order is processed almost entirely automatically, then the attacker can buy the goods at the prices he has manipulated. What can you do to fight such an attack?

In an ideal situation, a web application should always save its state on the server side and transfer only the session ID to the client. This then excludes a direct manipulation of the status of the session. The following scenarios assume that only the session ID is saved on the client and that the integrity of this session ID is being attacked by the attacker.

The simplest attack is to guess a valid session ID of another user. There are still web applications that simply assign a consecutive number as the session ID. Some other self-built procedures aren’t always as secure as programmers without cryptographic training would assume. A session ID must always be generated by the server in such a way that an attacker can’t guess this. Ideally, you use a cryptographically secure pseudo random number generator. The random number function made available by most programming languages isn’t usually suitable, it’s statistically evenly distributed, but generally isn’t cryptographically secure.

As a developer of web applications without cryptographic training you should therefore ensure that you use existing frameworks. There you can at least hope that the developers of the application framework have taken care of the problem and have correctly implemented the session ID – even if past experience has proven this trust to be increasingly incorrect. vWAF solves this problem by replacing the (possibly unsecure) session ID of the web application with an independent secure session ID (see Secure Session Wizard).

If an attacker can’t guess the session ID, he could establish it in several other ways. The simplest way is to “sniff” the network traffic. This however only functions if the attacker is located in the same network as the legitimate user or the web server. The former is generally the case in the company networks or also when using WLANs, the latter can crop up in hosting environments. More and more companies rent their web servers from a web hoster. An attacker can attempt to rent a web server with the same hoster. Depending on the web hoster, it’s then possible to read the network traffic of other servers. How can you counteract such a case?

If the security of the session has any economic significance to the web application operator, then the use of SSL is compellingly necessary; this way, the session ID is no longer transmitted unencryptedly and a (passive) reading of the network traffic is no longer an issue. Unfortunately there are other ways of obtaining the session ID. If the web application is susceptible to cross site scripting, for example, then the session ID can be indirectly read via this method (refer also to Cross Site Scripting).

If the session is being transmitted not in a cookie but in the URL, then the attacker can attempt to establish the URL from the browser history, from the log files of proxy servers or the web server, or via the HTTP referer header.

Via the HTTP referer, upon each query on the web server, the browser of the victim sends the URL of the page where the user last visited. Attacks via the HTTP referer are a particular problem with web mail and web forums. You can have a certain amount of protection against session hijacking by connecting the IP address of the querying web client with the session ID and denying queries with the same session ID but a different querying IP address. But this only partially solves the problem. On the one hand, with large providers several users (and attackers) can use the same proxy server and therefore come from the same IP address. On the other hand, a user can also use a proxy server procedure, then the queries of the user will come alternatively from several IP addresses.

The simplest way to discover a session ID is to force a known session ID onto the victim. In doing so, at some point in the run-up, the attacker sets the session ID in the victim’s browser to a value known to the attacker. Then the attacker waits for the victim to use the website and then this session ID is linked to the login information of the server.

How can something like this happen? If the web application transmits the session ID per URL and not per cookie, the attacker could convince the user to click a link with a known session ID and then use the web application.

Even if a cookie is used as standard, some web frameworks also accept the session ID in the URL. Even if only cookies are used to transmit session IDs, the HTTP protocol itself offers in restricted scope the possibility of setting cookies directly for other websites. This is always the case if the web applications are running on the same domain or the last two components of the host name comply with both websites.

The website with the URL http://www.attacker.com/ can’t set cookies for the domain http:// www.victim.com/, but it's very probable for the website http:// www.attacker.exampledomain.com/ to set a cookie for the website http:// www.victim.exampledomain.com/, as the last two components of the domain name tally.

But even if the domains are separated from the attacker and victim, there’s the possibility of using other weak points of the web application, like cross site scripting, in order to set a specific cookie. As a website operator and application developer, what can you do about this?

The web application must ignore an unknown session ID and generate a new one in its place. Ideally, after the successful login of a user, a new session ID should be generated and the old one no longer used.

If the attacker can’t ascertain the session ID, he can still cause damage. Let us consider the following scenario. A user has logged in to his e-banking system, carried out some transactions and then doesn’t explicitly log off. He then accesses another website that the attacker has under control. The cookie from the e-banking application and hence the session ID is still saved in the browser of the user. If he then accesses his e-banking site, he is still considered as logged in and can trigger actions. So how can the attacker use this? The attacker can lure the clueless user to his website and there refer back to the bank site by means of a link.

If the user clicks on this link, a query is again set on the bank’s server, this then detects a legitimate and logged in user and carries out the action specified in the query – for example, a transfer to the attacker’s account. The worst thing about this attack is that it’s easier than it appears. It suffices merely to force a manipulated link on the attacked user. This can take place via email or links in web forums. What can prevent this attack?

Users must ensure that they always explicitly log out and hence end the validity of the session. It also helps if you don’t use other web applications while you’re using critical applications (e-banking, eBay, etc.). The website operators or the application developers can also act effectively against session riding. On the one hand, after a longer period of inactivity, the session could be automatically ended and the user (the next time he logs in) urged in future to explicitly log out. On the other hand, the application developers could ensure on the technical front that critical actions are always carried out by POST requests and, in doing so, that the HTTP referrer is checked. A session riding attack can be recognized here as the browser of the legitimate user sends the URL of the outside website as an HTTP referrer.