Patent Publication Number: US-2013246517-A1

Title: Method and system for containment of networked application client software by explicit human input

Description:
BACKGROUND OF INVENTION 
     1. Field of Invention 
     The present invention relates generally to computer systems. More particularly, the present invention relates to explicit human input or confirmation for containing networked application client software. 
     2. Related Art 
     In a typical computer system, any software running on the system has full network access to, and the service usage of, any networked service or application that is needed directly or indirectly by users of the computer system. Furthermore, networked application client software is herein defined as software that makes use of network-accessible services by using network communication from the client host to the host(s) providing the service(s), and implementing the correct protocol for using such service(s). 
     Today, there exist numerous techniques for automating and simulating a user in order so networked application client software would specify, request, and use the aforementioned network-accessible services. Although such techniques as creating a human-input script or creating client software that utilizes the same application programming interface (API) as the user-interface software do provide many benefits, the same techniques may also be used to allow malicious or erroneous software to make service requests that are not intended by the user. 
     One solution to detect malicious usage of networked application client software is to use human interactive proofs. Conventionally, human interactive proofs have been used to gather human input with high assurance that input came from a human rather than software developed to simulate human input. However, human interactive proofs have thus far neither been used to detect whether application software operating on behalf of a user is functioning without the user&#39;s knowledge or authorization, nor used within an existing application workflow to obtain human confirmation for an application transaction request. 
     A second solution is to implement network firewalls that control the ability of networked application client software to send request to networked application server software. In one example of a firewall technique, a firewall acts as a “proxy” for client/server transmission control protocol (TCP) connections, that is, acts as a TCP connection endpoint for a connection with a client and a second connection for a server. A firewall may set up a dialogue with the user in order to notify the user that some software is attempting to traverse the firewall to the host that the user is using. The dialogue is considered successful if the user provides the information expected in the dialogues (e.g. a mouse click on an “OK” button rather than a mouse click on a “Cancel” or “Close” button). However, such dialogue techniques have not been used to provide any assurance of human participation in the dialogue, that is, the data entered on the user&#39;s side may well be provided via a script or other forms of automation. 
     SUMMARY OF INVENTION 
     Accordingly, the present invention provides a method and system for containing the capabilities of networked application client software so that it can perform specified transactions only given explicit consent or confirmation of a legitimate user. In one embodiment of the present invention, the consent from the user is obtained by means of dialogues with the user who is using the host executing the networked application client software. The dialogues are performed with one of several techniques for gathering human input, wherein the techniques are designed so it is extremely difficult for software to automate the user&#39;s responses to a dialogue, and much more difficult to automate the user&#39;s responses reliably for multiple arbitrary dialogues. 
     The present invention provides a method and system to reduce or eliminate the spread of malicious software via means such as electronic mail or internet messaging that include data attachments. The present invention prevents the spread of such malicious service usage attempts by intercepting a service request, notifying the user of the service request, and subsequently dropping the request if the user denies the request or does not confirm the notification. 
     The present invention may also be used to prevent unauthorized service usage wherein the service request comes from a non-legitimate user masquerading as a legitimate user. Moreover, the system of the present invention may be used to implement service on user demand in order to contain a workstation to a specific set of services where each channel through which the workstation communicates with a host in order to access a service has been explicitly authorized by a human user. Alternatively, the present invention may be used to implement access on demand to contain a server&#39;s usage of other services to only the services that the server needs. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       The accompanying drawings that are incorporated in and form a part of this specification illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention: 
         FIG. 1  is a block diagram comprising: a server host having server application software and a confirmation interceptor; a data network, a workstation host having user/client software, automated client software, and a confirmation agent; and a user, interacting in accordance to a first embodiment of the present invention. 
         FIG. 2  is a block diagram comprising the same components as  FIG. 1  wherein the components interact without the user in accordance to the first embodiment of the present invention. 
         FIG. 3  is a block diagram comprising: a server host having server application software and a confirmation interceptor; a data network, a first workstation host having user/client software, and automated client software; a second workstation host having a confirmation agent; and a user, interacting in accordance to a second embodiment of the present invention. 
         FIG. 4  is a block diagram comprising: a server host having server application software and a confirmation interceptor; a data network, a workstation host having user/client software, and automated client software; a user, and a communication device comprising a confirmation agent, on the same data network as the workstation host, interacting in accordance to a third embodiment of the present invention. 
         FIG. 5  is a block diagram comprising: a server host having server application software and a confirmation interceptor; a data network, a workstation host having user/client software, and automated client software; a user, a communication device comprising a confirmation agent, and a second data network, interacting in accordance to a fourth embodiment of the present invention. 
         FIG. 6  is a flow chart illustrating the steps for containing networked application client software in accordance to one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENT (S) 
     The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. In the following description, specific nomenclature is set forth to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the specific details may not be necessary to practice the present invention. Furthermore, various modifications to the embodiments will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described herein. 
       FIG. 1  illustrates a block diagram  100  in accordance to a first embodiment of the present invention. Block diagram  100  comprises: a server host denoted  1 , a data network denoted  7 , a workstation host denoted  9 , and a user denoted  21 . The server host  1  further comprises server application software denoted  3  and a confirmation interceptor denoted  5 . The workstation host  9  further comprises: user/client software denoted  13 , automated client software denoted  17 , and a confirmation agent denoted  19 . The user/client software  13  and the automated client software  17  each in turn comprise a network programming interface denoted  15 . 
     Furthermore, the server host  1  is herein defined as a computer that is running a service that may be used directly or indirectly by the user  21  via user/client software  13 . The data network  7  is herein defined as an electronic medium used for communication between two or more computers, including communication between the server host  1  and the workstation host  9 . The workstation host is herein defined as a computer used by the user  21  to execute client software and make use of services running on the server host  1 . The server application software  3  is herein defined as software that runs on the server that implements one or more services. The confirmation interceptor  5  is herein defined as software that intercepts service requests and in some cases obtains user confirmation for service requests. The confirmation agent  19  is herein defined as software used to receive information from the confirmation interceptor  5  and implement a dialogue between the system and the user  21 . For example, internet messaging (IM) software may be used as a confirmation agent  19  to provide interaction between the system and the user. The user/client software  13  is herein defined as software comprising user-interface software and client application software. The automated client software  17  is herein defined as software comprising client application logic (i.e. usage and network programming interface). The network programming interface  15  is herein defined as a set of data exchange protocols used to facilitate communication between the server application software  3  and client application software. Moreover, client application software is herein defined as software that runs on workstation host  9  and executes tasks that comprises: implementing an application&#39;s network programming interface, using the network programming interface to formulate service requests, sending the requests to the server host  1 , and receiving responses from the server host  1  via the data network  7 . 
       FIG. 1  illustrates one exemplary embodiment for containment of the capabilities of network application client software. The term containment as used in the description of this invention is herein defined as a mechanism for ensuring that for any designated service or any designated transaction of a designated service, a human user has provided explicit confirmation to process the service or the transaction. 
     A contained system observes several properties including: any software in the contained system can be prevented from using network-accessible services unless the use of such services results from human-originated actions; any software in the contained system can be prevented from using transactions implemented by a specific service unless the use of such transactions result from human-originated actions; and no autonomous software in the contained system can surreptitiously use services and/or transactions. 
     Moreover, the containment mechanism can be applied selectively to services based on the nature of the service and/or the nature of specific threats or possible harmful effects that could results from the service. For example, malicious software could spread via electronic mail or messaging that includes data attachments, therefore, whenever electronic mail with attachments is sent, the human user is asked to confirm the origin of the request. If malicious software attempts to spread to other hosts by sending itself via electronic mail, the user will be contacted to confirm that he/she has sent the message and its associated data attachment, and the malicious attempt would be thwarted when the human user denies the origin of the electronic mail. 
     Containment is accomplished in a system by controlling the ability of any software on a host system to use a communication conduit. A conduit is herein defined as a mechanism that has the ability to create a communication session from the local host system to a host system offering a service, wherein the session uses a communication channel for the service. For example, a common pair of conduits used by many workstation hosts are able to communicate over a conduit to a mail server using TCP and port  110  in order to access a POP3 service for receiving mail; the pair may also communicate over a conduit to a mail server using TCP and port  24  to access a simple mail transfer protocol (SMTP) service for sending mail. 
     An important aspect of conduits in practice is that most hosts have the ability to use a conduit to communicate with most services running on most other hosts. The number of such conduits is large and most of these conduits are rarely used but are available for accidental or intentional abuse with harmful results. 
     A system is considered contained if there is a containment mechanism that controls the usage of all conduits, and enables the conduits that are actually needed. In a contained system, control is applied both to the ability to make use of a conduit (to make requests for transactions implemented by the server), and to the ability to use conduits to make a specific request. 
     Referring now back to  FIG. 1 . As illustrated in  FIG. 1 , the user  21  interacts with the user/client software  13  in order to provide user data input that describes an application transaction that the user wants performed. Once the user/client software  13  receives the data input from the user  21 , the user/client software  13  sends a service request message to the server application software  3  on the server host  1 . 
     The service request message is passed from the workstation host  9  to the confirmation interceptor  5  via the data network  7 . The confirmation interceptor  5  then intercepts the service request message and determines whether the requested transaction necessitates user confirmation. 
     If the requested transaction does require user confirmation to proceed, the confirmation interceptor  5  holds the service request message and sends a confirmation request message to one of several possible devices such as: a confirmation agent on workstation  9 , a confirmation agent on a second workstation associated with the user  21 , a communication device comprising a confirmation agent connected to the data network  7 , or a communication device comprising a confirmation agent connected to a second data network. Although the confirmation interceptor  5  may send a confirmation request message to any of a number of possible devices such as those listed, the confirmation interceptor  5  shown in  FIG. 1  sends the confirmation request message to the confirmation agent  19 . Moreover, confirmation request message comprises information related to the confirmation requested of the user. 
     The confirmation agent  19  then displays a message to the user, wherein the displayed message prompts the user for the response that the confirmation interceptor requires in order to process the service and/or the transaction requested. Moreover, to obtain the required response, the confirmation agent  19  may query the user by one or more dialogues. The confirmation agent  19  then waits for a user response within a predefined time frame. If the confirmation agent  19  obtains a response within the time frame, the confirmation agent  19  sends the response data back to the confirmation interceptor  5  in the form of a confirmation status message. 
     Moreover, when the confirmation interceptor  5  receives the response data, the interceptor determines whether the response data is an acceptable confirmation reply. In one example, the confirmation interceptor receives an acceptable confirmation from the user to proceed with the request transaction and forwards the service request message to the server application software  3 . Alternatively, if the confirmation interceptor  5  determines that one of the following is true: a) the response is not an acceptable confirmation response; or b) there is no response data; the confirmation interceptor  5  then drops the service request message instead of forwarding the message to the server application software  3 . 
       FIG. 2  illustrates an alternative scenario to the embodiment shown in  FIG. 1 , whereas a service request message originates from the user  21  to the user/client software  13  in  FIG. 1 , a service request message originates from automated client software  15  and the service request message is then transmitted to the confirmation agent  19  without the knowledge of the user  21 . In  FIG. 2 , the automated client software  15  provides the confirmation response to the confirmation agent  19  that sends the response data back to the confirmation interceptor  5  in the form of a confirmation status message. The confirmation interceptor  5  then determines that the response is unacceptable, because the required response is designed to not be computable from either the original request message (intercepted by the confirmation interceptor  5 ) or the confirmation agent  19 &#39;s prompt for the confirmation response. Consequently, confirmation interceptor  5  drops the service request message. However, the confirmation interceptor  5  would forward the request to the server application software  3  if the user  21  becomes aware of the service request that originates from the automated client software  15 , confirms the request with an acceptable response to the confirmation agent  19  which forwards the response data to the confirmation interceptor  5 . In the embodiment of the present invention illustrated in  FIG. 1  and  FIG. 2 , automated client software  15  is not prevented from seeing (or intercepting) the prompt for user confirmation, nor from attempting to impersonate the user  21  by responding; however, the nature of the prompt and acceptable responses makes it infeasible for automated client software  15  to compute an acceptable response. 
       FIG. 3  is a block diagram  300  in accordance to a second embodiment of the present invention. Block diagram  300  comprises: a server host denoted  1 , a data network denoted  7 , a first workstation host denoted  9 , a second workstation host denoted  11 , and a user denoted  21 . The server host  1  further comprises server application software denoted  3  and a confirmation interceptor denoted  5 . The first workstation host  9  further comprises: user/client software denoted  13 , and automated client software denoted  17 . The second workstation host  11  further comprises a confirmation agent  23 . The user/client software  13  and the automated client software  17  each in turn comprise a network programming interface denoted  15 . 
     As shown in  FIG. 3 , the server host  1 , the server application software  3 , the confirmation interceptor  5 , the user/client software  13 , the automated client software  17 , the network programming interface  15 , and the user  21  are substantially the same as they are illustrated and described in  FIG. 1 . However, whereas confirmation agent  19  is shown to operate on workstation host  9  in  FIG. 1 , the confirmation agent  23  in  FIG. 3  is shown to operate on a second workstation host  11  that is associated with the same user  21 . As with the embodiment illustrated in  FIG. 1  and  FIG. 2 , the automated client software  17  may also originate a service request that is intercepted by the confirmation interceptor  5 . However, the automated client software  17  shown in  FIG. 3  is unable to see or intercept the confirmation request or user prompt since the confirmation request is directed not to the first workstation host denoted  9  on which the automated client software  17  executes, but instead to a second workstation host denoted  11 . 
       FIG. 4  is a block diagram  400  in accordance to a third embodiment of the present invention. Block diagram  400  comprises: a server host denoted  1 , a data network denoted  7 , a workstation host denoted  9 , a communication device denoted  27  comprising a confirmation agent, and a user denoted  21 . The server host  1  further comprises server application software denoted  3  and a confirmation interceptor denoted  5 . The workstation host  9  further comprises: user/client software denoted  13 , and automated client software denoted  17 . The user/client software  13  and the automated client software  17  each in turn comprise a network programming interface denoted  15 . 
     As shown in  FIG. 4 , the server host  1 , the server application software  3 , the confirmation interceptor  5 , the user/client software  13 , the automated client software  17 , the network programming interface  15 , and the user  21  are substantially the same as they are illustrated and described in  FIG. 1 . However, whereas the confirmation interceptor  5  is shown to send confirmation request messages to the confirmation agent  19  on workstation host  9 , and receive confirmation status messages from the confirmation agent  19  in  FIG. 1 , the confirmation interceptor  5  in  FIG. 4  is shown to send confirmation request messages to an alternative communication device  27  comprising a confirmation agent and receive confirmation status messages from the communication device  27 , wherein the communication device  27  is on the same data network  7  but is not on workstation host  9 . As with the embodiment illustrated in  FIG. 1  and  FIG. 2 , the automated client software  17  may also originate a service request that is intercepted by the confirmation interceptor  5 . However, the automated client software  17  shown in  FIG. 4  is unable to see or intercept the confirmation request or user prompt, because the confirmation request is directed not to the first workstation host denoted  9  on which the automated client software  17  executes, but instead to the communication device  27 . 
       FIG. 5  illustrates a block diagram  500  in accordance to a fourth embodiment of the present invention. Block diagram  500  comprises: a server host denoted  1 , a first data network denoted  7 , a workstation host denoted  9 , a second data network denoted  29 , a communication device denoted  31  comprising a confirmation agent, and a user denoted  21 . The server host  1  further comprises server application software denoted  3  and a confirmation interceptor denoted  5 . The workstation host  9  further comprises: user/client software denoted  13 , and automated client software denoted  17 . The user/client software  13  and the automated client software  17  each in turn comprise a network programming interface denoted  15 . 
     As shown in  FIG. 5 , the server host  1 , the server application software  3 , the confirmation interceptor  5 , the user/client software  13 , the automated client software  17 , the network programming interface  15 , and the user  21  are substantially the same as they are illustrated and described in  FIG. 1 . However, whereas the confirmation interceptor  5  is shown to send confirmation request messages to the confirmation agent  19  implemented on workstation host  9 , and receive confirmation status messages from the confirmation agent  19  in  FIG. 1 , the confirmation interceptor  5  in  FIG. 5  is shown to send confirmation request messages to an alternative communication device  31  via a second data network  29 , and receive confirmation status messages from the communication device  31  via the second data network  29 . As with the embodiment illustrated in  FIG. 1  and  FIG. 2 , the automated client software  17  may also originate a service request that is intercepted by the confirmation interceptor  5 . However, the automated client software  17  shown in  FIG. 5  is unable to see or intercept the confirmation request or user prompt, because the confirmation request is directed not to the first workstation host denoted  9  on which the automated client software  17  executes, but instead to the confirmation agent  31 . 
       FIGS. 1 to 5  illustrate confirmation of explicit human input in accordance to several embodiments of the present invention. Moreover, the transactions between the elements shown in  FIGS. 1 to 5  may be summarized into a log displayed to a human user such as a system administrator (not shown). In one exemplary embodiment, the log summary includes: the source and destination host addresses of the communication channel intercepted; protocol used to intercept communication (e.g. TCP, etc) including source and destination port numbers; host information for the confirmation interceptor; date and time of interception of transaction request message wherein the transaction requires confirmation; full or partial information related to the transaction request message; target device, communication channel, and protocols used by the confirmation interceptor to attempt contact with the confirmation agent (e.g. target host, protocol, port usage, type of network, network-specific target identifier such as a phone number, etc.); whether communication succeeded, failed, or timed out; and a log of communication with confirmation agent including: any local context provided by the confirmation agent to the confirmation interceptor, type of confirmation request sent; full log of confirmation requests sent to the confirmation agent; full log of response information gathered from human-machine interaction; whether response information was correct confirmation response; date and time of forwarded requests if response information was correct; actions taken if response information was incorrect. 
       FIG. 6  is a flow chart illustrating the steps for containing networked application client software in accordance to one embodiment of the present invention. In step  41 , a service request message is sent to server application software. As illustrated by the embodiments shown in  FIG. 1-FIG .  5 , the service request message may originate from a user or may originate from automated client software as shown in  FIG. 5 . Moreover, a system in accordance with the present invention may operate in different modes wherein in a first exemplary embodiment, the system operates without user confirmation for service requests. 
     In this first exemplary embodiment, the service request is logged and the service request message is forwarded onto the server application software in step  57 . 
     In an alternative embodiment, the system operates with user confirmation for service requests. In this alternative embodiment, the service request message is checked to determine whether the message requires a user confirmation in step  45 . If the service request message does not require any user confirmation, the service request is logged and the service request message is forwarded onto the server application software in step  57 . 
     In step  45 , if it is determined that the service request message does require user confirmation, the message is checked to determine if a specific confirmation agent has been defined as the means to process the service request in step  47 . 
     In step  49 , if a confirmation agent has been designated to process the service request, a confirmation request message is then sent to the designated confirmation agent from a confirmation interceptor. 
     Alternatively, in step  51 , if a confirmation agent is not designated to process the service request, a confirmation request message is sent to a default confirmation agent from a confirmation interceptor. 
     Having received the confirmation request message, the designated or default confirmation agent engages in a dialogue with the user in order to obtain user confirmation, and the designated or default confirmation agent subsequently sends a confirmation status message to the confirmation interceptor, wherein the confirmation status message comprises the content of the user&#39;s dialogue information. Moreover, the confirmation status message may comprise: a) an acceptable user response wherein the response is one that is required for the service request, b) an unacceptable user response, or c) no user response wherein the user does not respond within a user or system defined time frame. Case (b) may comprise a well-formed response wherein the user denies the service request, or it may comprise a malformed response such as the result of autonomous client software attempting to impersonate a user. 
     Furthermore, one or more techniques maybe employed to carry out the dialogue with the user in order to ensure that the response comes from a legitimate user rather than other means such as automation. In one embodiment, a natural language puzzle maybe used wherein human reasoning is necessary to determine the input solicited. For example, one dialogue employing natural language puzzles may solicit an input by asking for the name of a color in the rainbow, wherein the color is adjacent to the color yellow in the rainbow and is not a citrus fruit. The nature of such questions enables a higher probability of explicit user confirmation due to the current inability of software automation to perform human reasoning. 
     In a second embodiment, the dialogue is presented via a graphical representation of letters that are known to be difficult for optical character recognition. By presenting text as graphics rather than textual data, software automation would be forced to infer the text from the graphical representation of letters and words. In one example, the dialogue may solicit an input with a request such as “to confirm this operation, please type green”. Alternatively, the response may be solicited as selection of graphical items that represent letters or words, thus forming a “virtual keypad”. 
     In a third embodiment, the dialogue presents a challenge/response request where the request must be computed by using the challenge data in addition to information that the human knows and is not on the computer the user is using. For example, a “2 factor authentication” may be used wherein a separate handheld device is employed to compute the response. 
     In a fourth embodiment, the interface between the human user and the machine is implemented entirely on a separate device from the workstation the user is using. For example, confirmation may be solicited via a short messaging system to a designated cell phone so that the workstation the user is using would have no information regarding the response solicited. The separate device could be on a different communication network as in the embodiment illustrated in  FIG. 5  with the alternative network  29  being a short messaging system network and the confirmation agent  31  being a cell phone. The separate device could alternatively be on the same network as the workstation host  9  in  FIG. 4  (e.g. a personal digital assistant connected to the network via 802.11 wireless networking) or could be another workstation associated with the same user  21  shown in  FIG. 3 . 
     Referring now back to  FIG. 6 . In step  53 , the confirmation interceptor receives the confirmation status message from either the designated confirmation agent or from the default confirmation agent, and subsequently determines whether or not the response was from a legitimate user. Moreover, the lack of a user response is equivalent to a lack of confirmation for the service request. 
     In step  59 , if the confirmation interceptor determines that the user has denied the service request, the service request is logged but the service request message is not forwarded to the server application software. Conversely, in step  57 , if the confirmation interceptor determines that the user has confirmed the service request, the service request is logged and the service request message is forwarded to the server application software. 
     The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the arts to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents. 
     For example, although the confirmation interceptor  5  is illustrated in  FIG. 1-FIG .  5  as an element of the server host  1 . In a first alternative embodiment, the confirmation interceptor  5  is implemented on a second server host. In this first alternative embodiment, the confirmation interceptor intercepts communication from the server host  1  by redirecting communication from the server host  1  to the second server host. In a second alternative embodiment, the confirmation interceptor is software running on the workstation. In this second embodiment, the interceptor intercepts outgoing communication and gets confirmation for those transactions that require confirmation by contacting the confirmation agent using local host communication means. In a third alternative embodiment, the confirmation interceptor is embedded in a network device such as a switch or a router, wherein the network device is part of the communication path to and from the server host. In this third alternative embodiment, communication is intercepted when it passes through the network device in which the confirmation interceptor is embedded. 
     Moreover, the confirmation agents such as confirmation agent  19  and confirmation agent  23  may be implemented as special purpose software or existing communication software such as an email client or instant messaging client. The confirmation agent may be implemented using alternative communication devices such as handheld computers, personal digital assistants, 2-way pagers, cell phones, etc. Depending on the device in which a confirmation agent is implemented, the agent may be specific software or confirmation from the user may be solicited by using the native capabilities of the device. For example, telephone confirmation may be obtained via a phone call, the input would then be prompted as a voice response.