A Client-side Solution Against Session Hijacking Through XSS Attacks

Web applications are becoming the dominant way to provide access to on-line services. At the same time, web application vulnerabilities are being discovered and disclosed at an alarming rate. Web applications often make use of JavaScript code that is embedded into web pages to support dynamic client-side behavior. To protect the user’s environment from malicious JavaScript code, an input sanitization mechanism is used that limits a program to access only resources associated with its origin site. Unfortunately, these security mechanisms fail if a user can be lured into downloading malicious JavaScript code from intermediate, trusted site. In this case, the malicious script is granted full access to all resources (e.g., authentication tokens and cookies with session identifiers) that belong to the trusted site. Such attacks are called cross-site scripting (XSS) attacks.Cross-site scripting (XSS) attacks belong to a broader range of attacks, collectively known as code injection attacks. In code injection attacks, the attacker inputs data that is later on perceived as code and executed by the running application. In XSS attacks, the attacker convinces the victim’s browser to execute JavaScript code on his behalf thus giving him access to sensitive information stored in the browser. Malicious JavaScript running in the victim’s browser can access the contents of the cookie for the running domain. Since session identifiers are most commonly propagated through cookies, the injected JavaScript can read them and transfer them to an attacker-controlled server which will record them. The attacker can then reply these sessions to the vulnerable website effectively authenticating himself as the victim. Session hijacking is by the far the most prevalent type of XSS attack since every critical-mission web application that uses session identifiers is potentially vulnerable to it.The workhorse protocol of the World Wide Web, the HyperText Transfer Protocol (HTTP) and its secure counterpart (HTTPS) are by design stateless. That means that a Web application cannot track a client between multiple requests unless it adds a separate tracking mechanism on top of the HTTP(S) protocol. The most commonly used tracking mechanism are session identifiers. A session identifier (SID) is a unique string of random data (typically consisting of numbers and characters) that is generated by a Web application and propagated to the client, usually through the means of a cookie. After the propagation of the session, every request initiated by the client will contain, among others, the session identifier that the application entrusted him with. Using session identifiers, the Web application is able to identify individual users, distinguish simultaneously submitted requests and track the users in time. Session identifiers are a prime attack target since a successful capture-and-replay of such an identifier by an attacker provides him with instant authentication to the vulnerable Web application. Depending on the access privileges of the user whose id was stolen, an attacker can login as a normal or as a privileged user on the website in question and access all sorts of private data ranging from emails and passwords to home addresses and even credit card numbers. The most common way of stealing session identifiers is through Cross-site Scripting attacks.Currently there is only one mechanism meant to protect users from session hijacking in presence of XSS vulnerability. HTTP-Only is a web browser feature introduced by Microsoft to safeguard cookies in Internet Explorer6and later versions. HTTP-Only is a flag that is sent by the web application to the client, along with a cookie that contains sensitive information, e.g., a session identifier. It instructs the user’s browser to keep the values of that cookie away from any scripting languages running in the browser. Thus if a cookie is denoted as HTTP-Only and JavaScript tries to access it, the result will be an empty string.In our research we proposed a system called Sessionlmmunizer. Sessionlmmunizer is a proxy outside of the browser that inspects all outgoing requests and incoming responses. Using a variety of methods, it detects session identifiers in the incoming HTTP headers, strips them out and stores their values in its own database. In every outgoing request, Sessionlmmunizer checks the domain of the request and adds back the values that were previously stripped. In case of a session hijacking attack, the browser will still execute the session hijacking code, but the session information will not be available since the browser never received it. Our system is transparent to both the web client and web server functionalities, it operates solely on the client-side and it doesn’t rely on the web server or trusted third parties.