Duncans Security Blog An enthusiasts scrawlings

Session riding

I decided to make this post about web application session riding, known more formally as cross site request forgery, following a presentation about javascript malware done at one of the ISG Durban meetings. There are many ways in which a web application can be designed insecure, and much more ways in which to exploit them.

Web application security has a lot of followers, and their respective communities. One such community is OWASP. OWASP is an open source application security project, and their website is perhaps the most beneficial to anyone looking for a source of information about web security.

Vulnerabilities like XSS or SQL injection are widely used by attackers and security professionals alike, and are the most popular methods of attack. Session riding however, although not as popular, is used just as frequently.

Why is it such a threat?

Web applications do not determine whether a logged in users action is authorised or not, instead it trusts the web users instructions and considers requests as legitimate. A valid session is all that is required by the web application to confirm the validity of an action.

So how does it work?

The web uses the HTTP protocol to deliver information to the user. Every HTTP request made to the web server from the same source is taken as unrelated to any previous or future requests. Neglecting keepalive connections, this is the way a browser interacts with the web server. It is required in some circumstances that the web server remembers the previous requests, for example, when shopping online. This activity needs to be kept track of, and kept seperate to the activities of other users. As a result, cookies were brought in by developers to do just that.

Cookies are bits of information sent by the application on the server, to the user via HTTP response headers. The browsers are designed to remember these cookies. These cookies are then sent to the web pages that have the same application.

Sessions of different users are maintained by random and unique cookie strings, known as session tokens(or session IDs). The randomness and unpredictability of the session token guarantees that the server side application knows who it is communicating with.

The trouble comes in, when a web application only evaluates the origin and validity of actions solely based on a valid session token. A clever attacker only needs a pre-made URL doing the same action as the target web application, and then produce it to the user in a recognisable form, and hope that the user is logged into the legitimate web application at the time. This URL could be sent to the user in a number of ways, including via email. The valid session token would then be obtained by the attacker, and they could get access to the web application.

Such an attack could even disable a network. Say for instance on a home ADSL router. All these devices utilise the HTTP protocol to access the device control panel. Hijacking the session token would allow the attacker access to the network infrastructure, and could lead to network failure if the attacker changes settings(or perhaps they could even change all the passwords).

As more and more devices are using such interfaces, more and more session riding becomes possible. The sky is the limit, as they say. What the attacker really needs to know, is a clever way to deliver the prepared html or javascript to their targets browser (email is but one method). Even standard html tags can be used. For example, in an <img> tag one could display an image, and link it through to the desired URL. Or the URL could be opened in an <iframe> tag. Even <script> tags may be used.  Links such as these can easily be displayed in web applications such as facebook, where every visitor could potentially click on it.

But it doesnt stop there

To make things worse, when session riding, the attacks are always performed from the victims IP address. Thus, according to the web server logs, everything seems to have been done by the victim.

Enough with the doom and gloom

There are, however, some limitation with session riding. If the web application checks the referrer header, the attack will fail, because the origin of the request is usually not the same as the target. However, very few web applications perform this check, and could still be unreliable if a proxy, web filtering software or other such "man in the middle" is being used.

So what measures can be taken to prevent such an attack?

The most common advice to web application developers would be adding a random challenge string to each request. This random string is tied with the user session, and is different for every new login, which prevents the attacker from fetching a valid session token. It is also good practice to provide a lease on the lifetime of a session, such that it expires after a defined period of time.

These measures, however, require the developers to do additional work to the application. In the event that the application is already complete; the redesign costs are not favourable(and would use up too many human resources), and thus the applications remain vulnerable.

On the client side, a user should be very careful as to what links they open, especially if the link has been provided in an email. Browser plugins such as noscript for firefox will also go a long way toward detecting such attacks, especially where javascript malware is concerned.