Abstract:
A method for tracking and identifying an identity of a user accessing a web application. An application normal behavior profile (NBP), wherein said NBP includes a plurality of authentication identifiers of the web application is generated. It is determined using the NBP whether an authentication request submitted by the user was successful. A first actionable data on a successful authentication request is saved. A second actionable data on an unsuccessful authentication request is saved.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims priority from US provisional application No. 60/739,955 filed on Nov. 28, 2005, the contents of which are incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     This disclosure relates generally to application level security systems, and more particularly to techniques for tracking hackers by such systems. 
     BACKGROUND OF THE TECHNOLOGY 
     Currently, a growing number of web applications require a client to carry out an authentication process prior to being granted access, and prior to being assigned with an application session. In the authentication process a client declares its identity to the system (“UserId”) together with a proof of that identity (usually password based). The same identity must be presented for each application session involving a specific client. 
     In the related art there are at least two techniques used to perform authentication in web applications. The first technique is based on the authentication protocol semantics described in the Hypertext Transfer Protocol Request for Comments (HTTP RFC). In this technique the protected application responds with a 401 error code whenever authentication is required, the client then sends a request with the proper values in the “Authorization” header field and is authenticated by the application. If the application fails to authenticate the client it responds again with a 401 error (or a 403 error). 
     The second technique, also known as “form authentication”, is more commonly used and relies on HTML forms in which the client types the UserID and password. The form is submitted to a specific module in the web application (using a HTTP request). The module evaluates the client&#39;s credentials and responds accordingly. In both techniques, once an authentication is successful, the client is not required to resend the credentials throughout the rest of the application session. Specifically, the server internally associates the session identifier sent to the user (in the form of a cookie) with the identification token representing that user. 
     Web application security systems are required to be able to correlate multiple requests that constitute a single attack. Traditional techniques, taken from network security domain, rely on the source IP address of the request. This type of correlation is inadequate in the domain of web applications because of the prevailing use of network address translation (NAT), on one hand, and the ability of an attacker to switch IP addresses quickly during an attack, on the other hand. Attacker can switch IP addresses either by using proxies, dial-up connection, or any other techniques. More advanced protection techniques rely on the notion of application session as maintained by the web server using some mechanism for keeping session for HTTP requests (e.g. cookies). While these are more adequate techniques, they fail to provide a robust solution since session creation is controlled by the client rather than the server. For example, a client may refuse to send an existing cookie and by that invoke the generation of a new session with a new cookie by the server. Therefore, it would be advantageous to provide a more robust correlation mechanism for web application protection. 
     SUMMARY 
     To realize some of the advantages noted above, there is provided a method for tracking and identifying an identity of a user accessing a web application. An application normal behavior profile (NBP), wherein said NBP includes a plurality of authentication identifiers of the web application is generated. It is determined using the NBP whether an authentication request submitted by the user was successful. A first actionable data on a successful authentication request is saved. A second actionable data on an unsuccessful authentication request is saved. 
     In another specific enhancement a corresponding user identification is attached to each subsequent authentication request submitted by the user. 
     In another specific enhancement the plurality of authentication identifiers comprise at least: an authentication form, a login pattern of the successful authentication request, a login pattern of the unsuccessful authentication request. 
     More specifically, the authentication form is a hypertext markup language (HTML) form. 
     More specifically, the login pattern includes at least one login indication and a value of said at least one login indication. 
     Even more specifically, the login indication comprises at least one of: a response code, existence of redirect directives, a target URL of redirect directives, and existence of the authentication form. 
     More specifically, the NBP is generated to include the plurality of authentication identifiers by a process including identifying at least one authentication form in a reply to the submitted authentication request and identifying at least one login pattern in the reply. 
     More specifically, identifying the authentication forms further includes analyzing said at least one authentication form in the reply. A search is conducted for at least one identifier parameter in the at least one authentication form. A number of occurrences of additional authentication forms that has the at least one identifier parameter during a predefined time interval is counted. The at least one authentication form is added to the NBP if the number of occurrences exceeds a predefined threshold. 
     More specifically, the identifier parameter comprises at least one of: an input field of type password, an input field of type text. 
     More identifying the at least one login pattern further includes marking each combination of login indications found in the reply. A number of observations of each combination during a predefined time interval is counted. A combination of login indications is determined as the login pattern of a successful authentication request if a corresponding number of observations exceeds a predefined threshold. A combination of login indications is determined as the login pattern of an unsuccessful authentication request if a corresponding number of observations is below a predefined threshold. 
     More specifically, determining whether the authentication request was successful further includes extracting values of the login indications from a response associated with the authentication request. It is checked if the extracted values of the login indications exist in the NBP. It is determined that the authentication request was successful if the extracted values exist in the NBP. 
     In another specific enhancement the actionable data on the successful authentication request comprises at least one of: a user identification, a session identification, a user name, an internet protocol address, actions preformed by the user. 
     More specifically, the actionable data on the successful authentication request is utilized to track users across many sessions and days. 
     In another specific enhancement the first actionable data on the unsuccessful authentication request comprises at least one of: a session identification, a user identification, an internet protocol address associated with the user. 
     More specifically, second actionable data on the unsuccessful authentication request is utilized for detecting brute force attacks. 
     Another aspect of the disclosed teachings is a computer program product including a computer readable medium having instructions for enabling a computer to perform the above discussed methods. 
     Still another aspect of the disclosed teachings is security system having user awareness capabilities for tracking and identifying the identity of users accessing a web application, the system comprises a secure server coupled to a secure gateway and operable to generate an application normal behavior profile (NBP) that includes at least a plurality of authentication identifiers of the web application. At least one secure gateway is installed in a line of traffic between a client and a web server and operable to determine using the NBP whether an authentication request from the client was successful. 
     In another specific enhancement the authentication request is submitted by a user. 
     More specifically, the secure gateway is further operable to save first actionable data on a successful authentication request and further operable to save second actionable data on an unsuccessful authentication request and labeling each authentication request with an identity of the actual user. 
     In another specific enhancement, the system is further operable to identify authentication forms in replies to submitted authentication requests and identify login patterns in replies to the submitted authentication requests. 
     More specifically, to determine whether the authentication request was successful, the system is operable to extract values of at least login indications from a response associated with the authentication request, and further operable to check if the extracted values of the login indications exist in the NBP; and further operable to determine that the authentication request was successful if the extracted values exist in the NBP. 
     More specifically, the first actionable data on the successful authentication request comprises at least one of: a user identification, a session identification, a user name, an internet protocol address, actions preformed by the user. 
     More specifically, the first actionable data actionable data on the successful authentication request is utilized to track users across many sessions and days. 
     More specifically, the second actionable data on the unsuccessful authentication request comprises at least one of: a session identification, a user identification, an internet protocol address associated with the user. 
     More specifically, the second actionable data on the unsuccessful authentication request is utilized for detecting brute force attacks. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The above objectives and advantages of the disclosed teachings will become more apparent by describing in detail preferred embodiments thereof with reference to the attached drawings in which: 
         FIG. 1  is a diagram of an application level security system in accordance with an exemplary embodiment of the disclosed teachings. 
         FIG. 2  is a flowchart describing the method for detecting authentication operations and generating actionable data in accordance with an exemplary embodiment of the disclosed teachings. 
         FIG. 3  is a flowchart describing the process for identifying authentication forms in accordance with an exemplary embodiment of the disclosed teachings. 
         FIG. 4  is a flowchart describing the process for identifying successful logins in accordance with an exemplary embodiment of the disclosed teachings. 
     
    
    
     DETAILED DESCRIPTION 
     Techniques for automatically identifying the client identity as embodied by the UserID of each application session are disclosed. Specifically, techniques for identifying the specific module in a web application that validates credentials and for assessing whether a specific authentication request was successful or not are disclosed. Also disclosed is a web application security system having user awareness capabilities. 
     Using the disclosed techniques in a web application security system that is capable of tracking application sessions, each and every client request can be labeled with the identity of the actual user. Thus, robust correlation mechanism based on the actual client that generated the request is achieved. A web application security system can use the user awareness capabilities for a more accurate detection of attacks. It also has a better attack thwarting mechanism. For example, it can block all session of a user rather than a single session. The system provides a better and more meaningful attack reporting. Furthermore, an operator can take actions against an actual user. Better auditing of application access can be provided. For example, an operator can monitor any behavior of specific clients. Furthermore, by using the techniques disclosed, web applications can be protected against specific attacks that are aimed at the authentication process such as brute force guessing. 
       FIG. 1  shows a non-limiting and exemplary diagram of an application level security system  100  that carries out the techniques disclosed. Security system  100  includes a plurality of secure gateways  130  connected to a secure server  110 . Secure gateways  130  may be connected to server  110  through out-of-band network (not shown) for transferring traffic over a dedicated and secure network that is completely separated from the production traffic. A secure gateway  130  is placed on each network segment that includes servers  160  (e.g., Web or database servers) to be protected. Access to one or more Web applications that reside on one of servers  160  is permitted only after a user successfully logs-on to server  160 . For this purpose, server  160  provides an authentication service as described in greater detail herein. 
     Security system  100  is a non-intrusive system, and thus each of secure gateways  130  is configured to operate in the line of traffic, i.e., traffic passing directly through the secure gateways  130  to protected server  160 . Specifically, each of the secure gateways  130  gathers, and reconstructs application requests sent to protected server  160 . A secure gateway  130  further matches the reconstructed request against a predetermined application normal behavior profile (NBP). Application requests are sent by client  190 . 
     A NBP is generated by the secure server  110  and includes a plurality of application attributes such as uniform resource locators (URLs), cookies, users&#39; information, IP addresses, query statements, and many others. These attributes determine the normal behavior of the protected application. If one or more of the application requests do not match the NBP an alert providing an indication of a potential attack is produced. In accordance with the exemplary implementation of the disclosed teachings, a NBP includes at least a list of authentication (or login) forms, i.e., web pages that encapsulate an authentication service. For each such form, a NBP further includes a list of login indications and their values. Secure gateways  130  monitor incoming requests in order to detect candidate authentication forms. These forms are forwarded to secure server  110  which determines if they should be included in the NBP. If so, secure server  110  updates the NBP of the protected application. Additionally, secure gateways  130  monitor responses that result from login requests. In these responses, each secure gateway  130  looks for values of the login indications and passes them to secure server  110 , which in turn determines if these values indicate a successful login. If so, the NBP is updated and uploaded to secure gateways  130 . 
       FIG. 2  shows a non-limiting and exemplary flowchart  200  describing the technique for detecting authentication operations and generating actionable data from such operations, in accordance with certain aspects of the disclosed teachings. At S 210 , a process for identifying authentication forms in the protected web application is applied. 
       FIG. 3  shows an example of the execution of S 210  in greater detail. At S 310 , the server replies are monitored and inspected for HTML forms. An HTML form is identified by the FORM tag and includes one or more INPUT tags. The FORM tag contains an ACTION attribute, i.e., a URL that specifies the target page, which handles the input from a user. This page may be the embodiment of the authentication service. At S 320 , in each of the forms discovered at S 310 , the process looks for the identifier parameters. As a non-limiting example such parameter may be: a single input field of type “password”. This identifier parameter can be further corroborated with heuristics regarding the “NAME” attribute of this field such as “passwd”, “pass”, “RegPass”, “pass_*”, “pswd”, “UserPassword”, “user_password”, “login_password”, “pc”, “user_pin”, “pin”. As another example, an identifier parameter may be two input fields of type “text”. This indication can be further corroborated with heuristics regarding the “NAME” attribute of the fields such as “login”, “id”, “user”, “user_id”, “UserId”, “user_name”, “UserName”, “LoginName”, “email”, “login_email”, “nick_*”. 
     At S 330 , it is checked if a form includes the identifier parameters tested for in S 320 , and if so it is considered a candidate and execution continues with S 340 ; otherwise, execution terminates. At S 340 , the value of the “ACTION” attribute together with the “NAME” attribute of the first text field are sent to the server  110 . At S 350 , secure server  110  counts the number of occurrences of each candidate form during a predefined time interval (e.g., 24 hours). At S 360 , the number of occurrences is compared to a predefined threshold. If the count exceeds the threshold, the candidate form is actually an authentication form and added, at S 370 , to the NBP of the protected application; otherwise, execution terminates. 
     Referring back to  FIG. 2  where at S 220 , a process for learning the pattern of successful and failed login operations is applied. Secure server  110  dose not hold the authentication data of users. Therefore, when a user authenticates, secure server  110  cannot determine whether it is a successful or failed login by using the UserID and password entered by the user, and thus such a decision is made based on the response sent by server  160 . 
       FIG. 4  shows an example of the execution of S 220  in greater detail. At S 410 , a response that a server  160  sends back to client  190  is received. Such a response is a reply to a login request. At S 420 , in each such response the process looks for one or more login indications. These login indications include at least a response code, existence of redirect directives, a target URL of redirect directives, and the existence of an authentication form (as described above) in the HTML part of the response. At S 425 , the indications are sent to secure server  110 . At S 430 , each combination of indications is given a unique marking and a counter is maintained for the number of observations of each combination. At S 440  it is checked whether the number of observations exceeds a given threshold (e.g. 100 login attempts). If so, execution continues at S 450 , otherwise execution ends. At S 450 , secure server  110  checks for the combination of indications (or group of such combinations) whose proportion within the total number of observation exceeds a given threshold (e.g. 80%). This combination of indications is then declared to indicate a successful authentication and is added, at S 460 , to the NBP. It should be noted that the technique described in  FIG. 4  teaches how to detect responses that represent successful logins. However, a person skilled in the art can easily adapt this process to identify responses representing failed logins. 
     Referring back to  FIG. 2  where at step S 230  the updated NBP, that includes the learnt authentication forms and successful login indications, is uploaded to secure gateways  130 , and subsequently, system  100  switches to a protection mode that begins with step S 240 . 
     At S 240 , a secure gateway  130  receives a login request and waits for the respective response from a server  160  that handles this request. At S 250 , the secure gateway  130  extracts login indications from the response and, at S 260 , compares them to the values saved in the NBP. If a match exists, then it is considered as a successful login and execution continues with S 270 ; otherwise, the login has failed and execution continues at S 280 . At S 270 , parameters such as the UserID, SessionID, and the actions that the user preformed, are saved in a success list. This list may further include an IP address, a user name, and other related information. The actionable data in the success list can be used to track a user across many sessions and days and take actions against specific users. For example, a security officer can provide the authorities with incriminating data, stored in the success list, of users who committed unauthorized actions in the protected application. At S 280 , the session ID, UserID and preferably an IP address associated with a user that failed to login are saved in a failure list. At S 290 , the user identity (i.e., UserID and username) is attached to subsequent requests that belong to the same session. In an exemplary embodiment, static based authorization rules may be applied on a request. For example, an authorization rule may define that a specific URL can be accessed only by designated users. 
     In another exemplary embodiment, the information kept in the failure list can be used for the detection of brute force attacks. Such attacks are committed by trying large number of password combinations until a combination is found that enables the penetration into the application. In order to detect such attacks, system  100 , using data in the failure list, counts the number of failed logins from the same UserID over a predetermined short period of time. If and when the count exceeds a predefined threshold an alert is generated. 
     Other modifications and variations to the invention will be apparent to those skilled in the art from the foregoing disclosure and teachings. Thus, while only certain embodiments of the invention have been specifically described herein, it will be apparent that numerous modifications may be made thereto without departing from the spirit and scope of the invention.