Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-8, 10-19 and 35 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Shukla (US PG-PUB No. 20210099483 A1).
Regarding claim 1, 18 and 35, Shukla teaches a method, system and computer program product, the method comprising: determining whether a request to a web-based application running at a server is potentially harmful by inspecting the request, and interpretations of the request by the web-based application; if the request of the web-based application is potentially harmful, issuing a protection action to the web-based application (Paragraph [0011]: “In one aspect, a method for preventing attacks on a web application server (determining whether a request to a web-based application running at a server is harmful or attack) by monitoring and validating the API calls (by inspecting the request and interpretations of the request) executed by the dynamic language code of web application (by the web-based application) is provided. The method includes the step of inserting hooks for monitoring incoming requests and API calls executed by the web application server. The method includes the step of inserting validation code that validates the API calls executed by the dynamic language code in a script file by matching them against a rule set for that script file. The validation code checking conformity of the API call's event with the rule set for the script as determined by the mapping. The validation code applies a dynamic validation method if a matching rule is not found. The validation code takes a default action when a rule violation is detected for an event associated with an API call during the execution of the dynamic language code (if the request of the web-based application is potentially harmful, issuing a protection action to the web-based application).”).
Regarding claim 2 and claim 19, Shukla teaches all of the features with respect to claim 1 and claim 18, as outlined above.
Shukla further teaches the method and system further comprising: determining whether an interpreter execution status that is potentially harmful if the request is successfully run by the application or unsuccessfully run; labeling the request as an attack if it is successfully run; labeling the request as a threat if it is unsuccessfully run (Paragraph [0069]: “An incoming http connection 310 (http request) to the web-application server 360 (the request is run by the application) gets mapped to its respective dynamic language code files or script files 320 330 (interpreter syntax). The execution of script files 320 330 results in API calls 340 (interpreter execution status). Normal execution of a script file will result in a specific API call list pattern. API calls made by the web application server 360 are validated 350 to ensure that any incorrect handling of the user input, which is part of the http request 310, has not resulted in attack via unauthorized API calls (determining whether an interpreter execution status that is potentially harmful, and labeling the request as an attack if it is successfully run by the application). When a vulnerability in the code of the script files 320 330 is exploited, however, the pattern of the API calls executed by the script files 320 330 will change. Validation of API calls 350 detects this change and makes it possible to detect and prevent the exploitation of vulnerabilities in the script files (labeling the request as a threat if it is unsuccessfully run, where the exploitation of vulnerabilities in the script files are threats).”).
Regarding claim 3, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches the method further comprising: determining whether an interpreter syntax in response status that is potentially harmful if the request is successfully run by the application or unsuccessfully run; labeling the request as an attack if it is successfully run; labeling the request as a threat if it is unsuccessfully run (Paragraph [0065]: “For the embodiment illustrated in FIG. 1, system 100 includes a web application server 150 that executes a set of script files 122 (interpreter syntax) whose vulnerabilities could be targeted and exploited by the attacker 110. The script files contain code that is interpreted and executed at run time by a software virtual machine or interpreter 124 in the web application server. In the memory 120 of the web application server 150 there executes an injection attack detection process 125 (determining whether an interpreter syntax in response status that is potentially harmful if the request is successfully run by the application or unsuccessfully run) whose role is to detect and prevent any attempts to exploit vulnerabilities in the dynamic language code executing on the web application server 150 by monitoring and validating API calls executed by said dynamic language code in the script file 122 (labeling the request as an attack if it is successfully run; labeling the request as a threat if it is unsuccessfully run). The validation process can be implemented as a service, application, DLL (dynamic-link library), kernel module, or hypervisor.”).
Regarding claim 4, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein the request is a user request (Paragraph [0069]: “FIG. 3 illustrates the processing of an incoming network connection 310 to a web application server 360 and the resulting API calls 340 to detect an attack. API calls made by the web application server 360 are validated 350 to ensure that any incorrect handling of the user input, which is part of the http request 310 (the request is a user request), has not resulted in attack via unauthorized API calls.”).
Regarding claim 5, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein determining whether the request is potentially harmful includes: determining that interpreter syntax is in the request and that user input is in the interpreter input (Paragraph [0005]: “SQL injection is perhaps the most common vulnerability in web applications that arises due to dynamic typing of variables. When an input from the user is used in constructing a SQL query that will be interpreted at runtime (interpreter syntax is in the request and that user input is in the interpreter input) then, in the absence of strict type checking, it becomes possible for a malicious user to modify the input to lead to execution of queries that were not intended. If the input is not verified, then execution of the malicious query can allow the attacker to view or corrupt the target database, and even to escalate privileges to compromise the hosting server.”; Paragraph [0077]: “The mechanism used in dynamic analysis is to remove the effect of any user input to the API call (user input is in the interpreter input, if user input in the interpreter input is found then the request is determined to be potentially harmful) to create rules that are free from influence by any attack. The user input may be received through a form, JSON, XML document, etc. It is then interpreted by the web application and can subsequently be used in the invocation of the API calls.”).
Regarding claim 6, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches the method further comprising hijacking a system call table of the server (Paragraph [0011]: “ The method includes the step of parsing all script files to identify API calls, the location of API calls, and arguments used in the API calls and storing them as rules. The method includes the step of inserting hooks for monitoring incoming requests and API calls executed by the web application server (hijacking a system call table of the server).”).
Regarding claim 7, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches the method further comprising: analyzing at least one of arguments and return value of system calls being traced by the server (Paragraph [0012]: “The method includes the step of obtaining the argument names used in the API call. The method includes the step of building a parse tree for the script file and use a tree parser to determine the value of arguments used in the API call (analyzing at least one of arguments and return value of system calls being traced by the server).”).
Regarding claim 8, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein the determining step occurs in a modified system call table in a kernel of an operating system, the system call table running with preemption enabled (Paragraph [0035]: “Hooking can be used to alter or augment the behavior of an operating system, of applications, or of other software components by intercepting function calls or messages or events passed between software components (determining step occurs in a modified system call table in a kernel of an operating system).”; Paragraph [0036]: “Seccomp (secure computing mode) is a computer security facility in the Linux kernel. Seccomp allows a process to make a one-way transition into a “secure” state where it cannot make any system calls except exit( ), sigreturn( ), read( ) and write( ) to already-open file descriptors. Should it attempt any other system calls, the kernel can terminate the process with SIGKILL or SIGSYS (the system call table running with preemption enabled).”).
Regarding claim 10, Shukla teaches all of the features with respect to claim 8, as outlined above.
Shukla further teaches wherein the modified system call can be applied to multiple distributions and versions of any operating system (Paragraph [0011]: “The method includes the step of inserting hooks (modified system call) for monitoring incoming requests and API calls executed by the web application server.”; Paragraph [0035]: “Hooking can be used to alter or augment the behavior of an operating system, of applications, or of other software components by intercepting function calls or messages or events passed between software components (modified system call can be applied to multiple distributions and versions of any operating system).”).
Regarding claim 11, Shukla teaches all of the features with respect to claim 8, as outlined above.
Shukla further teaches wherein injected code of any size can be detected by the modified system call table (Paragraph [0004]: “This vulnerability of the unserialize( ) function has, in fact, been used to execute PHP object injection attacks (injected code of any size can be detected by the modified system call table). Similarly, the JSON (JavaScript Object Notation) parser for the Ruby on Rails web-application framework was found to be vulnerable to injection of malicious objects.”).
Regarding claim 12, Shukla teaches all of the features with respect to claim 8, as outlined above.
Shukla further teaches wherein the determining and issuing steps are performed within the kernel (Paragraph [0036]: “Seccomp (secure computing mode) is a computer security facility in the Linux kernel (the determining and issuing steps are performed within the kernel). Seccomp allows a process to make a one-way transition into a “secure” state where it cannot make any system calls except exit( ), sigreturn( ), read( ) and write( ) to already-open file descriptors. Should it attempt any other system calls, the kernel can terminate the process with SIGKILL or SIGSYS.”).
Regarding claim13, Shukla teaches all of the features with respect to claim 12, as outlined above.
Shukla further teaches wherein the steps being performed within the kernel avoids context switching or waiting for a response from user space (Paragraph [0040]: “A method and system are provided for a technique for deterministically validating API function calls to prevent attacks on web applications resulting from improper handling of inputs. The deterministic approach for validating the API function calls ensures that user input is not a factor (avoids waiting for a response from user space).”).
Regarding claim 14, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches the method further comprising: receiving the request over a network from a user system; and after the determination, responding to the request to the user system (Paragraph [0069]: “FIG. 3 illustrates the processing of an incoming network connection 310 (receiving the request over a network from a user system) to a web application server 360 and the resulting API calls 340 to detect an attack.” In FIG. 3, http response 370 is the responding to the request to the user system after the determination of the attack detection.).
Regarding claim 15, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein the interpreter is a logical program (Paragraph [0003]: “Modern web applications can be built using dynamic languages (e.g. PHP, Python, Java, JavaScript, etc.) (Interpreters are dynamic languages which are logical programs) whose instructions are interpreted at runtime. Interpreters may be easier to develop than compilers.”).
Regarding claim 16, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein the protection action is a mitigation measure such as stopping the request from being run at the user system, stopping the user request from being run in the server, denying the user request from read access to a database, and/or denying the user request from write access to a database (Paragraph [0072]: “The default action (protection action) could be permitting the API call, when the event passes validation, or denying the API call when the event fails validation(denying the user request, the user request can be read and write access to a database). The default action could be to log the event indicating presence of an attack.”; Paragraph [0085]: “The default action (protection action or mitigation measure) could be terminating the web request, preventing the API call, shutting down the web application (stopping the request from being run at the user system, stopping the user request from being run in the server), etc.”).
Regarding claim 17, Shukla teaches all of the features with respect to claim 1, as outlined above.
Shukla further teaches wherein the request is potentially harmful if data in the request is turned into code by the web-based application (Paragraph [0004]: “Since these same functions can also lead to execution of system commands, by carefully crafting the input data to the dynamic language code (data in the request is turned into code by the web-based application), an attacker can steer the interpreter to remotely execute commands or code on the device that would lead to a compromise (the request is potentially harmful).”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Shukla (US PG-PUB No. 20210099483 A1) in view of Kanade (US PG-PUB No. 20050066149 A1).
Regarding claim 9, Shukla teaches all of the features with respect to claim 8, as outlined above.
Shukla fails to explicitly teach, but Kanade teaches wherein preemption being enabled further enables use of semaphores, allocating large amounts of memory, processing input-output to make the code dynamic and protect critical sections (Paragraph [0040]: “FIG. 2A schematically illustrates the standard thread running service of the operating system. Standard thread running service 116 provides a preemption service 202 that enables thread preemption calls (preemption being enabled in the operating system). Preemptive services 204 include various services like inter-thread communication and synchronization mechanisms 208 using semaphores (preemption enables use of semaphores), mutexes or mailboxes. Preemptive services 204 are enabled through preemption service 202. Using these services, a thread can wait for a signal or data from another thread. While the signal or data does not appear, the thread is swapped out of the processor, so that the processor resource may be utilized by another thread (the thread is swapped out of the processor to allocate large amounts of memory and protect critical sections).” Paragraph [0041]: “Another class of preemptive services is file and input/output (I/O) services 210 (preemption enables processing input-output to make the code dynamic) wherein access to a resource is governed by a set of criteria. Examples of these criteria include elapsed time for using a resource, priority of task and the like.”; Paragraph [0059]: “The overall memory requirement is reduced. This functionality can be used to free up local memory for other important purposes (allocate large amounts of memory).”).
Shukla and Kanade are both considered to be analogous to the claimed invention because they both teach a method which system call running with preemption enabled. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method disclosed by Shukla with adding use of semaphores and allocating large amounts of memory disclosed by Kanade.
One of the ordinary skills in the art would have been motivated to make this modification in order to give priority to urgent tasks by using preemption and free the local memory for other important purposes, as suggested by Kanade in paragraph [0016].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (see PTO-892 form for details)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.M.D./ Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499