`Ji
`
`54) COMPUTER NETWORK MALICIOUS CODE
`SCANNER
`
`75 Inventor: Shuang Ji, Santa Clara, Calif.
`73 Assignee: Trend Micro Incorporated, Cupertino,
`Calif.
`
`21 Appl. No.: 08/926,619
`1-1.
`22 Filed:
`Sep. 10, 1997
`(51) Int. Cl." ...................................................... G06F 13/00
`52 U.S. Cl. ............................................... 713/200; 714/38
`58) Field of Search
`395/186, 187.01
`395 issol,183.14,183.13 20054. 20055.
`2OO 33. 3803, 4, 23 25. 713,300 201.
`•-1 as
`s
`is a-s 202. 714/3s 3.
`s
`s
`
`56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,257,381 10/1993 Cook ....................................... 395/700
`5,359,659 10/1994 Rosenthal .................................... 380/4
`
`USOO5983348A
`Patent Number:
`11
`(45) Date of Patent:
`
`5,983,348
`Nov. 9, 1999
`
`5,390,232 2/1995 Freeman et al. .......................... 379/15
`5,623,600 4/1997 Ji et al. ...........
`... 395/187.01
`5,805,829 9/1998 Cohen et al. ...................... 395/200.32
`
`Primary Examiner Norman Michael Wright
`Attorney, Agent, or Firm-Skjerven, Morrill MacPherson,
`Franklin & Friel LLP, Norman R. Klivans
`57
`ABSTRACT
`57
`A network Scanner for Security checking of application
`programs (e.g. Java applets or Active X controls) received
`over the Internet or an Intranet has both static (pre-run time)
`and dynamic (run time) scanning. Static scanning at the
`HTTP proxy server identifies suspicious instructions and
`instruments them e.g. a pre-and-post filter instruction
`Sequence or otherwise. The instrumented applet is then
`transferred to the client (web browser) together with security
`monitoring code. During run time at the client, the instru
`mented instructions are thereby monitored for Security
`policy violations, and execution of an instruction is pre
`vented in the event of Such a violation.
`
`34 Claims, 2 Drawing Sheets
`
`Applet
`
`Prefetcher
`JAR
`
`-3
`
`
`
`Securing Policy
`Generator
`
`Verify Signature
`
`40
`
`54
`
`Monitoring
`Pockoge
`
`42
`
`
`
`COSS fles
`
`CoSS files
`
`Signer
`
`50
`
`58
`
`SCOnner
`
`- 26
`
`Juniper Ex. 1005-p. 1
`Juniper v Finjan
`
`
`
`U.S. Patent
`
`Nov. 9, 1999
`
`Sheet 1 of 2
`
`5,983,348
`
`Server Mochine
`
`
`
`HTTP Proxy Server
`
`26
`
`
`
`T. F.
`
`
`
`10
`
`Client MOChine
`
`
`
`
`
`
`
`
`
`50
`
`FIC 1
`
`Juniper Ex. 1005-p. 2
`Juniper v Finjan
`
`
`
`U.S. Patent
`
`Nov. 9, 1999
`
`Sheet 2 of 2
`
`5,983,348
`
`Applet
`
`Securing Policy
`Generotor
`
`
`
`54
`
`Monitoring
`Pockage
`
`Prefetcher
`JAR
`
`Verify Signoture
`
`|-
`
`COSS files
`
`COSS files
`
`Instrumenter
`T
`
`
`
`
`
`
`
`26
`
`SCOnner
`
`cent
`
`-14
`
`FIC. 2
`
`Juniper Ex. 1005-p. 3
`Juniper v Finjan
`
`
`
`5,983,348
`
`15
`
`25
`
`35
`
`40
`
`1
`COMPUTER NETWORK MALICIOUS CODE
`SCANNER
`FIELD OF THE INVENTION
`This invention pertains to computer networks and Spe
`cifically to detecting and preventing operation of computer
`Viruses and other types of malicious computer code.
`BACKGROUND
`With the rapid development of the Internet, Intranet, and
`network computing, applications (application programs) are
`distributed more and more via Such networks, instead of Via
`physical Storage media. Many associated distribution tech
`nologies are available, Such as Java and Active X. Therefore
`objects with both data and code flow around the network and
`have Seamless integration with local computer resources.
`However, this also poses a great Security risk to users. Code
`(Software) from unknown origin is thereby executed on local
`computers and given access to local resources Such as the
`hard disk drive in a user's computer. In a world wide web
`browser environment, Such code is often automatically
`executed and the user might not even have a chance to be
`forewarned about any Security risks (e.g. presence of com
`puter viruses) he bears. Attempts have been made to reduce
`such risks; see Ji et al., U.S. Pat. No. 5,623,600, incorporated
`by reference in its entirety.
`Active X technology, like Java, distributes code that can
`access local System resources directly. The web browser
`cannot monitor or block Such accesses. Such an applet
`(application) can do Virtually anything that a conventional
`program, for instance, a virus, is capable of doing. MicroSoft
`Corp. and others have attempted to address this problem by
`using digital signature technology, whereby a special algo
`rithm generates a digital profile of the applet. The profile is
`attached to the applet. When an applet is downloaded from
`the Internet, a verification algorithm is run on the applet and
`the digital profile to ensure that the applet code has not been
`modified after the Signing. If an applet is signed by a known
`Signature, it is considered Safe.
`However, no analysis of the code is done to check the
`behavior of the applet. It is not difficult to obtain a signature
`from a reputable Source, Since the Signature can be applied
`for online. It has occurred that a perSon has created an Active
`X applet that was authenticated by Microsoft but contains
`malicious code. (Malicious code refers to viruses and other
`problematic Software. A virus is a program intended to
`replicate and damage operation of a computer System with
`out the user's knowledge or permission. In the Internet/Java
`environment, the replication aspect may not be present,
`hence the term “malicious code” broadly referring to such
`damaging Software even if it does not replicate.)
`Java being an interpreted language, Java code can be
`monitored at run-time. Most web browsers block attempts to
`access local resources by Java applets, which protects the
`local computer to a certain extent. However, as the popu
`larity of Intranets (private Internets) increases, more and
`more applets need to have access to local computers. Such
`restrictions posed by the web browsers are becoming rather
`inconvenient. As a result, web browsers are relaxing their
`Security policies. Netscape Communicator is a web browser
`that now gives users the ability to Selectively run applets
`with known Security risks. Again, decisions are made based
`on trust, with no code analysis done.
`Hence Scanning programs with the ability to analyze and
`monitor applets are in need to protect users.
`At least three Java applet Scanners are currently available
`commercially: SurfinShield and SurfinGate, both from
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Finjan, and Cage from Digitivity, Inc. SurfinShield is a
`client-side (user) solution. A copy of SurfinShield must be
`installed on every computer which is running a web browser.
`SurfinShield replaces some of the Java library functions
`included in the browser that may pose Security risks with its
`own. This way, it can trap all Such calls and block them if
`neceSSary.
`SurfinShield provides run-time monitoring. It introduces
`almost no performance overhead on applet Startup and
`execution. It is able to trap all Security breach attempts, if a
`correct Set of Java library functions is replaced. However, it
`is still difficult to keep track of the states of individual
`applets if a Series of actions must be performed by the
`instances before they can be determined dangerous this way,
`because the Scanner is activated rather passively by the
`applets.
`Since every computer in an organization needs a copy of
`the SurfinShield software, it is expensive to deploy. Also,
`installing a new release of the product involves updating on
`every computer, imposing a significant administrative bur
`den.
`Because SurfinShield replaces library functions of
`browsers, it is also browser-dependent; a minor browser
`upgrade may prevent operation. SufinCate is a Server Solu
`tion that is installed on an HTTP proxy server. Therefore,
`one copy of the Software can protect all the computers
`proxied by that server. Unlike SufinShield, SurfinGate only
`Scans the applet code Statically. If it detects that one or more
`insecure functions might be called during the execution of
`the applet, it blocks the applet. Its Scanning algorithm is
`rather slow. To solve this problem, SurfinCate maintains an
`applet profile database. Each applet is given an ID which is
`its URL. Once an applet is Scanned, an entry is added to the
`database with its applet ID and the insecure functions it
`might try to access. When this applet is downloaded again,
`the Security profile is taken from the database to determine
`the behavior of the applet. No analysis is redone. This means
`that if a previously safe applet is modified and Still has the
`same URL, SurfinGate will fail to rescan it and let it pass
`through. Also, because the size of the database is ever
`growing, its maintenance becomes a problem over time.
`Cage is also a server solution that is installed on an HTTP
`proxy server, and provides run-time monitoring and yet
`avoids client-side installations or changes. It is similar to X
`Windows. All workstations protected by the server serve as
`X terminals and only provide graphical presentation func
`tionality. When an applet is downloaded to Cage, it stops at
`the Cage server and only a GUI (graphical user interface)
`agent in the form of an applet is passed back to the browser.
`The applet is then run on the Cage Server. GUI requests are
`passed to the agent on the client, which draws the presen
`tation for the user. Therefore, it appears to users that the
`applets are actually running locally.
`This approach creates a heavy load on the Server, Since all
`the applets in the protected domain run on the Server and all
`the potentially powerful computers are used as graphical
`terminals only. Also, reasonable requests to access local
`resources (as in Intranet applications) are almost impossible
`to honor because the Server does not have direct access to
`resources on individual WorkStations.
`These products fail to create any balance between Static
`Scanning and run-time monitoring. SurfinShield employs
`run-time monitoring, SurfinGate uses Static Scanning, and
`Cage utilizes emulated run-time monitoring. Since Static
`Scanning is usually done on the Server and run-time moni
`toring on the client, this imbalance also causes an imbalance
`
`Juniper Ex. 1005-p. 4
`Juniper v Finjan
`
`
`
`3
`between the load of the server and the client. To distribute
`the load between the client and the Server evenly, the present
`inventor has determined that a combination of Static Scan
`ning and run-time monitoring is needed.
`
`SUMMARY
`This disclosure is directed to an applet Scanner that runs
`e.g. as an HTTP proxy server and does not require any
`client-side modification. The Scanner combines Static Scan
`ning and run-time monitoring and does not cause a heavy
`load on the Server. It also does not introduce significant
`performance overhead during the execution of applets. The
`Scanner provides configurable Security policy functionality,
`and can be deployed as a client-side Solution with appro
`priate modifications.
`Thereby in accordance with the invention a Scanner (for
`a virus or other malicious code) provides both Static and
`dynamic Scanning for application programs, e.g. Java
`applets or ActiveX controls. The applets or controls
`(hereinafter collectively referred to as applets) are conven
`tionally received from e.g. the Internet or an Intranet at a
`conventional Server. At this point the applets are Statically
`Scanned at the Server by the Scanner looking for particular
`instructions which may be problematic in a Security context.
`The identified problematic instructions are then each
`instrumented, e.g. Special code is inserted before and after
`each problematic instruction, where the Special code calls
`respectively a prefilter and a post filter. Alternatively, the
`instrumentation involves replacing the problematic instruc
`tion with another instruction which calls a Supplied function.
`The instrumented applet is then downloaded from the
`server to the client (local computer), at which time the applet
`code is conventionally interpreted by the client web browser
`and it begins to be executed. AS the applet code is executed,
`each instrumented instruction is monitored by the web
`browser using a monitor package which is part of the
`Scanner and delivered to the client Side. Upon execution,
`each instrumented instruction is Subject to a Security check.
`If the security policy (which has been pre-established) is
`Violated, that particular instruction which violates the Secu
`rity policy is not executed, and instead a report is made and
`execution continues, if appropriate, with the next instruc
`tion.
`More broadly, the present invention is directed to deliv
`ering what is referred to as a “live agent” (e.g., a Security
`monitoring package) along with e.g. an applet that contains
`Suspicious instructions during a network transfer (e.g. down
`loading to a client), the monitoring package being intended
`to prevent execution of the Suspicious instructions. The
`Suspicious instructions each may (or may not) be instru
`mented as described above; the instrumentation involves
`altering Suspicious instructions Such as by adding code (Such
`as the pre-and post-filter calls) or altering the Suspicious
`instructions by replacing any Suspicious instructions with
`other instructions.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows diagramatically use of a Scanner in accor
`dance with this invention.
`FIG. 2 shows detail of the FIG. 1 scanner.
`
`DETAILED DESCRIPTION
`Several characteristics of the well known Java language
`and applets are pertinent to the present Scanning method and
`apparatus. Java is an interpreted, dynamic-linking language.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,983,348
`
`4
`Only the application modules are distributed, and all the
`Standard library functions are provided by the interpreter, for
`instance a web browser. Because Java byte code is platform
`independent, applets have to use Some of the Standard library
`functions to access operating System resources.
`This creates two opportunities in accordance with the
`invention to detect attempts to use operating System
`resources. First, one can “trick’ applets into calling particu
`lar functions Supplied by the Scanner during the dynamic
`linking Stage. This is done by replacing the browser Java
`library routines with the Scanner's monitoring routines of the
`Same name. Second, Since invocations of Such functions
`have to be resolved at run-time, Symbolic names of these
`functions are kept in the Java applet module. The Scanner
`can detect possible use of these functions by looking at the
`Static code itself. The first opportunity provides run-time
`monitoring. It is the most definitive method to determine the
`Security risks posed by an applet.
`The Second opportunity enables Statically Scanning an
`applet, without running it, to detect possible Security riskS.
`If a Set of insecure functions is properly defined and an
`applet never calls any function in the Set, the applet can be
`assumed to be Safe. However, this Static Scanning method is
`not definitive, Since an applet might show different behavior
`given different user input. Under certain conditions, the
`instruction in the applet that makes the function call may
`never be executed. If Static Scanning is used without run
`time monitoring, many Such "false alarms of Security risks
`are produced undesirably.
`After the code of an applet is downloaded, e.g. via the
`Internet to a client platform (local computer), an instance of
`the applet is created in the conventional Java “virtual
`machine” in the web browser (client) running on that local
`computer. Different instances of the same applet might
`produce different results given different inputs. A running
`instance of an applet is conventionally called a Session;
`Sessions are Strictly run-time entities. Static Scanning cannot
`analyze Sessions because Static Scanning does not let the
`applet run. Sessions are important because an instance of an
`applet will often perform a Series of Suspicious tasks before
`it can be determined dangerous (i.e., in violation of the
`Security policy). Such state information needs to be associ
`ated with the Sessions. The present applet Scanner thereby
`StopS Sessions instead of blocking execution of the entire
`applet.
`A Security policy defines what functions an applet needs
`to perform to be considered a Security risk. Examples of
`Security policies include preventing(1) applets from any file
`access, or (2) file access in a certain directory, or (3) creating
`certain Java objects. An applet Scanner in accordance with
`the invention may allow different security policies for dif
`ferent clients, for different users, and for applets from
`different origins.
`FIG. 1 is a high level block diagram illustrating the
`present Scanner in the context of conventional elements. The
`Internet (or an Intranet) is shown generally at 10. The client
`machine or platform (computer) 14, which is typically a
`personal computer, is connected to the Internet 10 via a
`conventional proxy server machine (computer) 20. Client
`machine 14 also includes local resources 30, e.g. files Stored
`on a disk drive. A conventional web browser 22 is Software
`that is installed on the client machine 14. It is to be
`understood that each of these elements is complex, but
`except for the presently disclosed features is conventional.
`Upon receipt of a particular Java applet, the HTTP proxy
`server 32, which is software running on server machine 20
`
`Juniper Ex. 1005-p. 5
`Juniper v Finjan
`
`
`
`5,983,348
`
`6
`-continued
`
`else
`
`output the original instruction;
`
`1O
`
`Examples of pre- and post-monitor functions are:
`(1) to disallow any directory listing access:
`
`S
`and which has associated Scanner Software 26, then Scans the
`applet and instruments it using an instrumenter 28 which is
`part of the Scanner Software 26. (Downloaded non-applets
`are not scanned.) The instrumented applet is Subject to a
`Special digital signer which is an (optional) part of the
`Scanner 26. The Scanned (instrumented) applet, which has
`been digitally signed is then downloaded to the web browser
`22 in the client 14. The applet is then conventionally
`interpreted by the web browser 22 and its instructions are
`executed. The execution is monitored by the monitor pack
`age Software, also downloaded from Scanner 26, in the web
`browser 22 in accordance with this invention for security
`purposes. Thus static scanning is performed by the HTTP
`proxy Server 32 and dynamic Scanning by the web browser
`22.
`The present applet Scanner thus uses applet instrumenta
`tion technology, that is, for Java applets it alters the Java
`applet byte code Sequence during downloading of the applet
`to the Server 32. After the Java applet byte code Sequence has
`been downloaded, the Static (pre-run time) Scanning is
`performed on the applet by the Scanner 26. If an instruction
`(a Suspicious instruction) that calls an insecure function (as
`determined by a predefined set of Such functions) is found
`during this Static Scanning, a first instruction Sequence
`(pre-filter) is inserted before that instruction and a second
`instruction Sequence (post-filter) after that instruction by the
`instruments.
`An example of Such a Suspicious Java function is “Jav
`a.IO.File...list” which may list the contents of a client (local)
`directory 30, e.g. a directory on the client machine 14 hard
`disk drive. The first instruction Sequence generates a call to
`a pre-filter function provided by the Scanner 26, Signaling
`that an insecure (Suspicious) function is to be invoked. The
`pre-filter checks the Security policy associated with the
`Scanner 26 and decides whether this particular instruction
`("call’) is allowed. The Second instruction sequence gener
`ates a call to a post-filter function also provided by the
`Scanner. It also reports the result of the call to the post-filter
`function. Both the pre- and post-filter functions update the
`Session State to be used by the Security policy. The Static
`Scanning and instrumentation are both performed on the
`HTTP proxy server 32.
`The following is pseudo-code for the instrumentation
`proceSS:
`
`pre-filter(function name, parameters)
`
`if (function name == "java.io. File.list)
`throw new SecurityException();
`post-filter(result)
`
`(2) To protect files under c:\temp from directory listing
`CCCSS
`
`pre-filter(function name, parameters)
`
`(function name == "java.io. File.list)
`{
`extract the name of the file to be read from
`parameters;
`if the directory to be listed is under c\temp)
`throw new SecurityException();
`
`}
`post-filter(result)
`
`The pre and post filter and monitoring package Security
`policy functions) are combined with the instrumented applet
`code in a single JAR (Java archive) file format at the server
`32, and downloaded to the web browser 22 in client machine
`14. From this point on, the server 32 is virtually discon
`nected from this Server-client Session. All the monitoring
`and applet code is executed in the web browser 22 in the
`client machine 14. The only time that the server 32 may be
`again involved during this particular Session is when the
`applet is determined to be dangerous (i.e. including mali
`cious code that violates the Security policy) or the applet has
`completed execution, and a report is Sent back to the Server
`32 by the monitoring code in the Scanner 26. A report is
`optional in this Second case.
`This approach minimizes the overhead on both server 32
`and browser 14. The only work performed on the server 32
`is to identify Suspicious applet instructions and instrument
`them, which is usually performed by a one time pass over the
`applet code. To the client web browser 22, the only overhead
`is Some occasional calls to the Scanner monitoring functions,
`which update Session Statistics and check Security policies.
`This achieves an optimum distribution of Scanning and
`monitoring between the server 32 and the client web
`browser 22. Also, the Server 32 maintains no State informa
`tion about active Sessions in the Set of host associated with
`the proxy Server instead the Session State information is
`maintained locally at client machine 14 by the downloaded
`monitoring functions.
`This approach may damage the integrity of externally
`digitally signed (authenticated) applets, since the content of
`
`15
`
`25
`
`35
`
`40
`
`45
`
`instrument (JavaClassFile classfile)
`extract constant pool from classfile;
`extract functions from classfile;
`for each function
`
`for each function
`{
`if the instruction is a function call
`AND the target of the call is a pre-defined set
`of suspicious functions)
`{
`Output an instruction sequence which generates a
`function call to a pre-monitor function, with the
`name of the suspicious function, parameters to the
`suspicious function, and possibly other
`information about his suspicious function
`invocation as the parameters;
`Output the original instruction;
`Output an instruction sequence which generates a
`function call to a post-monitor function, with the
`result of the suspicious function invocation and
`possibly other related information as parameters;
`
`50
`
`55
`
`60
`
`65
`
`Juniper Ex. 1005-p. 6
`Juniper v Finjan
`
`
`
`5,983,348
`
`15
`
`25
`
`35
`
`40
`
`7
`the applets is changed by the instrumentation. However, this
`can also be used as an advantage because using the present
`Scanner, a new set of authenticated Signatures can be set and
`enforced for the entire domain as further described below.
`Operation of Scanner 26 and its various (Software) com
`ponents is better understood with reference to FIG. 2,
`showing greater detail than FIG. 1.
`An applet pre-fetcher component 38 fetches from the
`Internet 10 all the dependency files required by a Java class
`file, if they are not already packed into a JAR file. This is
`important because the goal is to attach the Scanner monitor
`package to a Session only once.
`A Java applet may contain more than one code module, or
`class file. Heretofore this disclosure has assumed that all the
`class files are packed in one JAR file and downloaded once.
`One monitoring package is attached to the JAR file and
`every instantiation of this package on the client web browser
`22 marks a unique Session. However, if the class files are not
`packed together and are downloaded on an as-needed basis
`during applet eXecution, multiple instrumentation will occur
`and multiple instances of the monitoring package for the
`Same Session are created on the client. This creates a
`problem of how to maintain information on Session States.
`To solve this problem, the pre-fetcher 38 pre-fetches the
`dependency class files during the Static Scanning of the main
`applet code module. The dependency class files are (see
`below) instrumented once, packed together, and delivered to
`the client.
`Upon receiving a (signed) applet, the Signal verifier
`component 40 then Verifies the Signature and its integrity, as
`conventional, to decide whether to accept this applet.
`Next, the unpacker 42 component extracts the class files
`from the JAR file. JAR uses ZIP (compression) format.
`Java class parser component 44 then parses each Java
`class file. Parser 44 conventionally extracts the instruction
`Sequence of the Java functions.
`The Java instrumenter component 48 instruments the Java
`class files, e.g. by inserting monitoring instructions (e.g. pre
`and post filter calls) before and after each Suspicious
`instruction, as described above.
`The monitor package contains monitoring functions that
`are delivered from the server 32 to the client web browser 22
`with the instrumental applet and are invoked by the instru
`mentation code in the applet. The monitor package also
`creates a unique Session upon instantiation. It also contains
`a Security policy checker (Supplied by Security policy gen
`erator component 54) to determine whether the applet being
`Scanned violates the Security policy, given the monitoring
`information.
`The Security policy generator component 54 generates the
`Security checker code included in the monitor package, from
`a Set of predefined Security policies. Different clients, users,
`and applets may have different Security policies. The Secu
`rity policy generator 54 may run on Server machine 20 or
`another computer. In addition, Security policies can be
`configured by an administrator of the System. A simple
`Security policy is to assign different weights to monitored
`functions and make Sure the Security weight of a Session
`does not exceed a preset threshold. A more Sophisticated
`Security policy checks the file or resource the applet is trying
`to access at run time and prompts the user whether to allow
`the access. Hence the Security policy broadly is a State
`machine to detect Security policy violations upon attempted
`instruction execution.
`The Security policy generator 54 can operate outside the
`run-time instrumenter component 48 when the Security
`policy is being created. The instrumenter component 48 can
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`then directly use the byte code. Thereby any performance
`limitations of the Security policy generator component 54
`become leSS important.
`Next, packer 50 creates a new JAR file (JAR) from the
`instrumented class files and the monitoring package.
`The digital signer component 58 digitally Signs the applet
`(now JAR"), with a digital signature unique to the particular
`Scanner 26, for authentication in the local domain. The
`applet JAR" is then transferred to the client machine 14 for
`execution. Thus the only signature that a client needs to
`recognize is the digital Signature of the Signer component 58
`in the Scanner 26. This pre-verification simplifies System
`administration and reduces risks to unsophisticated users
`who might otherwise accidentally accept applets with unau
`thorized signatures.
`In one embodiment, the components of Scanner 26 are
`each implemented in Java. Some (or all) of the functions
`(“components”) of the scanner 26 described above may be
`implemented in native (non-Java) code to improve perfor
`mance. The actual Scanner code is not given here; it can be
`readily written by one of ordinary skill in the art in light of
`this disclosure.
`This disclosure is illustrative and not limiting, further
`modifications will be apparent to one skilled in the art and
`are intended to fall within the Scope of the appended claims.
`I claim:
`1. A method of detecting and preventing execution of
`instructions in an application program provided from a
`computer network, comprising:
`providing the application program over the computer
`network,
`determining whether the provided application program
`includes any instructions that are members of a par
`ticular set of instructions,
`executing the application program if it is determined that
`no members of the Set are included in the application
`program,
`if it is determined that an instruction is a member of the
`Set, then altering the application program, thereby
`allowing monitoring of execution of the instruction,
`wherein the altering includes inserting a first predefined
`call before the instruction and a Second predefined call
`after the instruction; and
`wherein the first or Second predefined call changes a
`Session State of the application program.
`2. The method of claim 1, further comprising associating
`monitoring code with the application program.
`3. The method of claim 1, wherein the altering includes
`replacing the instruction with a predefined Second instruc
`tion.
`4. The method of claim 1, wherein the application pro
`gram is an applet.
`5. The method of claim 4, wherein the applet is in the Java
`language.
`6. The method of claim 1, wherein the computer network
`is an Intranet or the Internet.
`7. The method of claim 1 wherein the first predefined call
`is a call to check a Security policy.
`8. The method of claim 7, wherein the security policy is
`a State machine.
`9. The method of claim 1, wherein the inserting is
`repeated for each instruction in the application program that
`is a member of the particular Set.
`10. The method of claim 1, wherein the particular set of
`instructions includes instructions that access a predefined Set
`of files.
`
`Juniper Ex. 1005-p. 7
`Juniper v Finjan
`
`
`
`9
`11. The method of claim 1, wherein the computer network
`includes a Server and a client coupled to the Server, and
`wherein the altering takes place at the Server, wherein the
`executing the application program takes place at the client.
`12. The method of claim 1, wherein the instructions are
`problematic instructions.
`13. The method of claim 1, wherein the application
`program is altered at the point of the instruction.
`14. A method of detecting and preventing execution of
`instructions in an application program provided from a
`computer network comprising:
`providing the application program over the computer
`network;
`determining whether the provided application program
`includes any instructions that are members of a par
`ticular set of instructions,
`executing the application program if it is determined that
`no members of the Set are included in the application
`program,
`if it is determined that an instruction is a member of the
`Set, then altering the application program, thereby
`allowing monitoring of execution of the instruction;
`determining if the application program includes an
`authentication;
`Verifying the authentication; and
`replacing the verified authentication with a Second
`authentication.
`15. A method of detecting and preventing execution of
`instructions in an application program provided from a
`computer network, comprising:
`providing the application program over the computer
`network;
`determining whether the provided application program
`includes any instructions that are members of a par
`ticular set of instructions,
`executing the application program if it is determined that
`no members of the Set are included in the application
`program,
`if it is determined that an instruction is a member of the
`Set, then altering the application program, thereby
`allowing monitoring of execution of the instruction;
`providing all dependency files associated with the appli
`cation program;
`providing a single monitoring package performing the
`Step of determining for the application program and its
`asSociated dependency files, and
`executing the application program and its associated
`dependency files.
`16. A Scanner for detecting and preventing execution of
`instructions in an application program provided from a
`computer network, wherein the Scanner determines whether
`the provided application program includes any instructions
`that are members of a particular Set of instructions, allowing
`execution of the application program if it is determined that
`no members of the Set are included in th