Piggybacking malicious code blocker

A method includes determining whether a transaction request has occurred during a transaction session. Upon a determination that a transaction request has occurred, the method includes parsing critical values from the transaction request and determining whether the critical values are legitimate. If the critical values are found to be suspicious instead of legitimate, the method further includes seeking approval of the transaction request from the user of the host computer system. Upon approval of the transaction request, the transaction request is allowed. Conversely, upon denial of the transaction request, the transaction request is determined to be malicious, and protective action is taken including terminating the transaction request.

BACKGROUND

1. Field of the Invention

The present invention relates to computer system security. More particularly, the present invention relates to a system and method of detecting and blocking malicious code on a computer system.

2. Description of the Related Art

Attackers attempt to steal passwords, for example, to gain access to the bank accounts of a bank customer. To prevent this sort of theft, instead of assigning a bank customer a single static password that can be reused by an attacker if stolen, the password is continuously changed or is only valid for a single login. In this manner, even if the password is stolen, the password will not be valid when the attacker attempts to use it.

However, even if a password is only valid for a single logon, an attacker can still gain access to the bank accounts of the bank customer using an active attack, sometimes called a piggybacking attack. More particularly, the attacker installs piggybacking malicious code on a bank customer's (the victim's) computer system. The attacker waits until the bank customer logs into the bank, and piggybacks malicious transactions in the context of the bank customer's otherwise legitimate banking session. Accordingly, to facilitate secure transactions, any piggybacking attack should be detected and defeated.

SUMMARY OF THE INVENTION

In accordance with one embodiment, a method includes determining whether a transaction request has occurred during a transaction session. Upon a determination that a transaction request has occurred, the method includes parsing critical values from the transaction request and determining whether the critical values are legitimate. If the critical values are found to be suspicious instead of legitimate, the method further includes seeking approval of the transaction request from the user of the host computer system. Upon approval of the transaction request, the transaction request is allowed. Conversely, upon denial of the transaction request, the transaction request is determined to be malicious, and protective action is taken including terminating the transaction request.

In the above manner, malicious transactions within an otherwise legitimate transaction session are detected and defeated. Further, legitimate transactions are evaluated and allowed without user input, and the associated user inconvenience and annoyance. More particularly, all malicious transactions are blocked, while the user is rarely interrupted to authenticate a legitimate transaction.

Embodiments are best understood by reference to the following detailed description when read in conjunction with the accompanying drawings.

DETAILED DESCRIPTION

In accordance with one embodiment, referring toFIG. 2B, a method includes determining whether a transaction request has occurred during a transaction session in a TRANSACTION REQUEST CHECK OPERATION210. Upon a determination that a transaction request has occurred, the method includes parsing critical values from the transaction request in a PARSE CRITICAL VALUES FROM REQUEST OPERATION220and determining whether the critical values are legitimate.

More particularly, the critical values are matched against user input (e.g., keyboard input) in a CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224to determine if the critical values were input by the user and thus legitimate. The critical values are matched against values in a transaction history store in a CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234to determine if the critical values are form values cached by the Web browser and thus legitimate. The critical values are matched against cached and/or dynamic values in the HTTP request page in a CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236to determine if the critical values are cached and/or dynamic values from the HTTP request page and thus legitimate.

Upon a determination that the critical values do not match the user input, the form values cached by the Web browser, or the cached and/or dynamic values from the HTTP request page, the method further includes seeking approval of the transaction request from the user of the host computer system in a SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238.

Upon approval of the transaction request (a YES in REQUEST APPROVED CHECK OPERATION240), the transaction request is allowed in an ALLOW REQUEST OPERATION230. Conversely, upon denial of the transaction request (a NO in REQUEST APPROVED CHECK OPERATION240), the transaction request is determined to be malicious, and protective action is taken including terminating the transaction request in a TAKE PROTECTIVE ACTION OPERATION242.

In the above manner, malicious transactions within an otherwise legitimate transaction session are detected and defeated. Further, legitimate transactions are evaluated and allowed without user input, and the associated user inconvenience and annoyance. More particularly, all malicious transactions are blocked, while the user is rarely interrupted to authenticate a legitimate transaction.

More particularly,FIG. 1is a diagram of a client-server system100that includes a piggybacking malicious code blocking application106executing on a host computer system102in accordance with one embodiment of the present invention. Piggybacking malicious code blocking application106includes a HTTP proxy140, a keyboard logger142, and a transaction history store144.

Host computer system102, sometimes called a client or user device, typically includes a central processing unit (CPU)108, sometimes called a processor108, an input/output (I/O) interface110, and a memory114. Host computer system102further includes standard devices like a keyboard116, a mouse118, a printer120, and a display device122, as well as one or more standard input/output (I/O) devices123, such as a compact disk (CD) or DVD drive, floppy disk drive, or other digital or waveform ports for inputting data to and outputting data from host computer system102.

In one embodiment, piggybacking malicious code blocking application106is loaded into host computer system102via I/O device123, such as from a CD, DVD, or floppy disk containing piggybacking malicious code blocking application106.

Host computer system102is coupled to a server system130of computer system100by a network124. Server system130typically includes a display device132, a processor134, a memory136, and a network interface138. Additional computer systems such as a hacker, e.g., a second, computer system104, an optional proxy appliance150, and an application server152are also associated with network124.

Network124can be any network or network system that is of interest to a user. In various embodiments, network interface138and I/O interface110include analog modems, digital modems, or a network interface card.

Piggybacking malicious code blocking application106is stored, for example, in memory114of host computer system102and executed on host computer system102.

The particular type of and configuration of host computer system102, server system130, hacker computer system104, proxy appliance150, and application server152are not essential to this embodiment of the present invention.

Herein, in one embodiment, malicious code is defined as any computer program, module, set of modules, or code that enters a computer system environment without an authorized user's knowledge and/or without an authorized user's consent. Trojan horse software, sometimes called piggybacking malicious code, is one example of a malicious code. For example, the malicious code is propagated from hacker computer system104(the attacker's computer system) to host computer system102(the victim's computer system).

FIG. 2is a key toFIGS. 2A,2B, which are a flow diagram of a piggybacking malicious code blocking process200in accordance with one embodiment of the present invention. Referring now toFIGS. 1,2A,2B together, in one embodiment, execution of piggybacking malicious code blocking application106by processor108results in the operations of piggybacking malicious code blocking process200as described below.

From an ENTER OPERATION202, flow moves to a URL REQUESTED CHECK OPERATION204. In URL REQUESTED CHECK OPERATION204, a determination is made as to whether a Uniform Resource Locator (URL) has been requested. For example, HyperText Transfer Protocol (HTTP) proxy140intercepts the URL requested. HTTP proxies are well-known to those of skill in the art. Generally, HTTP proxy140sits between user applications of host computer system102, e.g., a Web browser of host computer system102, and network124. HTTP traffic of user applications of host computer system102pass through HTTP proxy140.

If a URL has not been requested, flow remains at URL REQUESTED CHECK OPERATION204. Conversely, if a URL has been requested, flow moves from URL REQUESTED CHECK OPERATION204to a REQUESTED URL PROTECTED CHECK OPERATION206. In REQUESTED URL PROTECTED CHECK OPERATION206, a determination is made as to whether the requested URL is protected.

In one embodiment, HTTP proxy140contains a list of protected URLs. The URL request is intercepted by HTTP proxy140, which compares the requested URL to the list of protected URLs. If the requested URL matches a URL in the list of protected URLs, a determination is made that the requested URL is protected. Conversely, if the requested URL does not match any of the URLs in the list of protected URLs, a determination is made that the requested URL is not protected.

In one embodiment, a URL is a protected URL if the URL is for a protected financial institution's web page. In one specific embodiment, the list of protected URLs is configurable, e.g., by the user or system administrator of host computer system102. In another embodiment, the list of protected URLs is periodically updated from a security center, e.g., for example, using SYMANTEC'S LIVE UPDATE® feature.

If a determination is made that the requested URL is not protected, flow returns from REQUESTED URL PROTECTED CHECK OPERATION206to URL REQUESTED CHECK OPERATION204, and awaits the next URL request. Conversely, if a determination is made that the requested URL is protected, flow moves from REQUESTED URL PROTECTED CHECK OPERATION206to an ACTIVATE USER INPUT RECORDING OPERATION208.

In one embodiment, a determination that a protected URL has been requested indicates that a financial transaction session is being initiated. For example, the protected URL request is followed by a download of a financial institution's user authentication web page, e.g., from application server152. The user, sometimes called the financial institution's customer, of host computer system102uses the financial institution's user authentication web page to logon, e.g., with a user name and password, to the financial institution's online services. Upon successful logon, the financial transaction session is initiated. During the financial transaction session, the user can perform several legitimate financial transactions.

However, if host computer system102has been compromised by piggybacking malicious code, a piggybacking malicious transaction can also be attempted during the otherwise legitimate financial transaction session. However, as set forth below, this piggybacking malicious transaction is detected and defeated in accordance with one embodiment.

Accordingly, upon a determination that a protected URL has been requested indicating that a financial transaction session is being initiated, flow moves to ACTIVATE USER INPUT RECORDING OPERATION208. In ACTIVATE USER INPUT RECORDING OPERATION208, user input recording is activated, e.g., keyboard input recording and/or other user input device recording is activated. More particularly, any keyboard input is recorded by keyboard logger142. Illustratively, the user of host computer system102inputs information into host computer system102using keyboard116, and this information is recorded by keyboard logger142as keyboard input, i.e., user input. For example, the user inputs information into a downloaded protected financial institution's web page, sometimes called a HTTP request page, such as that illustrated inFIG. 3.

In another embodiment, recording of other user input devices, e.g., mouse118, a microphone, that the user uses to input information into host computer system102is activated in ACTIVATE USER INPUT RECORDING OPERATION208.

From ACTIVATE USER INPUT RECORDING OPERATION208, flow moves to a TRANSACTION REQUEST CHECK OPERATION210. In TRANSACTION REQUEST CHECK OPERATION210, a determination is made as to whether a transaction request has been made. A transaction request is a request for a transaction, e.g., a financial transaction using a financial institution's HTTP request page. As discussed above, a transaction session can include a plurality of individual transactions. One example of a transaction request is a request to transfer money from one account to another account although the request is for any one of a number of other transactions in other embodiments.

If a determination is made that there has not been a transaction request, flow moves from TRANSACTION REQUEST CHECK OPERATION210to a TRANSACTION SESSION ENDED CHECK OPERATION212. Conversely, if a determination is made that there has been a transaction request, flow moves from TRANSACTION REQUEST CHECK OPERATION210to a STALL REQUEST OPERATION218.

Returning again to TRANSACTION SESSION ENDED CHECK OPERATION212, in TRANSACTION SESSION ENDED CHECK OPERATION212, a determination is made as to whether the transaction session has ended. If a determination is made that the transaction session has not ended, flow returns to TRANSACTION REQUEST CHECK OPERATION210, which is performed as discussed above. Accordingly, flow remains at CHECK OPERATIONS210,212, until it either a transaction request is made or the transaction session has ended.

If a determination is made that the transaction session has ended, e.g., the user has left or logged off the protected financial institution's web page or closed the Web browser, flow moves from TRANSACTION SESSION ENDED CHECK OPERATION212to a DEACTIVATE USER INPUT RECORDING OPERATION214. In DEACTIVATE USER INPUT RECORDING OPERATION214, user input recording is deactivated, e.g., keyboard input recording and/or other user input device recording is deactivated. In one embodiment, keyboard input recording by keyboard logger142is deactivated. More particularly, as the user has ended the transaction session, the risk of a piggybacked malicious transaction within the context of the legitimate transaction session is eliminated. Accordingly, user input recording is unnecessary and thus deactivated in DEACTIVATE USER INPUT RECORDING OPERATION214.

From DEACTIVATE USER INPUT RECORDING OPERATION214, flow moves to and exits at an EXIT OPERATION216or returns to URL REQUESTED CHECK OPERATION204and awaits the next URL request.

However, returning to TRANSACTION REQUEST CHECK OPERATION210, if a transaction request is made, flow moves to STALL REQUEST OPERATION218. In STALL REQUEST OPERATION218, the transaction request is stalled, i.e., is prevented from leaving host computer system102, e.g., at least temporarily. Illustratively, the transaction request is intercepted by HTTP proxy140, which stalls (holds) the transaction request until a determination is made that the transaction is legitimate as set forth below.

From STALL REQUEST OPERATION218, flow moves to a PARSE CRITICAL VALUES FROM REQUEST OPERATION220. In PARSE CRITICAL VALUES FROM REQUEST OPERATION220, critical values are parsed from the transaction request. In one embodiment, critical values, sometimes called parameters, are values that are critical to a successful piggybacking malicious code attack. For example, the transferee account number and the amount transferred are critical values and the other values of the transaction request are non-critical. In another embodiment, all values of the transaction request are critical values. Illustratively, which values of the transaction request are critical values is configurable, e.g., by the user or system administrator of host computer system102, by the financial institution, or by the security vendor.

HTTP proxy140contains application-specific knowledge of the form of the transaction request. Illustratively, a financial institution, e.g., a bank or stock brokerage firm, that desires the protection of piggybacking malicious code blocking application106provides the application-specific knowledge of the format of the financial institution's HTTP request page, the financial institution's transaction request, as well as which values in the financial institution's transaction request the financial institution considers as critical values. This information is contained in piggybacking malicious code blocking application106to enable HTTP proxy140to parse cached and/or dynamic values from the HTTP request page and to parse critical values from the transaction request.

In one embodiment, the HTTP request page is downloaded from application server152to host computer system102. Values, e.g., critical and non-critical values, are entered into the HTTP request page. A transaction request is generated, the values from the HTTP request page being transmitted as part of the transaction request. An illustrative example of a HTTP request page and a transaction request is set forth below in reference toFIG. 3.

From PARSE CRITICAL VALUES FROM REQUEST OPERATION220, flow moves to a SELECT FIRST CRITICAL VALUE OPERATION222. In SELECT FIRST CRITICAL VALUE OPERATION222, a first critical value is selected. Illustratively, a plurality of critical values are parsed from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220, and a first one of these critical values is selected in SELECT FIRST CRITICAL VALUE OPERATION222.

From SELECT FIRST CRITICAL VALUE OPERATION222, flow moves to a CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224. In CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224, a determination is made as to whether the selected critical value matches the user input.

As set forth above, the critical value is parsed from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220. As also set forth above, user input recording, e.g., keyboard input recording, was activated in ACTIVATE USER INPUT RECORDING OPERATION208and thus any user input has been recorded. The critical value is compared to the recorded user input to determine whether the critical value corresponds to information input by the user, e.g., using the keyboard, sometimes called keyboard input.

A determination in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224that the critical value matches the user input means that the user of host computer system102input the critical value in the transaction request, e.g., using keyboard116, i.e., the critical value is legitimate. Stated another way, a determination in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224that the critical value matches the user input means that the critical value in the transaction request was not programmatically entered, e.g., by piggybacking malicious code, without use of a user input device of host computer system102such as keyboard116.

Accordingly, upon a determination that the critical value matches the user input, flow moves from CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224to an UPDATE TRANSACTION HISTORY STORE OPERATION226. In UPDATE TRANSACTION HISTORY STORE OPERATION226, the transaction history store of the host computer system is updated with the critical value of the transaction request, and any other desired information associated with transaction request. In accordance with this embodiment, transaction history store144of host computer system102is updated by adding the critical value from the transaction request to transaction history store144, if the critical value is not already in transaction history store144.

Transaction history store144is a collection of critical values from previous transaction requests. Illustratively, the transferee account numbers and amounts of past transaction requests are stored in transaction history store144although any one of a number of critical values can be store depending upon the format of the transaction request and which values are considered as critical values.

From UPDATE TRANSACTION HISTORY STORE OPERATION226, flow moves to an ADDITIONAL CRITICAL VALUES CHECK OPERATION228. In ADDITIONAL CRITICAL VALUES CHECK OPERATION228, a determination is made as to whether there are additional critical values in the transaction request that have not been established as legitimate values. If a determination is made that there are no additional critical values, flow moves from ADDITIONAL CRITICAL VALUES CHECK OPERATION228to an ALLOW REQUEST OPERATION230. Conversely, if a determination is made that there is at least one additional critical value, flow moves from ADDITIONAL CRITICAL VALUES CHECK OPERATION228to a SELECT NEXT CRITICAL VALUE OPERATION232.

To illustrate, assume the transaction request contains only a single critical value that matches the keyboard input (user input) in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224. In this event, flow moves to ALLOW REQUEST OPERATION230. In ALLOW REQUEST OPERATION230, the transaction request is allowed. In one embodiment, the transaction request is released from HTTP proxy140, and the transaction request is transmitted to application server152. Recall that the transaction request was stalled in STALL REQUEST OPERATION218.

From ALLOW REQUEST OPERATION230, flow returns to TRANSACTION REQUEST CHECK OPERATION210, which is performed as discussed above.

However, if a determination is made that there is at least one additional critical value, flow moves from ADDITIONAL CRITICAL VALUES CHECK OPERATION228to SELECT NEXT CRITICAL VALUE OPERATION232. In SELECT NEXT CRITICAL VALUE OPERATION232, the next critical value from the transaction request is selected. From SELECT NEXT CRITICAL VALUE OPERATION232, flow moves to CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224, which is performed as discussed above but now on the critical value selected in SELECT NEXT CRITICAL VALUE OPERATION232.

Return again to CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224, upon a determination that the critical value being evaluated does not match the user input, e.g., keyboard input, flow moves to a CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234. In CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234, a determination is made as to whether the critical value matches a value in the transaction history store, i.e., transaction history store144in this embodiment.

As set forth above, the critical value is parsed from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220. As also set forth above, transaction history store144is a collection of critical values from previous transaction requests. The parsed critical value is compared to the stored critical values in transaction history store144to determine whether the critical value correspond to a critical value from a previous transaction request.

As discussed above, the critical value being evaluated was not input directly into the transaction request using keyboard116. However, critical values can legitimately be entered into a transaction request by means other than keyboard116.

For example, form values are cached by the Web browser and programmatically entered into the transaction request. For example, in a previous transaction request, the user entered the form value as a critical value into the previous transaction request using keyboard116. In this previous transaction request, a determination was made that the critical value matched the user input in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224, and transaction history store144was updated with the critical value. As one specific example, the user pays recurring bills every month by transferring funds from a bank account, and the recipient of each transaction appears in the transaction history store, the recipients having been added during the previous transaction requests.

Accordingly, if the critical value being evaluated matches a value in transaction history store144, then the critical value is the same as a critical value previously entered by the user or parsed from the HTTP request page as discussed further below in regards to a CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236. In either event, the critical value corresponds to a critical value previously entered by the user or retrieved from application server152, i.e., is a legitimate critical value. Thus, upon a determination that the critical value matches a value in the transaction history store, flow moves from CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234to ADDITIONAL CRITICAL VALUES CHECK OPERATION228, which is performed as discussed above.

Conversely, upon a determination that the critical value being evaluated does not match any of the values in the transaction history store, flow moves from CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234to CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236. In CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236, a determination is made as to whether the critical value being evaluated matches a value in the HTTP request page.

In this event, the critical value being evaluated was not input by the user directly into the transaction request nor was the critical value programmatically entered as a form value by the Web browser. However, critical values can legitimately be entered into a transaction request as cached and/or dynamic values in the HTTP request page from application server152. For example, a list of past payees is listed in a pulldown menu in the HTTP request page as cached values downloaded from application server152at the same time as the HTTP request page or as dynamic values downloaded from application server152dynamically after the initial download of the HTTP request page, e.g., through the use of AJAX (Asynchronous JavaScript and XML). The user selects one of the past payees, e.g., using mouse118, and the selected past payees becomes a critical value in the transaction request.

As set forth above, the critical value was parsed from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220. As also set forth above, HTTP proxy140has knowledge of the format of the HTML of the HTTP request page and parses cached and/or dynamic values from the HTTP request page. The parsed critical value of the transaction request is compared to cached and/or dynamic values from the HTTP request page to determine whether the critical value correspond to a cached and/or dynamic value from the HTTP request page.

A determination in CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236that the critical value matches a cached and/or dynamic value in the HTTP request page means that the HTTP request page contained the critical value, i.e., the critical value is legitimate. In this manner, the critical value is authenticated without requiring user authentication, e.g., in instances where the user has been using the financial institution's online services for some time but piggybacking malicious code blocking application106has just been installed.

Accordingly, upon a determination that the critical value matches a cached and/or dynamic value in the HTTP request page, flow moves from CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236to UPDATE TRANSACTION HISTORY STORE OPERATION226, which is performed as discussed above. More particularly, transaction history store144is updated with the critical value from the transaction request.

Conversely, upon a determination that the critical value does not match a cached and/or dynamic value in the HTTP request page, flow moves from CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236to a SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238. In SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238, approval, e.g., from the user of host computer system102, of the transaction request is sought.

In this event, at least one critical value of the transaction request was not input by the user directly into the transaction request, nor was the critical value programmatically entered as a form value by the Web browser, nor was the critical value programmatically entered as a cached and/or dynamic value from the HTTP request page. Accordingly, the transaction request is suspicious. More particularly, the transaction request is likely to be a piggybacking malicious transaction request in the context of an otherwise legitimate transaction session.

Accordingly, in SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238, the user of host computer system102is asked to explicitly authenticate (approve) the transaction request. Any one of a number of authentication techniques can be used. In one embodiment, a simple yes/no dialog box is displayed to the user, and the user selects the “yes” button to approve the transaction request and “no” button to deny the transaction request.

In another embodiment, a picture containing text is displayed to the user, and the user is asked to enter the displayed text. If the text is entered correctly, the transaction request is approved. Conversely, if the text is not entered or entered incorrectly, the transaction request is denied. Generally, the approval of the transaction request is sought using an authentication technique that prevents malicious code from maliciously approving the transaction request in the event the transaction request is actually malicious.

From SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238, flow moves to a REQUEST APPROVED CHECK OPERATION240. In REQUEST APPROVED CHECK OPERATION240, a determination is made as to whether the suspicious transaction request has been approved by the user of host computer system102.

If the transaction request has been approved by the user, the suspicious transaction request is legitimate, and flow moves from REQUEST APPROVED CHECK OPERATION240to UPDATE TRANSACTION HISTORY STORE OPERATION226and ALLOW REQUEST OPERATION230, which are performed as discussed above. Conversely, if the transaction request is not approved by the user, the suspicious transaction request is malicious, and flow moves from REQUEST APPROVED CHECK OPERATION240to a TAKE PROTECTIVE ACTION OPERATION242.

In TAKE PROTECTIVE ACTION OPERATION242, protective action is taken to defeat the malicious transaction request. Illustratively, the transaction request is terminated, e.g., by HTTP proxy140. Recall the transaction request was stalled in STALL REQUEST OPERATION218.

In another embodiment, the user of host computer system102and/or a system administrator are alerted, e.g., with a pop-up window, by writing to a log file, by sending an e-mail, or otherwise, that malicious code has been detected on host computer system102. Any one of a number of protective actions can be taken, and the above examples are illustrative only, and not limiting.

From TAKE PROTECTIVE ACTION OPERATION242, flow moves to DEACTIVATE USER INPUT RECORDING OPERATION214, which is performed as discussed above.

Although CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224is set forth as preceding CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234, which, in turn, is set forth as preceding CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236, in other embodiments, CHECK OPERATIONS224,234,236are performed in a different order or simultaneously. Generally, CHECK OPERATIONS224,234,236are performed in any order or simultaneously to determine whether the critical value being evaluated is legitimate.

FIG. 3is a protected financial institution's HTTP request page300A as displayed on display device122of host computer system102ofFIG. 1in accordance with one embodiment of the present invention. Referring now toFIGS. 1,2A,2B, and3together, HTTP request page300A is downloaded to host computer system102from application server152. User input recording is activated in ACTIVATE USER INPUT RECORDING OPERATION208as set forth above.

HTTP request page300A is an interface for transferring money from one account to another account. HTTP request page300A includes a transferor account number field302, a transferee account number field306, an amount field310, and a submit button314.

For purposes of illustration, a user using keyboard116and mouse118inputs information into HTTP request page300A to transfer money from one account to another account, i.e., to perform a legitimate financial transaction.

To illustrate, a user uses a pulldown menu316to select a transferor account value304, i.e., “555-555xxx”, in transferor account number field302. In the transferee account number field306, the user types a “4” and the Web browser inserts the form value “444-444xxx” as a transferee account value308. In the amount field310, the user types the amount “500.00” as an amount value312. The information input using keyboard116is recorded by keyboard logger142.

The user then activates submit button314, e.g., by clicking on submit button314, which initiates a transaction request. Transferor account value304, transferee account value308, and amount value312, i.e., “555-555xxx”, “444-444xxx”, “500.00”, are obtained from HTTP request page300A and packaged into a transaction request.

At TRANSACTION REQUEST CHECK OPERATION210, a determination is made that the transaction request has been made and the transaction request is stalled in STALL REQUEST OPERATION218. Transferee account value308and amount value312are parsed as critical values from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220. Transferee account value308is selected as the first critical value to be evaluated in SELECT FIRST CRITICAL VALUE OPERATION222. A determination is made in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224that transferee account value308does not match the user input, and flow moves to CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234. Recall that transferee account value308was programmatically entered by the Web browser as a cached form value that was entered by the user in a previous transaction request and thus is a value in transaction history store144.

In CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE OPERATION234, a determination is made that transferee account value308does match a value in transaction history store144and flow moves to ADDITIONAL CRITICAL VALUES CHECK OPERATION228.

In ADDITIONAL CRITICAL VALUES CHECK OPERATION228, a determination is made that there is at least one additional critical value that has not been evaluated in the transaction request, i.e., amount value312. Accordingly, amount value312is selected as the next critical value to be evaluated in SELECT NEXT CRITICAL VALUE OPERATION232.

Recall that amount value312was input by the user using keyboard116. Accordingly, a determination is made that amount value312matches the user input in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224. Transaction history store144is updated with amount value312in UPDATE TRANSACTION HISTORY STORE OPERATION226.

A determination is made that there are no additional critical values to be evaluated in ADDITIONAL CRITICAL VALUES CHECK OPERATION228, and the transaction request, which is legitimate, is allowed in ALLOW REQUEST OPERATION230.

FIG. 4is a protected financial institution's HTTP request page300B as displayed on display device122of host computer system102(FIG. 1) in accordance with another embodiment of the present invention. Referring now toFIGS. 1,2A,2B, and4together, HTTP request page300B is similar to HTTP request page300A ofFIG. 3except that malicious information has been programmatically entered into HTTP request page300B to maliciously transfer money from one account to another account, i.e., to perform a malicious financial transaction. Although the malicious transaction request is discussed in reference toFIG. 4for purposes of illustration, it is to be understood that the malicious transaction request can be programmatically constructed without being displayed on display device122to conceal the malicious transaction from the user.

In accordance with this malicious transaction, a malicious transferee account value408, i.e., “666-666xxx” is programmatically entered into transferee account number field306. Further, a malicious amount value412, i.e., “10,000.00” is programmatically entered into amount field310. Submit button314is activated, which initiates the malicious transaction request. Transferor account value304, malicious transferee account value408, and malicious amount value412, i.e., “555-555xxx”, “666-666xxx”, “10,000.00”, are obtained from HTTP request page300B and packaged into a malicious transaction request.

At TRANSACTION REQUEST CHECK OPERATION210, a determination is made that the transaction request has been made and the transaction request is stalled in STALL REQUEST OPERATION218. Transferee account value408and amount value412are parsed as critical values from the transaction request in PARSE CRITICAL VALUES FROM REQUEST OPERATION220. Transferee account value408is selected as the first critical value to be evaluated in SELECT FIRST CRITICAL VALUE OPERATION222. A determination is made in CRITICAL VALUE MATCHES USER INPUT CHECK OPERATION224that transferee account value308does not match the user input, as account value308was not input by the user, and flow moves to CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE CHECK OPERATION234.

In CRITICAL VALUE MATCHES VALUE IN TRANSACTION HISTORY STORE OPERATION234, a determination is made that transferee account value408does not match a value in the transaction history store, as transferee account value408was not programmatically entered as a cached form value by the Web browser, and so flow moves to CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236. In CRITICAL VALUE MATCHES VALUE IN HTTP REQUEST PAGE CHECK OPERATION236, a determination is made that transferee account value408does not match a value in the HTTP request page, as transferee account value408was not entered as a cached or dynamic value in the HTTP request page. Accordingly, the user is asked to approve the malicious transaction request in SEEK APPROVAL OF SUSPICIOUS REQUEST OPERATION238.

Realizing that the user did not make the transaction request, the user denies the transaction request and flow moves from REQUEST APPROVED CHECK OPERATION240to TAKE PROTECTIVE ACTION OPERATION242. In TAKE PROTECTIVE ACTION OPERATION242, protective action is taken. At a minimum, the malicious transaction request is terminated.

In the above manner, malicious transactions within an otherwise legitimate transaction session are detected and defeated. Further, legitimate transactions are evaluated and allowed without user input, and the associated user inconvenience and annoyance. More particularly, all malicious transactions are blocked, while the user is rarely interrupted to authenticate a legitimate transaction.

Referring again toFIG. 1, although piggybacking malicious code blocking application106is set forth is being in host computer system102, in another embodiment, piggybacking malicious code blocking application106is in proxy appliance150instead. In accordance with this embodiment, proxy appliance150is located between and intercepts HTTP traffic between host computer system102and network124and a secure connection exists between host computer system102and proxy appliance150.

In another embodiment, client-server system100does not include proxy appliance150and piggybacking malicious code blocking application106is on host computer system102. In accordance with this embodiment, host computer system102is directly connected to network124.

Further, although piggybacking malicious code blocking application106is referred to as an application, this is illustrative only. Piggybacking malicious code blocking application106should be capable of being called from an application or the operating system. In one embodiment, an application is generally defined to be any executable code. Moreover, those of skill in the art will understand that when it is said that an application or an operation takes some action, the action is the result of executing one or more instructions by a processor.

While embodiments in accordance with the present invention have been described for a client-server configuration, an embodiment of the present invention is carried out using any suitable hardware configuration or means involving a personal computer, a workstation, a portable device, or a network of computer devices. Other network configurations other than client-server configurations, e.g., peer-to-peer, web-based, intranet, and internet network configurations, are used in other embodiments.

Herein, a computer program product comprises a medium configured to store or transport computer readable code in accordance with an embodiment of the present invention. Some examples of computer program products are CD-ROM discs, DVDs, ROM cards, floppy discs, magnetic tapes, computer hard drives, servers on a network and signals transmitted over a network representing computer readable code. In another embodiment, a computer program product comprises a tangible medium configured to store computer readable code including CD-ROM discs, DVDs, ROM cards, floppy discs, magnetic tapes, computer hard drives and servers on a network.

As illustrated inFIG. 1, this medium belongs to the computer system itself. However, the medium is also removed from the computer system. For example, piggybacking malicious code blocking application106is stored in memory that is physically located in a location different from processor108, e.g., memory136of server system130. Processor108should be coupled to the memory136. This could be accomplished in a client-server system, or alternatively via a connection to another computer via modems and analog lines, or digital interfaces and a digital carrier line.

More specifically, in one embodiment, host computer system102and/or server system130is a portable computer, a workstation, a two-way pager, a cellular telephone, a digital wireless telephone, a personal digital assistant, a server computer, an Internet appliance, or any other device that includes components that execute piggybacking malicious code blocking application106in accordance with at least one of the embodiments as described herein. Similarly, in another embodiment, host computer system102and/or server system130is comprised of multiple different computers, wireless devices, cellular telephones, digital telephones, two-way pagers, personal digital assistants, server computers, or any desired combination of these devices that are interconnected to perform the methods as described herein.

In view of this disclosure, piggybacking malicious code blocking application106in accordance with one embodiment of the present invention can be implemented in a wide variety of computer system configurations. In addition, piggybacking malicious code blocking application106could be stored as different modules in memories of different devices. For example, piggybacking malicious code blocking application106could initially be stored in server system130, and as necessary, a portion of piggybacking malicious code blocking application106could be transferred to host computer system102and executed on host computer system102. Consequently, part of the piggybacking malicious code blocking functionality would be executed on processor134of server system130, and another part would be executed on processor108of host computer system102. In view of this disclosure, those of skill in the art can implement various embodiments of the present invention in a wide variety of physical hardware configurations using an operating system and computer programming language of interest to the user.

In yet another embodiment, piggybacking malicious code blocking application106is stored in memory136of server system130. Piggybacking malicious code blocking application106is transferred over network124to memory114in host computer system102. In this embodiment, network interface138and I/O interface110would include analog modems, digital modems, or a network interface card. If modems are used, network124includes a communications network, and piggybacking malicious code blocking application106is downloaded via the communications network.

This disclosure provides exemplary embodiments of the present invention. The scope of the present invention is not limited by these exemplary embodiments. Numerous variations, whether explicitly provided for by the specification or implied by the specification or not, may be implemented by one of skill in the art in view of this disclosure.