An instrumentation engine for web applications to detect injected code

Abstract

It provides an instrumentation engine that is independent (i.e., agnostic) of the underlying framework implemented in the server. In one embodiment of the present invention, a method determines whether a request to a web-based application running on a server is potentially harmful by examining the request and the web-based application's interpretation of the request. If the request of the web-based application is potentially harmful, a protective action is issued to the web-based application. The protective action may be a countermeasure such as stopping the request from executing on a user system, and / or stopping a user request from executing on a server, and / or denying read access to a database for a user request, and / or denying write access to a database for a user request.

Description

[Technical field]

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 269,046, filed March 9, 2022.

[0002] This application claims priority under 35 U.S.C. Sections 119 and 365 of Indian Patent Application No. 202241001257, filed on January 10, 2022.

[0003] The entire teachings of the above application are incorporated herein by reference. [Background technology]

[0004] A user system may issue requests, e.g., TCP / UDP based requests, to a web-based application through a network, e.g., a private cloud and / or a public cloud and / or a data center, etc. Such requests contain user data and are processed by the web-based application, often performing a task on a server and returning data over the network to the user system. Summary of the Invention [Problem to be solved by the invention]

[0005] In some embodiments, the method determines whether a request to a web-based application running on a server is harmful (or potentially harmful) by examining the request and the web-based application's interpretation of the request. [Means for solving the problem]

[0006] For example, in one embodiment, it is determined whether an attacker has used crafted data in the request that, when turned into code by a vulnerable web-based application, will be executed as a malicious child process. In the method, if the request of the web-based application is potentially harmful, a protective action is issued against the web-based application. The protective action may be a countermeasure such as stopping the request from executing on a user system, and / or stopping a user request from executing on the server, and / or denying read access to a database for the user request, and / or denying write access to a database for the user request. In another embodiment, the countermeasure includes pushing security control code to a system used to send the request.

[0007] In some embodiments, the method further includes determining whether the application succeeds or fails to execute the request based on whether the execution status of an interpreter (such as any Living Off the Land Binary (LOLBIN) that allows a bad actor to execute malicious code) is potentially harmful. In one embodiment, the determination may be whether malicious data in the request is converted into code that results in a malicious operation. The method further includes labeling the request as an attack if the request is successful and labeling the request as a threat if the request is unsuccessful.

[0008] In some embodiments, the method further comprises determining whether execution of the request by the application succeeds or fails depending on whether an interpreter syntax status of a response is potentially harmful, and further comprising labeling the request as an attack if execution of the request is successful and labeling the request as a threat if execution of the request is unsuccessful.

[0009] In some embodiments, the request is a user request, such as an HTTP request, an end-user request, etc.

[0010] In some embodiments, in determining whether the request is potentially harmful, it is determined that interpreter syntax is present in the request and user input is present in interpreter input.

[0011] In some embodiments, the method further includes hijacking, i.e., hooking, the system call table of the server, such that in hijacking the system call table of the server, the system call table may be replaced with a system call table capable of executing security logic exposed to the web-based application, and optionally interacting with an analysis module to do so.

[0012] In some embodiments, the method further comprises analyzing arguments and / or return values ​​of system calls traced by the server.

[0013] In some embodiments, the determining step occurs in a modified system call table within the kernel of the operating system, the system call table being executed with preemption enabled.

[0014] In some embodiments, enabling preemption also enables (i) the use of semaphores, (ii) large amounts of memory allocation, (iii) handling input / output to make the code dynamic, and (iv) protecting critical sections.

[0015] In some embodiments, the modified system call table is applicable to multiple distributions and versions of any operating system.

[0016] In some embodiments, the modified system call table allows for detection of injected code of any size.

[0017] In some embodiments, the determining and issuing steps are performed within the kernel.

[0018] In some embodiments, processes executing within the kernel do not require context switching and do not need to wait for responses from user space.

[0019] In some embodiments, the method further includes receiving the request from a user system over a network, and after the determining, responding to the request to the user system.

[0020] In some embodiments, the interpreter is a logic program, such as a handler (that can invoke the interpreter), application-specific business logic, etc.

[0021] In one embodiment, the request is deemed potentially harmful if data in the request is converted into code by the web-based application. For example, in such an embodiment, a determination may be made that the malicious data in the request includes code and / or data whose syntax is treated as code by an interpreter or LOLBIN of the web-based application.

[0022] In some embodiments, the system includes a processor and a memory having computer code instructions stored thereon that are configured to cause the processor and the memory to perform a procedure for determining whether a request to a web-based application executing on a server is potentially harmful by inspecting the request and an interpretation of the request by the web-based application, and the processor is further configured to issue a protective action against the web-based application if the request of the web-based application is potentially harmful.

[0023] The foregoing will become apparent from the following more particular description of exemplary embodiments as illustrated in the accompanying drawings. The same reference numerals refer to the same structures / components throughout the different views. The drawings are not necessarily to scale, rather emphasis is placed upon illustrating the embodiments. [Brief description of the drawings]

[0024] [Figure 1] 1 is a block diagram illustrating some example embodiments of the present disclosure. [Diagram 2] FIG. 1 is a flow diagram illustrating an exemplary embodiment of the present disclosure. [Diagram 3] FIG. 1 illustrates one embodiment of a system call table implementation that provides the system with the methods described below. [Figure 4] FIG. 1 illustrates a digital processing environment, such as a computer network, in which embodiments of the present invention may be implemented. [Diagram 5] 5 illustrates an example of the internal structure of a computer (eg, a client processor / device or a server computer) in the computer system of FIG. 4. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] Exemplary embodiments are described below.

[0026] In a web-based application, a user connects to a server of the web-based application. Often, the web-based application creates a session (e.g., authentication, etc.) specific to the user at a per-user session layer. The session begins with a request, such as an HTTP request, which includes information such as an HTTP request line and headers (e.g., agreement between endpoints, browser or device type, return data, outgoing data, etc.). The request traverses the application, such as through an HTTP pipeline, and the server analyzes the request and executes logic to generate a downstream response. In various embodiments, the logic may be a SQL request.

[0027] Cyber ​​attacks that originate from outside the network (e.g., the Internet, the cloud, etc.) can be difficult to detect, i.e., to prevent. One reason for this difficulty is that web-based applications often generate bytecode in the system's local memory. By exploiting vulnerabilities in the logic of web-based applications, attackers can "generate" their own intended code directly into memory. For example, a SQL injection attack can force commands on business logic through user data. Therefore, it would be desirable to be able to distinguish between the attacker's intended code and the application's code.

[0028] Contextual instrumentation can be deployed at strategic points in the application framework to distinguish between attacker-intended code and application-intended code. This allows security controls to track the attacker's data as it is processed by the application's business logic and the corresponding code generated by the application. One indicator of a web attack is when the attacker's data contains one or more interpreter verbs (e.g., SQL verbs) used by the application's business logic, which blindly trusts the data as harmless. For example, an attacker can slip in SQL verbs as data. A vulnerable application may trust such "data" and slip the data into the SQL statements it is generating.

[0029] Strategically inserting prescribed instrumentation into the existing code base of each framework can become tedious and difficult to maintain as the framework code evolves over time. Over time, the number of programming languages ​​and software frameworks increases, making it impractical to instrument each one individually.

[0030] In some embodiments, the present disclosure provides an instrumentation engine that is independent (e.g., agnostic) of the underlying frameworks implemented on the server, which significantly reduces the time and resources required to instrument each framework individually, i.e., the present disclosure provides a protection solution that relies only on the underlying operating system.

[0031] As mentioned above, web-based applications routinely accept user input (e.g., HTTP requests, etc.) and translate it in real time into code for downstream interpreters (e.g., SQL interpreters, OS command interpreters, Java interpreters, XML interpreters, etc.). Such code is dispatched to remote interpreters using standard inter-process communication (IPC) means (e.g., shared memory, TCP / IP, named pipes, etc.). This inter-process communication is done using system calls. For example, TCP / IP communication is done using send and receive system calls, although one skilled in the art will recognize that other protocols may be used.

[0032] Web servers typically process each user input synchronously using a run-to-completion model, meaning that a web-based application spawns worker threads that synchronize the various operations contained in the user input.

[0033] Thus, collecting data on system calls generated by each worker thread in real time allows a method to observe in context the user's "data" and the corresponding "code" generated by the application. From such observation, it allows a method to detect when an attacker attempts to affect the interpreter by sending specific verbs to reach it. The method also allows for the execution status of such system calls to be ascertained.

[0034] Such synchronous data is then fed to an analysis engine that uses truth tables to determine in real time whether the application-generated code, as influenced by the user, is malicious or not.

[0035] FIG. 1 is a block diagram 100 illustrating some exemplary embodiments of the present disclosure. Note that while the example of FIG. 1 illustrates processing an HTTP request, the embodiments are not limited to processing an HTTP request. Rather, any type of request to a web-based application may be determined to be malicious or not. When establishing a session with a web-based application, a user system 102 transmits a user input 120 to a server 130 over a network. In this example, the server 130 processes the user input as an HTTP request 104. The business logic 106 of the server 130 is applied to the HTTP request 104 to generate a downstream interpreter request 108. The downstream interpreter request 108 is processed by the server to generate a downstream interpreter response 110. The downstream interpreter response is also analyzed by business logic 112 and converted into an HTTP response 114 and sent back to the user system 102.

[0036] In some embodiments, interactions between user system 102 and server 130 may be analyzed according to logic such as that represented in logic table 116. HTTP request 104 may be analyzed (e.g., at the TCP / IP level, etc.) to determine if interpreted syntax is present in HTTP request 104. For example, the analysis may determine if SQL code is present in the provided username or other data fields that may be interpreted as code downstream.

[0037] The business logic 106 (e.g., application code, etc.) is analyzed to determine whether user input 120 is present in the interpreter input. That is, the business logic 106 is analyzed to determine whether user input 120 converted into code instructions, such as SQL, is present in a command. Next, the business logic 112 is analyzed to determine whether the interpreter execution status is successful, i.e., whether the command failed. Finally, the HTTP response 114 is analyzed to determine whether interpreter syntax is present in the HTTP response and whether it was successful or failed.

[0038] Logic table 116 receives the results of the above analysis of the HTTP request chain and determines whether the request is benign, a threat, or an attack. A benign request does not pose a risk to the system. A threat is when user input causes interpreter code to be entered but the code does not execute successfully. An attack is when user input causes interpreter code to be entered and the code executes successfully.

[0039] If there is no interpreter syntax in the HTTP request 104 (e.g., in the first column, etc.), the user input 120 is harmless. However, if the interpreter syntax is detected, the logic table 116 analyzes whether the user input was incorporated into the interpreter input (e.g., an SQL command, etc.). If not, the HTTP request 104 is processed normally by the business logic and is deemed harmless. If the user input was incorporated into the interpreter input, the request is either an attack or a threat. Then, both the interpreter execution status and the interpreter syntax in the HTTP response are analyzed to determine whether the execution in the interpreter 112 and the HTTP response 114 were successful or unsuccessful. If successful, it is determined to be an attack, and if unsuccessful, it is determined to be a threat.

[0040] FIG. 2 is a flow diagram 200 illustrating an exemplary embodiment of the present disclosure. The flow diagram 200 illustrates the logic of the logic table 116. Referring to the flow diagram 200 of FIG. 2, the method first analyzes server activity (e.g., an HTTP request in a web-based application) (202). The server analyzes the activity to determine whether interpreter syntax is present in the HTTP request (204). If not, the request is deemed benign (212). If present, the request is further analyzed to determine whether user input has been filtered into the interpreter input through business logic / application logic (206). If not, the request is deemed benign (212). If so, the interpreter execution status (e.g., whether the interpreter can execute the code normally, etc.) is analyzed. If the execution is successful, the request is deemed an attack (216). Conversely, if execution fails, the request is analyzed to determine whether interpreter syntax is present in the HTTP response (208). If interpreter syntax is present in the HTTP response (208), the request is marked as an attack (216), otherwise the request is marked as a threat (214).

[0041] 3 illustrates one embodiment of an implementation of a system call table that provides the methods described below to a system, which may be a Linux, Windows, or MacOS system, or any other operation or distribution of an operating system. Although the following embodiment is described in the context of Linux, it should be understood that other operating systems may be used.

[0042] (System call table instrumentation)

[0043] Every time a distribution of Linux (or any other operating system) boots, a system call table is loaded into kernel memory. Essentially, the system call table is a table of function pointers that directs incoming system calls from user space to the appropriate kernel function to process the system call. For example, when a "read" system call is made from user space, the kernel calls the function that corresponds to the "read" system call (e.g., the "sys_read" function, etc.).

[0044] (System call table operations)

[0045] In some embodiments, after locating the address of a system call table by the "kallsyms_lookup_name" function, a pointer is placed in the table according to the system call number defined in the "linux / syscalls.h" header file. In some embodiments, the method may overwrite the table with a desired function to intercept any system call.

[0046] To allow for proper telemetry, the system call table 306 of the operating system 304 is instrumented, resulting in a hijacked (i.e., modified) system call table 306 of system calls that process user input (e.g., user input from step 1) through which subsequent code can be sent to other IPC endpoints, such as various interpreters within the application.

[0047] (Intercepting incoming traffic)

[0048] In some embodiments, the web server application and / or the endpoint (process monitoring) client 302 running on the server and accepting some input from the user may also be potential entry points for an attacker. In some embodiments, the method verifies that the input provided is clean and non-malicious before being processed by the server. Many web servers have their own application programming interface (API) for processing incoming data packets (e.g., HTTP requests, etc.) depending on the underlying programming language of the framework. As a non-limiting example, the framework may be written in C. For an incoming connection, C establishes a socket for the incoming connection with the accept() function, which internally calls the "accept" system call. This transfers control to the "sys_accept4" function from the system call table residing in kernel memory. Similarly, the incoming data is read by the read() function, which takes the file descriptor returned by accept() as an argument. The read() internally calls the "read" system call, which calls the "sys_read" kernel function.

[0049] By instrumenting specific kernel functions as above instead of instrumenting framework APIs, our method can provide instrumentation for any kind of framework that runs on a Linux machine. This can be achieved by manipulating (i.e. hijacking) the system call table.

[0050] In some embodiments, the method writes a custom function in the kernel module that executes the "sys_accept4" function and saves the returned file descriptor. Another custom function can be a function that checks the file descriptor of the "sys_read" call and validates the received data against the one returned by "sys_accept4". If so, the method calls the original function with the original arguments for normal execution. If not, the process is terminated for cleanup. Such custom functions in kernel code 312 are implemented in the hijacked system call driver and also communicate with the operating system (OS) 304 and the analysis engine 308 (which executes table 116 of FIG. 1 and the flow diagram of FIG. 2). If the analysis engine 308 identifies a threat or attack, it can issue a protective action 310 to the endpoint client 302.

[0051] (Current method)

[0052] [Kprobes]

[0053] Kprobes allows the installation of pre- and post-handlers for any kernel instruction, as well as handlers for function entry and function return. Each handler can access and modify registers. Kprobes allows the option to both monitor and modify ongoing processes. SystemTap is an example of a dynamic instrumentation tool for the Linux kernel, and uses Kprobes internally by default.

[0054] However, Kprobes is just a tool to set breakpoints at specific places in the kernel: to get the values ​​of function arguments or local variables, you need to know exactly where on the stack and in which register they are located.

[0055] The cost of placing a breakpoint is high even if it is a one-time operation. Although breakpoints do not affect the rest of the function, their processing cost is still relatively high. The jump optimization implemented in the x86_64 architecture can significantly reduce the cost of using Kprobes, but the cost of Kprobes is still higher than the cost of modifying the system call table. Kprobes involves many context switches and repeated saves and reads to hardware registers. Therefore, preemption must be disabled for all handler executions for synchronization purposes. This means that handlers cannot wait, which results in several restrictions on handlers, such as not being able to allocate large amounts of memory or handle I / O, and not being able to sleep on semaphores or timers.

[0056] [eBPF (Extended Berkeley Packet Filter)]

[0057] eBPF (extended Berkeley Packet Filter) allows sandboxed programs to be executed within the operating system. This allows application developers to add functionality to the operating system at runtime by executing eBPF programs. The operating system then ensures safety and execution efficiency as if the program had been compiled natively by using a just-in-time (JIT) compiler and verification engine. SystemTap itself has the ability to inject custom code through the eBPF backend.

[0058] The biggest limitation of eBPF is that it is limited to the most recent version of the Linux kernel: to take full advantage of eBPF, the kernel version must be 4.4 or higher, which makes it difficult to implement on older Linux distributions that are still in use.

[0059] The size of an eBPF program is limited to a maximum of 4096 bytes. This ensures that the program will terminate without falling into an infinite loop. This limits the resources that the program can access and the functions that the program can achieve. Therefore, eBPF programs tend to be very small.

[0060] (Custom implementation using user space components)

[0061] Another approach is to hijack the system call table but let the concurrently running user space application decide about process reservation. The kernel module and the user space application share memory by mapping the memory allocated by the kernel module into the user space application's address space using the "mmap" system call. The data in this memory is shared by a circular buffer.

[0062] The overall implementation flow is to first intercept an incoming or outgoing system call and store the data in a "syscall" object and add it to the "system call ring buffer". The thread then waits until a decision is made. A concurrently running user space application detects the entry and begins processing. The user space application analyzes the calling thread's system call data (e.g., arguments, return values, etc.) and past system call data to decide whether to kill the thread or let it run. This decision is then stored in a "response" object and added to the "response ring buffer". Another kernel thread then retrieves the response and, depending on the content of the response, either allows the calling thread to continue or terminates it.

[0063] One of the drawbacks of this approach was the wait - the calling thread had to wait for the decision, which was costly when running the benchmark. Also, the multiple context switches between kernel and user space threads strongly impacted the project's performance, which was another limitation or drawback of this implementation.

[0064] Nevertheless, the system presented here has several advantages: First, by hijacking the system call table, embodiments of the method are able to capture and store for further analysis the arguments and return values ​​of every traced system call.

[0065] Second, the attached code runs with preemption enabled, which allows embodiments to use semaphores, allocate larger chunks of memory, handle input / output making the code more dynamic, and protect critical sections.

[0066] Third, modifying the system call table is extremely cost effective.

[0067] Fourth, the method is applicable to both old and new versions of the Linux kernel.

[0068] Fifth, in the embodiment, since the system call table itself is overwritten, there is no restriction on the size of the code to be injected.

[0069] Sixth, by making all decisions within the kernel itself, there is no need for context switching and / or waiting for responses from user space.

[0070] FIG. 4 illustrates a digital processing environment, such as a computer network, in which embodiments of the invention may be implemented.

[0071] One or more client computers / devices 50 and one or more server computers 60 provide processing, storage, and input / output devices for executing application programs and the like. The client computers / devices 50 may also be connected to other computing devices, such as other client devices / processes 50, server computers 60, etc., via a communications network 70. The communications network 70 may be part of: a remote access network; a global network (e.g., the Internet); a collection of computers around the world; a local area network or a wide area network; and gateways that currently communicate with each other using their respective protocols (TCP / IP, Bluetooth, etc.). Other electronic device / computer network architectures are also suitable.

[0072] FIG. 5 is a diagram illustrating an example of the internal structure of a computer (e.g., client processor / device 50, server computer 60, etc.) in the computer system of FIG. 4. Each computer 50, 60 includes a system bus 79, which is a series of hardware lines used to transfer data between components of a computer or processing system. The system bus 79 is essentially a shared conduit connecting the components of a computer system (e.g., processor, disk storage, memory, input / output ports, network ports, etc.) and allowing information to be transferred between them. Attached to the system bus 79 is an I / O device interface 82 for connecting various input / output devices (e.g., keyboard, mouse, display, printer, speakers, etc.) to the computer 50, 60. A network interface 86 allows the computer to connect to various other devices attached to a network (e.g., network 70 of FIG. 4, etc.). The memory 90 provides volatile storage of computer software instructions 92 and data 94 utilized to implement embodiments of the present invention (e.g., web application modules, system call driver modules, hijacked or modified system call driver modules, analysis module code, etc., as described above). Disk storage 95 provides non-volatile storage of computer software instructions 92 and data 94 utilized in implementing embodiments of the present disclosure. Central processing unit 84 is also attached to system bus 79 and executes computer instructions.

[0073] In one embodiment, the processor routines 92 and data 94 are a computer program product (collectively 92), such as a non-transitory computer readable medium (e.g., one or more removable storage media, such as DVD-ROMs, CD-ROMs, diskettes, tapes, etc.) that provides at least a portion of the software instructions of the system of the present invention. The computer program product 92 may be installed by any suitable software installation procedure, as known in the art. In other embodiments, at least a portion of the software instructions may be downloaded via wired communication and / or wireless connections. In other embodiments, the program of the present invention is a computer program propagated signal product embodied in a propagated signal on a propagated medium (e.g., radio waves, infrared waves, laser waves, sound waves, electric waves propagated in a global network, such as the Internet or other network(s)). Such carrier media or signals may provide at least a portion of the software instructions of the routines / programs 92 of the present invention.

[0074] The entire teachings of each patent, published patent application and publication cited herein are incorporated by reference.

[0075] Although exemplary embodiments have been specifically shown and described, those skilled in the art will recognize that various changes in form and detail may be made therein without departing from the scope of the embodiments encompassed by the appended claims.

Claims

1. determining whether a request to a web-based application executing on a server is potentially harmful by examining the request and an interpretation of the request by the web-based application; issuing a protective action against the web-based application if the request of the web-based application is potentially harmful; A method comprising:

2. The method of claim 1 further comprising: determining whether execution of the request by the application will succeed or fail depending on whether the interpreter execution status is potentially harmful; if the request is successfully executed, labelling the request as an attack; if execution of the request is unsuccessful, labelling the request as a threat; A method comprising:

3. The method of claim 1 further comprising: determining whether execution of the request by the application will succeed or fail depending on whether the interpreter syntax status of a response is potentially harmful; if the request is successfully executed, labelling the request as an attack; if execution of the request is unsuccessful, labelling the request as a threat; A method comprising:

4. The method of claim 1 , wherein the request is a user request.

5. 2. The method of claim 1, wherein the step of determining whether the request is potentially harmful comprises: the substep of determining that interpreter syntax is present in the request and that user input is present in interpreter input; A method comprising:

6. The method of claim 1 further comprising: hijacking a system call table of said server; A method comprising:

7. The method of claim 1 further comprising: analyzing at least one of arguments and return values ​​of system calls traced by said server; A method comprising:

8. 2. The method of claim 1, wherein the determining step is performed on a modified system call table within a kernel of the operating system, the system call table being executed with preemption enabled.

9. 9. The method of claim 8, wherein enabling preemption also allows the use of semaphores, large memory allocations, handling of I / O to make the code dynamic, and protection of critical sections.

10. 9. The method of claim 8, wherein the modified system call table is applicable to multiple distributions and versions of any operating system.

11. 9. The method of claim 8, wherein the modified system call table allows detection of injected code of any size.

12. 9. The method of claim 8, wherein the steps of determining and issuing are performed within the kernel.

13. 13. The method of claim 12, wherein each process executed within the kernel does not require context switching and does not require waiting for a response from user space.

14. The method of claim 1 further comprising: receiving said request from a user system over a network; after said determining, responding to said request to said user system; A method comprising:

15. 2. The method of claim 1, wherein the interpreter is a logic program.

16. 2. The method of claim 1, wherein the protective measures are countermeasures such as stopping the request from being executed on the user system, and / or stopping the user request from being executed on the server, and / or denying read access to a database to the user request, and / or denying write access to a database to the user request.

17. 2. The method of claim 1, wherein the request is potentially harmful if data in the request is converted into code by the web-based application.

18. A processor; a memory having computer code instructions stored therein; A system comprising: The computer code instructions cause the processor and the memory to: determining whether a request to a web-based application running on a server is potentially harmful by examining the request and an interpretation of the request by the web-based application; and issuing a protective action against the web-based application if the request of the web-based application is potentially harmful; A system that is configured to run

19. 20. The system of claim 18, wherein the processor further comprises: determining whether execution of the request by the application is successful or unsuccessful based on whether the interpreter execution status is potentially harmful; If the request is successful, labeling the request as an attack; if execution of the request fails, labeling the request as a threat; The system is configured as follows:

20. 20. The system of claim 18, wherein the processor further comprises: determining whether execution of the request by the application is successful or unsuccessful based on whether an interpreter syntax status of a response is potentially harmful; If the request is successfully executed, labeling the request as an attack; if execution of the request fails, labeling the request as a threat; The system is configured as follows:

21. 20. The system of claim 18, wherein the request is a user request.

22. 20. The system of claim 18, wherein the step of determining whether the request is potentially harmful comprises: the substep of determining that interpreter syntax is present in the request and that user input is present in interpreter input; Including, the system.

23. 20. The system of claim 18, wherein the processor is further configured to hijack a system call table of the server.

24. 20. The system of claim 18, wherein the processor is further configured to analyze at least one of arguments and return values ​​of system calls traced by the server.

25. 20. The system of claim 18, wherein the step of determining occurs in a modified system call table within an operating system kernel, the system call table being executed with preemption enabled.

26. 26. The system of claim 25, wherein enabling preemption also enables the use of semaphores, large amounts of memory allocation, handling of I / O to make code dynamic, and protection of critical sections.

27. 26. The system of claim 25, wherein the modified system call table is applicable to multiple distributions and versions of any operating system.

28. 26. The system of claim 25, wherein the modified system call table allows for detection of injected code of any size.

29. 26. The system of claim 25, wherein the steps of determining and issuing are performed within the kernel.

30. 30. The system of claim 29, wherein each procedure executed within the kernel does not require context switching and does not require waiting for a response from user space.

31. 20. The system of claim 18, wherein the processor further comprises: receiving the request from a user system over a network; after said determining, responding to said request to said user system; The system is configured as follows:

32. 20. The system of claim 18, wherein the interpreter is a logic program.

33. 20. The system of claim 18, wherein the protective measures are countermeasures such as stopping the request from being executed on the user system, and / or stopping the user request from being executed on the server, and / or denying read access to a database to the user request, and / or denying write access to a database to the user request.

34. 20. The system of claim 18, wherein the request is potentially harmful if data in the request is converted into code by the web-based application.

Images