US20130246517A1

US20130246517A1 - Method and system for containment of networked application client software by explicit human input

Info

Publication number: US20130246517A1
Application number: US10/651,591
Authority: US
Inventors: Rosen Sharma; Bakul Shah; E. John Sebes
Original assignee: Solidcore Systems Inc
Current assignee: SOLIDCARE SYSTEMS Inc; JPMorgan Chase Bank NA; Morgan Stanley Senior Funding Inc
Priority date: 2003-08-29
Filing date: 2003-08-29
Publication date: 2013-09-19
Also published as: US8539063B1

Abstract

Method and system for containing networked application client software in order to perform specified transactions only given explicit consent of a legitimate user. In one embodiment, a confirmation interceptor intercepts a service request message, queries the user of the request for a confirmation, and then either passes the service request message onto server application software or drops the request, depending on the user's confirmation response. In soliciting and processing the confirmation response, query is formulated so that the required response cannot be automatically generated by software that attempts to automate and simulate the user's actions.

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'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'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's responses to a dialogue, and much more difficult to automate the user'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'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'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'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'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.

Claims

1. A method comprising:

intercepting a service request at a confirmation interceptor;

sending a confirmation request to a user via a confirmation agent, wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction with the user via a communication device that is separate from a host computer, wherein the host computer includes a software agent that originated the service request;

receiving, from the communication device, a confirmation status message at the confirmation interceptor, wherein the confirmation status message is in response to the confirmation request; and

determining acceptability of the confirmation status message, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the status message is unacceptable, usage of a communication conduit associated with a port of the host computer is limited such that e-mail messages cannot be communicated by the host computer.

2. The method of claim 1, wherein the acceptability of the confirmation status message is determined by comparing the confirmation status message to an expected response.

3. The method of claim 1, wherein the confirmation status message is acceptable.

4. The method of claim 3, further comprising the step of forwarding the service request from the confirmation interceptor.

5. The method of claim 1, wherein the confirmation status message is unacceptable.

6. The method of claim 5, further comprising the step of discarding the service request at the confirmation interceptor.

7. The method of claim 1, after the intercepting step, further comprising the steps of determining if a confirmation mode is on.

8. The method of claim 7, wherein the confirmation mode is not on.

9. The method of claim 8, further comprising the step of forwarding the service request from the confirmation interceptor.

10. The method of claim 7, wherein the confirmation mode is on.

11. The method of claim 10, further comprising the step of determining if the service request requires confirmation of explicit human input.

12. (canceled)

13. (canceled)

14. The method of claim 11, wherein the service request does require confirmation of explicit human input.

15. (canceled)

16. The method of claim 14, wherein the confirmation request is sent to a defined confirmation agent.

17. The method of claim 14, wherein the confirmation request is sent to a default confirmation agent.

18. A system contained by verification of explicit human input, the system comprises:

a server host having server application software;

a confirmation interceptor connected to the server application software, wherein the confirmation interceptor intercepts a service request and receives a confirmation status;

a workstation having user/client software connected to the confirmation interceptor, wherein the user/client software sends the service request to the server application software;

a confirmation agent connected bi-directionally to the confirmation interceptor; and

a user connected bi-directionally to the confirmation agent and connected to the user/client software, wherein the confirmation agent sends a confirmation request to the user and the confirmation status based on a response from the user to the confirmation interceptor to determine acceptability of the confirmation status, further wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction with the user via a communication device that includes the confirmation agent, wherein the communication device is separate from the workstation, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the confirmation status is unacceptable, usage of a communication conduit associated with a port of the workstation is limited such that e-mail messages cannot be communicated by the workstation.

19. The system of claim 18, wherein the user/client software further comprises a network programming interface.

20. The system of claim 18, further comprising a data network through which the user/client software and the confirmation agent connect to the confirmation interceptor.

21. The system of claim 18, wherein the confirmation interceptor is implemented on the server host.

22. The system of claim 18, wherein the confirmation interceptor is implemented on a second server host.

23. The system of claim 18, wherein the confirmation interceptor is implemented in a network device, wherein the network device is part of any communication path to and from the server host.

24. The system of claim 18, wherein the confirmation interceptor is implemented on the workstation.

25. The system of claim 18, wherein the confirmation agent is special-purpose software customized for containing the system.

26. The system of claim 18, wherein the confirmation agent is commercially available communication software.

27. (canceled)

28. A system contained by verification of explicit human input, the system comprises:

a server host having server application software;

a first workstation host having user/client software connected to the confirmation interceptor, wherein the user/client software sends the service request to the server application software;

a second workstation host having a confirmation agent connected bi-directionally to the confirmation interceptor; and

a user connected bi-directionally to the confirmation agent and connected to the user/client software, wherein the confirmation agent sends a confirmation request to the user and the confirmation status based on a response from the user to the confirmation interceptor to determine acceptability of the confirmation status, further wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction with the user via the second workstation host that is separate from the first workstation host, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the confirmation status is unacceptable, usage of a communication conduit associated with a port of the first workstation host is limited such that e-mail messages cannot be communicated by the first workstation host.

29. The system of claim 28, wherein the user/client software further comprises a network programming interface.

30. The system of claim 28, further comprising a data network through which the user/client software and the confirmation agent connect to the confirmation interceptor.

31. The system of claim 28, wherein the confirmation interceptor is implemented on the server host.

32. The system of claim 28, wherein the confirmation interceptor is implemented on a second server host.

33. The system of claim 28, wherein the confirmation interceptor is implemented in a network device, wherein the network device is part of any communication path to and from the server host.

34. The system of claim 28, wherein the confirmation interceptor is implemented on the first workstation host.

35. The system of claim 28, wherein the confirmation agent is special-purpose software customized for containing the system.

36. The system of claim 28, wherein the confirmation agent is commercially available communication software.

37. The system of claim 28, wherein the confirmation agent is a communication device.

38. A system contained by verification of explicit human input, the system comprises:

a server host having server application software;

a workstation host having user/client software connected to the confirmation interceptor, wherein the user/client software sends the service request to the server application software; and

a confirmation agent connected bi-directionally to the confirmation interceptor, wherein the confirmation agent sends a confirmation request to a user and the confirmation status based on a response from the user to the confirmation interceptor to determine acceptability of the confirmation status, further wherein the user is connected bi-directionally to the confirmation agent and is connected to the user/client software, further wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction with the user via a communication device that includes the confirmation agent, wherein the communication device is separate from the workstation host, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the confirmation status is unacceptable, usage of a communication conduit associated with a port of the workstation host is limited such that e-mail messages cannot be communicated by the workstation host.

39. The system of claim 38, wherein the user/client software further comprises a network programming interface.

40. The system of claim 38, further comprising a data network through which the user/client software and the confirmation agent connect to the confirmation interceptor.

41. The system of claim 38, wherein the confirmation interceptor is implemented on the server host.

42. The system of claim 38, wherein the confirmation interceptor is implemented on a second server host.

43. The system of claim 38, wherein the confirmation interceptor is implemented in a network device, wherein the network device is part of any communication path to and from the server host.

44. The system of claim 38, wherein the confirmation interceptor is implemented on the workstation host.

45. The system of claim 38, wherein the confirmation agent is special-purpose software customized for containing the system.

46. The system of claim 38, wherein the confirmation agent is commercially available communication software.

47. (canceled)

48. A system contained by verification of explicit human input, the system comprises:

a server host having server application software;

a workstation host having user/client software connected to the confirmation interceptor, wherein the user/client software sends the service request to the server application software;

a first data network through which the user/client software connects to the confirmation interceptor;

a confirmation agent connected bi-directionally to the confirmation interceptor;

a second data network through which the confirmation agent connects to the confirmation interceptor; and

a user connected bi-directionally to the confirmation agent and connected to the user/client software, wherein the confirmation agent sends a confirmation request to the user and the confirmation status based on a response from the user to the confirmation interceptor to determine acceptability of the confirmation status, further wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction with the user via a communication device that includes the confirmation agent, wherein the communication device is separate from the workstation host, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the confirmation status is unacceptable, usage of a communication conduit associated with a port of the workstation host is limited such that e-mail messages cannot be communicated by the workstation host.

49. The system of claim 48, wherein the user/client software further comprises a network programming interface.

50. The system of claim 48, wherein the confirmation interceptor is implemented on the server host.

51. The system of claim 48, wherein the confirmation interceptor is implemented on a second server host.

52. The system of claim 48, wherein the confirmation interceptor is implemented in a network device, wherein the network device is part of any communication path to and from the server host.

53. The system of claim 48, wherein the confirmation interceptor is implemented on the workstation host.

54. The system of claim 48, wherein the confirmation agent is special-purpose software customized for containing the system.

55. The system of claim 48, wherein the confirmation agent is commercially available communication software.

56. (canceled)

57. (canceled)

58. A system contained by verification of explicit human input, the system comprises:

a server host having server application software;

a second workstation host having a confirmation agent connected bi-directionally to the confirmation interceptor;

a user connected bi-directionally to the confirmation agent and connected to the user/client software, wherein the confirmation agent sends a confirmation request to the user and the confirmation status based on a response from the user to the confirmation interceptor to determine acceptability of the confirmation status, further wherein the confirmation request comprises one or more dialogues configured to require human participation by the user, wherein a selected one of the dialogues involving the confirmation request includes a short message service interaction between the user via the second workstation host that is separate from the first workstation host; and

an interface connected to the confirmation interceptor, wherein the interface logs interactive events between the confirmation interceptor, the confirmation agent, and the user in a log summary, wherein the service request is associated with a destination other than the confirmation interceptor, and wherein if the confirmation status is unacceptable, usage of a communication conduit associated with a port of the first workstation host is limited such that e-mail messages cannot be communicated by the first workstation host.

59. The system of claim 58 wherein the log summary comprises address information, protocol information, host information, date and time information and status information.

60. The system of claim 58 wherein the log summary comprises a source host address of a communication channel intercepted, a destination host address of the communication channel intercepted, a protocol used to intercept the service request, host information for the communication interceptor, date and time data of interception of the service request, service request message information, a confirmation agent communication log and a communication status.

61. The method of claim 1, wherein the confirmation agent is separate from a source generating the service request.

62. The system of claim 18, wherein the confirmation agent is a separate application from the user/client software generating the service request.

63. The system of claim 48, wherein the confirmation agent is a separate application from the user/client software generating the service request.

64. The system of claim 58, wherein the confirmation agent is a separate application from the user/client software generating the service request.

65. The method of claim 1, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.

66. The system of claim 18, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.

67. The system of claim 28, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.

68. The system of claim 38, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.

69. The system of claim 48, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.

70. The system of claim 58, wherein at least one of the dialogues includes a natural language puzzle to be successfully answered with human reasoning in order to satisfy the service request.