Symantec 1012
`IPR of U.S. Pat. No. 8,141,154
`
`000001
`
`

`
`Privacy Act Statement
`
`The Privacy Act of 1974 (P.L. 93-579) requires that you be given certain information in connection with your
`submission of the attached form related to a patent application or patent. Accordingly, pursuant to the
`requirements of the Act, please be advised that: (1) the general authority for the collection of this information is
`35 U.S.C. 2(b)(2); (2) furnishing of the information solicited is voluntary; and (3) the principal purpose for which
`the information is used by the U.S. Patent and Trademark Office is to process and/or examine your submission
`related to a patent application or patent.
`If you do not furnish the requested information, the U.S. Patent and
`Trademark Office may not be able to process and/or examine your submission, which may result in termination
`of proceedings or abandonment of the application or expiration of the patent.
`
`The information provided by you in this form will be subject to the following routine uses:
`
`1 . The information on this form will be treated confidentially to the extent allowed under the Freedom of
`Information Act (5 U.S.C. 552) and the Privacy Act (5 U.S.C 552a). Records from this system of
`records may be disclosed to the Department of Justice to determine whether disclosure of these
`records is required by the Freedom of Information Act.
`A record from this system of records may be disclosed, as a routine use, in the course of presenting
`evidence to a court, magistrate, or administrative tribunal, including disclosures to opposing counsel in
`the course of settlement negotiations.
`A record in this system of records may be disclosed, as a routine use, to a Member of Congress
`submitting a request involving an individual,
`to whom the record pertains, when the individual has
`requested assistance from the Member with respect to the subject matter of the record.
`A record in this system of records may be disclosed, as a routine use, to a contractor of the Agency
`having need for the information in order to perform a contract. Recipients of information shall be
`required to comply with the requirements of the Privacy Act of 1974, as amended, pursuant to 5 U.S.C.
`552a(m).
`A record related to an International Application filed under the Patent Cooperation Treaty in this
`system of records may be disclosed, as a routine use,
`to the International Bureau of the World
`Intellectual Property Organization, pursuant to the Patent Cooperation Treaty.
`A record in this system of records may be disclosed, as a routine use, to another federal agency for
`purposes of National Security review (35 U.S.C. 181) and for review pursuant to the Atomic Energy Act
`(42 U.S.C. 218(c)).
`A record from this system of records may be disclosed, as a routine use, to the Administrator, General
`Services, or his/her designee, during an inspection of records conducted by GSA as part of that
`agency’s responsibility to recommend improvements in records management practices and programs,
`under authority of 44 U.S.C. 2904 and 2906. Such disclosure shall be made in accordance with the
`GSA regulations governing inspection of records for this purpose, and any other relevant (i.e., GSA or
`Commerce) directive. Such disclosure shall not be used to make determinations about individuals.
`A record from this system of records may be disclosed, as a routine use, to the public after either
`publication of the application pursuant to 35 U.S.C. 122(b) or issuance of a patent pursuant to 35
`U.S.C. 151. Further, a record may be disclosed, subject to the limitations of 37 CFR 1.14, as a routine
`use, to the public if the record was filed in an application which became abandoned or in which the
`proceedings were terminated and which application is referenced by either a published application, an
`application open to public inspection or an issued patent.
`A record from this system of records may be disclosed, as a routine use, to a Federal, State, or local
`law enforcement agency,
`if the USPTO becomes aware of a violation or potential violation of law or
`regulation.
`
`OOOOO2
`
`000002
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CONI
`
`COMPUTER SECURITY METHOD AND SYSTEM
`
`WITH INPUT PARAMETER VALIDATION
`
`PRIORITY REFERENCE TO RELATED APPLICATIONS
`
`[0001]
`
`This application is a continuation of pending U.S. Patent Application No.
`
`12/174,592, filed on July 16, 2008, entitled “COMPUTER SECURITY METHOD
`
`AND SYSTEM WITH INPUT PARAMETER VALIDATION,” which is a
`
`continuation-in-part of U.S. Patent Application No. 11/354,893, filed on February 16,
`
`2006, entitled SYSTEM AND METHOD FOR ENFORCING A SECURITY
`
`CONTEXT ON A DOWNLOADABLE, now U.S. Patent No. 7,613,918, and is a
`
`continuation-in-part of U.S. Patent Application No. ll/298,475, filed December 12, 2005,
`
`entitled “SYSTEM AND METHOD FOR INSPECTING DYNAMICALLY
`
`GENERATED EXECUTABLE CODE,” now U.S. Patent No. 7,757,289.
`
`FIELD OF THE INVENTION
`
`[0002]
`
`The field of the present invention is computer security.
`
`BACKGROUND OF THE INVENTION
`
`[0003]
`
`Computer security software and hardware are used to inspect downloadables, to
`
`determine if they are malicious. The term "downloadable" refers generally to an
`
`executable application program, which is downloaded from a source computer and run on
`
`a destination computer. There are many different types of malicious downloadables,
`
`including malware, phishing, spyware, Trojan horses, Viruses and worms. Malicious
`
`downloadables often enter an internal computer network from an external network, and
`
`infect all or most of the computers in the internal network once they break in. As such,
`
`computer security systems often employ gateway computers to scan and filter incoming
`
`downloadables.
`
`OOOOO3
`
`000003
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CONI
`
`[0004]
`
`Scanning downloadables at a gateway computer may be performed by
`
`running the programs; however, running the programs on the gateway computer instead
`
`of on the computer in the internal network for which the programs are intended, may
`
`result in the gateway computer failing to detect exploits in the downloadables.
`
`[0005]
`
`Scanning downloadables at a gateway computer may also be performed by
`
`analyzing the programs. Assignee's U.S. Patent No. 6,092,194 describes such a gateway
`
`security system.
`
`[0006] When analyzing downloadables, scanners generally search for computer
`
`operations that are potentially suspicious. For example, if a suspect downloadable invokes
`
`a function call that writes to a file system or opens a network connection or changes a
`
`registry entry, such behavior raises a warning fiag for potentially malicious activity. A
`
`security system may block a downloadable from reaching an internal network if the
`
`downloadable includes a suspicious computer operation. However, most non-malicious
`
`downloadables use these same computer operations in an innocuous way, and such a
`
`security system may block both good and bad downloadables from reaching the internal
`
`network.
`
`[0007]
`
`Consider, for example, a function that deletes a file in the file system.
`
`Many safe programs, such as software installation programs, generate temporary files
`
`during execution, and delete the temporary files upon completion. However, a malicious
`
`program may delete critical operating system files. A security system that blocks
`
`downloadables which invoke a function to delete a file would block safe downloadables in
`
`addition to the malicious ones.
`
`[0008]
`
`Consider, for example, a downloadable that includes the following simple
`
`JavaScript source code:
`
`<SCRIPT LANGUAGE="JavaScript">
`var b = new ActiveXObj ect("Msxml2.XMLHTTP“);
`exploit data = "SSSSSSSSSSSSSSSSSSSSSS exploit";
`
`OOOOO4
`
`000004
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CONI
`
`b.setRequestHeader(exploit data);
`</SCRIPT>
`
`This source code initiates a new Msxml2.XMLHTTP ActiveX object, and invokes the
`
`object's method setRequestHeader(). An Msxml2.XMLHTTP object is a standard object
`
`built into the Microsoft XML parser. The Msxml2.XMLHTTP object is an important part of
`
`the Ajax web development technique, and is used to implement responsive and dynamic
`
`web applications.
`
`It is used on a client side web page to grab information from the server,
`
`process it, and use the information on the current web page (as opposed to having to reload
`
`a web page).
`
`[0009]
`
`The method setRequestHeader() is generally a safe function that simply adds an
`
`HTTP header to a request. The following code snippet shows how setRequestHeader() is
`
`used, for example, to set the HTTP Content-Type header to ‘text/xml' before sending a
`
`request body.
`
`var oReq = new XMLHttpRequest();
`oReq.open("POST", sURL, false);
`oReq .setRequestHeader(CONTENT, "text/xml");
`oReq.send(sRequestBody);
`
`As such, the example JavaScript above appears innocuous.
`
`[0010]
`
`However, the input parameter to setRequestHeader() in the example JavaScript
`
`code above is only evaluated at run-time, and a code exploit may be triggered in the
`
`process of evaluating the input parameter. More generally, input parameters to function
`
`calls, even for safe functions, are potential hiding places for code exploits. Since input
`
`parameters may only be determined at run-time, such code exploits may go undetected
`
`when scanning downloadables.
`
`[0011]
`
`It would thus be of advantage for a security system to be able to validate input
`
`parameters that are evaluated at run-time.
`
`It would be of further advantage for a security
`
`system to be able to determine if a given input parameter will exploit a non-malicious
`
`function, prior to actually executing the non-malicious function with the given input
`
`OOOOO5
`
`000005
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CONI
`
`parameter.
`
`SUMMARY OF THE DESCRIPTION
`
`[0012]
`
`Aspects of the present invention relate to a computer security method and system
`
`that validates input parameters to computer operations when scanning a suspect
`
`downloadable.
`
`In one embodiment, the present invention overwrites suspicious computer
`
`operations, and appends special monitoring code to the suspect downloadable that, when
`
`invoked, validates input parameters to computer operations.
`
`[0013]
`
`The present invention may be embodied at a gateway computer, at a server
`
`computer, or at a client computer.
`
`[0014]
`
`There is thus provided in accordance with an embodiment of the present
`
`invention a method for identifying suspicious downloadables, including receiving a
`
`downloadable, scanning the downloadable to identify suspicious computer operations
`
`therein, and if at least one suspicious computer operation is identified, then overwriting the
`
`suspicious computer operations with substitute computer operations, and appending
`
`monitoring program code to the downloadable thereby generating a modified
`
`downloadable, wherein the monitoring program code includes program instructions for
`
`validating input parameters for the suspicious computer operations during run-time of the
`
`downloadable.
`
`[0015]
`
`There is additionally provided in accordance with an embodiment of the present
`
`invention a computer security system, including a receiver for receiving a downloadable, a
`
`scanner, coupled with the receiver, for scanning the downloadable to identify suspicious
`
`computer operations therein, a code modifier, coupled with the scanner, for overwriting the
`
`suspicious computer operations with substitute computer operations, if at least one
`
`suspicious computer operation is identified by the scanner, and for appending monitoring
`
`program code to the downloadable thereby generating a modified downloadable, if at least
`
`one suspicious computer operation is identified by the scanner, and a processor, coupled
`
`OOOOO6
`
`000006
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CON1
`
`with the code modifier, for executing programmed instructions, wherein the monitoring
`
`program code includes program instructions for the processor to validate input parameters
`
`for the suspicious computer operations during run-time of the downloadable.
`
`[0016]
`
`There is further provided in accordance with an embodiment of the present
`
`invention a method for identifying suspicious downloadables, including receiving a
`
`downloadable, and appending monitoring program code to the downloadable thereby
`
`generating a modified downloadable, wherein the monitoring program code includes
`
`program instructions for identifying suspicious computer operations during run-time of the
`
`downloadable, for overwriting the suspicious computer operations with substitute
`
`computer operations during run-time of the downloadable, and for validating input
`
`parameters for the suspicious operations during run-time of the downloadable.
`
`[0017]
`
`There is yet further provided in accordance with an embodiment of the present
`
`invention a computer security system, including a receiver for receiving a downloadable, a
`
`code modifier, coupled with the scanner, for appending monitoring program code to the
`
`downloadable thereby generating a modified downloadable, and a processor, coupled with
`
`the code modifier, for executing programmed instructions, wherein the monitoring
`
`program code includes program instructions for the processor to identify suspicious
`
`computer operations during run-time of the downloadable, to overwrite the suspicious
`
`computer operations with substitute computer operations during run-time of the
`
`downloadable, and to validate input parameters for the suspicious computer operations
`
`during run time of the downloadable.
`
`[0018]
`
`There is moreover provided in accordance with an embodiment of the present
`
`invention a method for identifying suspicious downloadables, including scanning a
`
`downloadable to detect the presence of at least one suspicious computer operation,
`
`dynamically generating during run-time of the downloadable at least one input parameter
`
`for the at least one suspicious computer operation detected by the scanning, and
`
`000007
`
`000007
`
`

`
`Attorney Docket No. FIN0009-CIPI-CON1
`
`determining whether or not the dynamically generated at least one input parameter
`
`corresponds to a safe input parameter for the at least one suspicious computer operation.
`
`[0019]
`
`There is additionally provided in accordance with an embodiment of the present
`
`invention a computer security system, including a scanner for scanning a downloadable to
`
`detect the presence of at least one suspicious computer operation, and a processor that
`
`executes programmed instructions for dynamically generating during run-time of the
`
`downloadable at least one input parameter for the at least one suspicious computer
`
`operation detected by the scanner, and for determining whether or not the dynamically
`
`generated at least one input parameter corresponds to a safe input parameter for the at least
`
`one suspicious computer operation.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0020]
`
`The present invention will be more fully understood and appreciated from the
`
`following detailed description, taken in conjunction with the drawings in which:
`
`[0021]
`
`FIG. 1 is a simplified block diagram of a computer security system with input
`
`parameter validation, in accordance with an embodiment of the present invention;
`
`[0022]
`
`FIG. 2 is a method for computer security with input parameter validation,
`
`in accordance with an embodiment of the present invention; and
`
`[0023]
`
`FIG. 3 is an alternative method for computer security with input parameter
`
`validation, in accordance with an embodiment of the present invention.
`
`DETAILED DESCRIPTION
`
`[0024]
`
`Aspects of the present invention relate to a computer security method and system
`
`that receives as input a downloadable, and detects whether or not the downloadable is
`
`potentially malicious by inter alia validating input parameters to computer operations.
`
`[0025]
`
`Reference is now made to FIG. 1, which is a simplified block diagram of a
`
`OOOOO8
`
`000008
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`computer security system with input parameter validation, in accordance with an
`
`embodiment of the present invention. The embodiment of the security system shown in
`
`FIG. lincludes a gateway computer 100 and two destination computers
`
`110. Downloadables transmitted to destination computers 110 first pass through
`
`gateway 100.
`
`[0026]
`
`Downloadables may be inter alia in the form of source code, such as
`
`JavaScript, or in the form of compiled code, such as Java applets, that is de- compiled
`
`in order to derive its source code.
`
`[0027]
`
`One of the responsibilities of gateway computer 100 is to run security checks on
`
`downloadables prior to their reaching destination computers 110. If gateway computer
`
`100 identifies a potentially malicious downloadable, then it either blocks the downloadable
`
`fiom reaching destination computers 110, or neutralizes the potentially malicious portions
`
`of the downloadable prior to forwarding the downloadable to destination computers 110.
`
`[0028]
`
`As shown in FIG. 1, gateway computer 100 includes a processor 120, for
`
`executing programmed instructions, a receiver 130 for receiving a downloadable in transit
`
`to one or both of destination computers 110, and a transmitter 140 for forwarding the
`
`received downloadable to one or both of destination computers 110. Gateway computer 100
`
`further includes a scanner 150, for scanning a downloadable received by receiver 130, and a
`
`code modifier 160 for appending special modification code to the downloadable received
`
`by receiver 130.
`
`[0029]
`
`Generally, scanner 150 inspects downloadable source code for the presence of
`
`suspicious computer operations. Ifthe downloadable is in compiled object code form,
`
`the scanner 150 first de-compiles the object code to derive downloadable source code
`
`therefrom, and then inspects the downloadable source code for the presence of
`
`suspicious operations.
`
`[0030]
`
`If no suspicious computer operations are detected, then the downloadable is
`
`000009
`
`000009
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`deemed to be safe, and is forwarded to one or both of destination computers 110 via
`
`transmitter 140. However, if scanner 150 detects one or more suspicious computer
`
`operations, then processor 120 appends special modification code 170 to the downloadable,
`
`thereby generating a modified downloadable. Modification code 170 includes instructions
`
`for overwriting the suspicious computer operations detected by scanner 150, and for
`
`validating their input parameters. If all input parameters to all suspicious computer
`
`operations are validated, then the downloadable is deemed to be safe, and is forwarded to
`
`one or both of destination computers 110. Otherwise, the downloadable is deemed to be
`
`potentially malicious.
`
`[0031]
`
`For a downloadable deemed to be potentially malicious, processor 120 may
`
`neutralize the suspicious computer operations by eliminating such operations, or by
`
`replacing their input parameters with valid input parameters, and then forwarding the
`
`remedied downloadable to one or both of destination computers 110. Further, processor
`
`120 may first execute the remedied downloadable within a secure environment and inspect
`
`the execution results, prior to forwarding the downloadable. Alternatively, processor 120
`
`may block the downloadable fiom being forwarded to destination computers 110. Further
`
`details of operation of scanner 150 and code modifier 160 are provided in the discussion of
`
`FIG. 2 hereinbelow.
`
`[0032]
`
`Reference is now made to FIG. 2, which is a method for computer security with
`
`input parameter validation, in accordance with an embodiment of the present invention.
`
`In
`
`conjunction with FIG. 2, reference is also made to the following example downloadable,
`
`used to supplement the description of various steps in FIG. 2 by way of example.
`
`000010
`
`000010
`
`

`
`Attorney Docket No. FIN0009-CIP1-CON1
`
`Original JaVaScript source program code:
`
`<SCRIPT LANGUAGE="JaVaScript">
`
`Var b = new ActiVeXObject("Msxm12.XMLHTTP");
`b.setRequestHeader("SSSSSSSSSSSSSSSSSSSSSS");
`</SCRIPT>
`
`Modified program code:
`
`<SCRIPT LANGUAGE="JaVaScript">
`
`Vu1nAcxStruct=[["Msxm12.XMLHTTP", [['setRequestHeader',
`
`function(){a11ow=["GET", “POST“, “HEAD“, "DELETE", "PUT",
`
`"CONNECT","OPTIONS"]; for(i in a11ow){if
`
`(arguments [0 ==a11ow[i])retum; } a1ert("ma1icious! ") } ] ] , []]]
`
`function makeVu1nObjDict(arr)
`
`{
`
`}
`
`dict=new Obj ect();
`
`for(i in arr) {
`
`diet[arr[i] [0]]=[arr[i][2] ,arr[i][3]];
`
`dict[arr[i][1]]=[arr[i] [2],arr[i] [3]];
`
`}
`return dict;
`
`Vu1n_Obj _Dict=makeVu1nObj Dict(Vu1nAcxStruct);
`
`function checkAcx(acxId)
`
`{
`
`}
`
`if (acxld in Vu1n_Obj_Dict){
`
`obj = new Obj ect();
`
`for(i in Vu1n_Obj_Dict[acx1d] [0])
`
`{
`
`}
`
`obj [Vu1n_Obj_Dict[acx1d][0] [i][0]] =
`
`Vu1n_Obj_Dict[acx1d] [0] [i] [1 ];
`
`obj ['myID'] = acxld;
`
`return obj;
`
`}
`return new Obj ect();
`
`-l>UJl\)p_A
`
`5
`
`6
`
`7
`
`8
`
`9
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`18
`
`1 9
`
`20
`
`2 1
`22
`
`23
`
`24
`
`25
`
`2 6
`
`27
`
`2 8
`
`29
`
`30
`
`3 1
`
`32
`
`3 3
`
`34
`35
`
`3 6
`
`37
`
`00001 1
`
`000011
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`38
`
`39
`4 0
`41
`
`window.ActiveXObject = checkAcx;
`
`var b = new ActiveXObject("Msxml2.XMLHTTP");
`b.setRequestHeader("SSSSSSSSSSSSSSSSSSSSSS");
`</SCRIPT>
`
`[0033]
`
`FIG. 2 begins at step 210, whereat an original downloadable is received in
`
`transit to one or more destination computers. Referring to the example JavaScript code
`
`hereinabove, the downloadable received at step 210 includes lines 1 -4. These lines of
`
`code cause a browser to create an ActiveX object named "Msxmi2.XMLHTTP", and assign
`
`the created object to variable b. The setRequestHeader() method of object b is called using
`
`an input parameter "SSSSSSSSSSSSSSSSSSSSSS". At this stage it is unclear ifthe input
`
`parameter is legitimate for this method, or if it abuses the method call in a malicious way.
`
`[0034]
`
`At step 220, the received downloadable is scanned, to detect the presence of
`
`suspicious computer operations. Referring further to the example code, the function call
`
`setRequestHeader() is identified as being suspicious.
`
`In one embodiment of the present
`
`invention, a dictionary of suspicious operations is accessed and consulted by scanner 150, in
`
`order to detect which computer operations are potentially malicious. Such a dictionary is
`
`included in lines 6 — 9 of the example program code, as described below with reference to
`
`step 270.
`
`In an alternative embodiment of the present invention, a dictionary of non-
`
`malicious computer operations is accessed and consulted by scanner 150, in order to detect
`
`malicious computer operations.
`
`[0035] At step 230 a determination is made whether or not suspicious computer
`
`operations have been detected in the downloadable. If not, then the downloadable is
`
`deemed safe and is forwarded to its destination at step 240. Otherwise, if one or more
`
`suspicious computer operations have been detected, then at step 250 monitoring program
`
`code is appended to the original downloadable. Referring to the example above, the
`
`monitoring code includes lines 1 l — 36, and has two functions; namely,
`
`makeVulnObjDict(arr) and checkAcx(acxld).
`
`[003 6]
`
`At line 21 the function mal<eVulnObjDict() is called with array parameter
`
`OOOO12
`
`10
`
`000012
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CON1
`
`VulnAcxStruct[] , to build a dictionary, Vuln_Obj_Dict, ofpotentially malicious function
`
`calls. As seen at lines 6 — 9, VulnAcxStruct[] is an array ofthree-element arrays, each
`
`three-element array corresponding to a potentially malicious function. For purposes of
`
`clarity, only one three-element array is defined in lines 6 — 9, corresponding to the
`
`method setRequestHeader() of object Msxml2.XMLHTTP, but it will be appreciated by
`
`those skilled in the art that additional three-element arrays may be defined. The first
`
`element of the three-element array in VulnAcxStruct[] is the name of the object
`
`containing the potentially malicious function; i.e. "Msxml2.XMLHTTP". The second
`
`element of this array is the name of the suspicious method, setRequestHeader(),
`
`together with the function to be used for input validation of the method; namely,
`
`function()
`{
`
`all0W = ["GET", "POST", "HEAD", "DELETE", "PUT",
`
`"CONNECT", "OPTIONS"];
`
`for (i in alloW){
`
`if(arguments[0]==alloW[i] return;
`
`} a
`
`lert("malicious! ")
`
`} T
`
`hus to validate input parameters for the method setRequestHeader(), the input
`
`parameter is matched against six expected non-malicious parameter values GET,
`
`POST, HEAD, DELETE, PUT, CONNECT and OPTIONS. If no match is found then
`
`an alert is made.
`
`It will be appreciated by those skilled in the art that the function given
`
`above is but one of many methods for validating input parameters. Other such methods
`
`to validate input parameters and to issue a notification when input parameters are not
`
`validated, are also Within the scope of the present invention.
`
`[0037]
`
`The third element of the three-element array in VulnAcxStruct[], shown
`
`empty at line 9, is reserved for a definition of vulnerable properties. In summary form,
`
`VulnAcxStruct[] holds a list of vulnerabilities, Where a "vulnerability" is of the form
`
`000013
`
`11
`
`000013
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`[object name, list of [method name, definition], properties].
`
`[0038]
`
`Referring back to FIG. 2, at step 260 the suspicious computer operations
`
`are overwritten. Referring to the example JavaScript, the over-writing is performed at
`
`lines 29 and 30. Specifically, lines 28- 31 loop over the list of [method name,
`
`definition] and associate each method name with its corresponding definition.
`
`[0039]
`
`In addition, at line 38 the function window.ActiveXObject() is overwritten
`
`by the function checkAcx(). As such, instead of invoking ActiveXObject() during run- time
`
`when an ActiveX object is created, the function checkAcx() is invoked.
`
`[0040]
`
`Subsequently the modified downloadable is executed. At step 270 the input
`
`parameters for each of the suspicious computer operations are validated during run-time.
`
`Referring to the example code, the function checkAcx(), defined at lines 23 — 36, performs
`
`the validation. Specifically, if the ActiveX object to be created, as identified by acxld, is
`
`listed in the dictionary Vuln_Obj_Dict[], then the corresponding input validation function
`
`is performed. Ifthe validation fails, then the call to alert("malicious!") is made.
`
`Otherwise, the desired ActiveX object is created and returned.
`
`It will be appreciated by
`
`those skilled in the art that other forms of notification of failed validation are within the
`
`scope of the present invention. For example, checkAcx() may generate a warning text
`
`message.
`
`[0041]
`
`For the example provided above, when the input parameter
`
`"SSSSSSSSSSSSSSSSSSSSSS" to setRequestHeader() is validated, the validation fails
`
`since the input parameter does not match any of the expected input parameters GET,
`
`POST, HEAD, DELETE, PUT, CONNECT and OPTIONS. If the input parameter to
`
`setRequestHeader() had instead been valid, the desired ActiveX object,
`
`Msxml2.XMLHTTP, would have been created by checkAcx() and returned.
`
`[0042]
`
`At step 280 a determination is made whether or not the input parameters to
`
`each of the suspicious computer operations have been validated.
`
`If so, then the
`
`000014
`
`12
`
`000014
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`downloadable is deemed safe and is forwarded to its destination at step 240. Otherwise,
`
`the downloadable is deemed suspicious, an alert is made, and various preventive actions
`
`may be taken. One such action, at step 291, is simply not to forward the downloadable to
`
`the destination computer. Another such action, at step 292, is to neutralize the input
`
`parameters that were not validated, by replacing them with valid input parameters, and
`
`then forwarding the remedied downloadable to the destination computer. Another such
`
`action, at step 293, is to consult a computer security policy to determine whether or not to
`
`forward the downloadable to the destination computer, based on the suspicious computer
`
`operations that were detected.
`
`[0043]
`
`It will be appreciated by those skilled in the art that step 260, of overwriting
`
`suspicious computer operations may be performed either in a pre-scan phase, prior to
`
`executing the loop around step 270, as indicated in FIG. 2, or instead may be performed
`
`in real-time, within the loop. Specifically, referring to the example JavaScript code
`
`provided hereinabove, the structure VulnAcxStruct[], defined at lines 6 - 9, which pre-
`
`identifies the suspicious computer operations, may be appended to the monitoring code.
`
`In turn, the monitoring code overwrites the pre- identified operations in real-time at lines
`
`29 and 30.
`
`In this regard, reference is now made to FIG. 3, which is an alternative
`
`method for computer security with input parameter validation, with the overwriting being
`
`performed during run-time, in accordance with an embodiment of the present invention.
`
`[0044]
`
`FIG. 3 begins at step 310, whereat an original downloadable is received in
`
`transit to one or more destination computers. At step 350 monitoring program code is
`
`appended to the original downloadable, to generate a modified downloadable.
`
`[0045]
`
`Subsequent to step 350 the modified downloadable is executed. At step 355
`
`suspicious computer operations are identified at run-time. Step 355 may be performed by
`
`referencing a structure, such as the VulnAcxStruct[] structure in the example JavaScript,
`
`that lists pre-designated suspicious computer operations. Alternatively, step 355 may be
`
`000015
`
`13
`
`000015
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CON1
`
`performed by referencing a structure that lists pre-designated non-malicious computer
`
`operations.
`
`[0046]
`
`At step 360 the suspicious computer operations are overwritten at run-
`
`time. Referring to the example JavaScript, at lines 29 and 30 the object method
`
`obj [Vuln_Obj_Dict[acxId][0][i][0]]
`
`is overwritten with the function
`
`obj [Vuln_ Obj_Dict[acxId][0] [i] [1 ]].
`
`Based on lines 15 and 16, this corresponds to overwriting the method setRequestHeader()
`
`ofobj ect Msxmk2.XMLHTTP with the function in lines 7- 9; namely,
`
`function()
`{
`
`allow = [“GET“, “POST“, "HEAD“, "DELETE“, "PUT",
`"CONNECT", "OPTIONS"];
`
`for (i in allow){
`if(arguments[0]==allow[i] return;
`
`} a
`
`lert("malicious! ")
`
`} [
`
`0047]
`
`At step 370 the input parameters for the suspicious computer operations are
`
`validated at run-time. Referring to the JavaScript example, input parameter validation is
`
`performed by the function in lines 7- 9. If the input parameters are validated then the
`
`function returns normally; otherwise, the function invokes alert("malicious!"). Other such
`
`methods to validate input parameters and to issue a notification when input parameters are
`
`not validated, are also within the scope of the present invention.
`
`[0048]
`
`At step 380 a determination is made whether or not the input parameters to each
`
`of the suspicious computer operations have been validated. If so, then the downloadable is
`
`deemed safe and is forwarded to its destination at step 340. Otherwise, the downloadable
`
`is deemed malicious, an alert is made, and various preventive actions may be taken. One
`
`such action, at step 391, is simply not to forward the downloadable to the destination
`
`computer. Another such action, at step 392, is to neutralize the input parameters that were
`
`000016
`
`14
`
`000016
`
`

`
`Attorney Docket No. FIN0009-CIP 1 -CON1
`
`not validated, by replacing them with valid input parameters, and then forwarding the
`
`remedied downloadable to the destination computer. Another such action, at step 393, is
`
`to consult a computer security policy to determine whether or not to forward the
`
`downloadable to the destination computer, based on the suspicious computer operations
`
`that were detected.
`
`[0049]
`
`In the foregoing specification, the invention has been described with reference to
`
`specific exemplary embodiments thereof It will, however, be evident that various
`
`modifications and changes may be made to the specific exemplary embodiments without
`
`departing from the broader spirit and scope of the invention as set forth in the appended
`
`claims. Accordingly, the specification and drawings are to be regarded in an illustrative
`
`rather than a restrictive sense.
`
`OOOO17
`
`15
`
`000017
`
`

`
`Attorney Docket No. FIN0009-CIP l -CONl
`
`WE CLAIM:
`
`l.
`
`A computer-based method for identifying suspicious downloadables, comprising:
`
`receiving, by a receiving computer, a downloadable;
`
`scanning, by the receiving computer, the downloadable to detect the presence of
`
`suspicious computer operations;
`
`if at least one suspicious computer operation is detected by said scanning, appending,
`
`by the receiving computer, monitoring program code to the downloadable thereby generating a
`
`modified downloadable, wherein the monitoring program code includes a dictionary of objects
`
`including for each object at least one name of a suspicious object meth