Patent Application
20080222299
The present invention relates to the field of Internet security, secure browsing, and secure eCommerce. More particularly, the invention relates to a method for preventing the theft of the session token from the user's browser, which is used to identify the user to a web server.
A computer executing a browser, referred to hereinafter as a Web Client or client, is essentially a hyper text reader communicating with a Web Server via a specific data transfer protocol such as a Hyper Text Transfer Protocol (HTTP). Any hyper text file on the web is uniquely identified by its Universal Resource Locator (URL). Many of the hyper text files are currently structured using the Hyper Text Mark-up Language (HTML) which may also be used for calling hyper text data objects. The hyper text data object may be in the form of any information medium including a text, an image, a voice, a moving picture or an executable computer program. When a client requests a hyper text file, using the file's URL, the file is displayed on the client's browser, where the display is commonly known as a web page. The client can return data to the server and call a Common Gateway Interface (CGI) program on the server computer to perform a specific task.
Since HTTP is stateless and since Web servers are accessible by many users, where each user may interact with the Web server in many ways, application designers had to develop a way to track the states of the connecting users. Instead of requesting each user to authenticate upon each click in a Web application, a session token is created on the client's browser, where the session token is used to identify the user. Usually the session token is kept “alive” in the browser as long as the user is logged on to the Web server. Typically, the session token is deleted when the user logs-out from the Web Server or after a predefined period of inactivity. Session tokens are commonly stored in cookies, URLs and hidden fields of Web pages.
As explained the session token is used by the user's browser as an identification string for transmitting to the server. One of the problems concerning Internet security today involves session token thieving which is the act of copying a user session token after the user successfully obtained an authentication session token. Since after the log-in, the web site's server identifies the user solely by his session token, the act of thieving/copying it allows the attacker to browse the Web site with the same privileges of the user, for the duration of the user's session, i.e. until the user actively logs out, or is logged out by the system, due to inactivity.
One of the ways to maliciously copy a session token is “Cross Site Scripting”. This attack exploits a vulnerability of the targeted web site, which allows the attacker to craft a malicious link (in the target web site) and entice the user to click it. Once the user clicks this link, the attacker's Javascript/VBscript code runs at the user's browser in the context of the web site. This malicious code can copy the session token, if it is a cookie or part of a URL, possibly in a different window of the same site and browser).
Another way to maliciously copy a session token is by implementing in the client a “Malicious browser plug-in”. The malicious browser plug-in (e.g. BHO technology in Microsoft Internet Explorer) waits for the user to log in, and then forwards the session token to the attacker's server, where it is collected by the attacker and used to browse the web site with the same privileges as the logged in user.
Today, in general, most attempts to prevent Cross Site Scripting are carried out at the server side, e.g. by sanitizing input and encoding output. However, no silver bullet has so far emerged, and Cross Site Scripting attacks are still prevalent among all attacks reported. Some attempts were made to suggest browser measures to confine and contain the effect of cross site scripting (e.g. “Content Restrictions” and “Script Keys” by Gervase Markham, http://www.gerv.net/security/content-restrictions/ and http://www.gerv.net/security/script-keys/, respectively), but these methods remain at this time experimental and have never made it into the core of any major browser.
As to the virus/spyware/Trojan/malware problem, one approach applied by the Anti-virus and anti-spyware vendors, for combating client side threats (such as malicious browser plug-ins), is detection through signatures, meaning that any virus/spyware/Trojan/malware detected by the vendors is identified and marked by a unique signature for detection. Nevertheless, this reactive approach is unlikely to detect a threat until it was (1) noticed several times by the vendors, (2) analyzed in the vendors' lab and a signature identifying the threat is developed, and (3) the signature is distributed to the clients. This process can take many hours, sometimes days, thereby opening a window large enough for the threat to operate. Although, heuristics and generalization techniques (“behavioral analysis”) exist, they are far from being effective, as the attacker can study them at his convenience and come up with ways to avoid detection.
It is an object of the present invention to provide a method for preventing session token theft.
It is another object of the present invention to provide a method for preventing an unauthorized user from copying a user's session token and falsely identifying as the user to a secure web site.
It is still another object of the present invention to provide a method for preventing session token theft applied by Cross Site Scripting or Malicious browser plug-ins.
Other objects and advantages of the invention will become apparent as the description proceeds.
The present invention relates to a method for preventing the theft of a session token comprising the steps of: (a) detecting a submission of a first request from the client's browser to a protected site; (b) redirecting said first request to the traffic processor for monitoring said first request; (c) forwarding said first request from said traffic processor to said protected site; (d) receiving the response containing the session token from said protected site by said traffic processor; (e) storing said session token in the session table; (f) providing a token index for indexing said session token stored in said session table; (g) modifying the content of said response by changing said session token to said token index; and (h) forwarding the modified response from said traffic processor to said browser.
Preferably, the method further comprises the steps of: (i) attaching by the browser the token index to a second request intended for the protected site; (j) redirecting said second request to the traffic processor by the redirector; (k) modifying said second request by replacing said token index of said second response with the corresponding session token from the session table; and (l) forwarding the modified second request to said protected site;
In one of the embodiments, prior to forwarding the first request, modifying said first request by deleting the session token.
In one of the embodiments, the session table stores more than one session tokens.
Preferably, the forwarding of the request(s) by the traffic processor and the receiving of response(s) from the protected site is done using a secure path.
In one of the embodiments, the first request from the client's browser is the login request.
In the drawings:
In one of the embodiments the user may connect to a number of protected sites in which the method of the invention is applied to each of the sites individually. As described, the session table may store a number of session tokens where each session token of each protected site is indexed by its corresponding index token.
In one of the embodiments the protected web page is part of a broader unprotected web site where the user receives a session token from the unprotected web site. In this embodiment, as long as the user continues to surf the unprotected web page no need arises to change the session token. However, once the user enters the protected web page and submits a login request to the protected page the redirector redirects the request the TP in the session shredder. In this embodiment the TP removes the session token from the request and forwards the request to the protected web site without the session token. Thus, once the protected web site receives the request without a session token it automatically generates a new session token and attaches it to the returning response, effectively allowing the TP to store the new session token, retrieved from the received response, without revealing it to the browser.
While some embodiments of the invention have been described by way of illustration, it will be apparent that the invention can be carried into practice with many modifications, variations and adaptations, and with the use of numerous equivalents or alternative solutions that are within the scope of persons skilled in the art, without departing from the spirit of the invention or exceeding the scope of the claims.
