Search

EP-4421667-B1 - INJECTION ATTACK SENSOR WITH SYNTAX ATTACK DETECTION TEMPLATE

EP4421667B1EP 4421667 B1EP4421667 B1EP 4421667B1EP-4421667-B1

Inventors

  • HEBERT, CEDRIC
  • BARBER, THOMAS
  • PATNAIK, Suv Sanjit

Dates

Publication Date
20260513
Application Date
20230829

Claims (15)

  1. A computer-implemented method comprising: via instrumentation within a cloud application (120, 330, 520, 640, 715, 1110, 1240), tracking which data incorporated in an executable statement originates as input data (140, 320, 705) from a client computer (110, 310, 510, 1205), wherein the data incorporated in the executable statement and originating as input data (140, 320, 705) from the client computer (110, 310, 510, 1205) is designated as tainted data (355); generating a mock executable statement (155, 365), wherein generating the mock executable statement (155, 365) comprises incorporating the tainted data (355) into a syntax attack detection template (160, 360, 560, 660), and wherein the mock executable statement (155, 365) comprises the tainted data (355) as well as the body of the syntax attack detection template (160, 360, 560, 660); detecting syntax manipulation by the tainted data (355) in the mock executable statement (155, 365), wherein the mock executable statement (155, 365) is analyzed to determine whether the tainted data (355) has manipulated the syntax of the mock executable statement (155, 365); and responsive to detecting syntax manipulation by the tainted data (355), generating an alert (170, 380) indicating that syntax of the mock executable statement (155, 365) has been manipulated by the tainted data (355).
  2. The method of claim 1, wherein instrumentation (125, 335, 525) is performed by a taint-aware class that is substituted for an original class in the cloud application (120, 330, 520, 640, 715, 1110, 1240); and/or wherein instrumentation (125, 335, 525) is performed non-intrusively.
  3. The method of claim 1 or 2, wherein: tracking which data incorporated in an executable statement originates as input data (140, 320, 705) from a client computer (110, 310, 510, 1205) comprises: intercepting a Structured Query Language (SQL) query generated by the cloud application (120, 330, 520, 640, 715, 1110, 1240).
  4. The method of any one of the preceding claims, further comprising: determining whether the syntax manipulation is categorized as malicious or malformed; wherein the alert (170, 380) indicates whether the syntax manipulation is categorized as malicious or malformed.
  5. The method of any one of the preceding claims, wherein: the cloud application (120, 330, 520, 640, 715, 1110, 1240) comprises code injection attack blocking functionality that blocks a given code injection attack; and syntax manipulation by the tainted data (355) in the mock executable statement (155, 365) is detected; whereby an attempted attack is separately detected via the mock executable statement (155, 365) even though the attempted attack is blocked by the cloud application (120, 330, 520, 640, 715, 1110, 1240).
  6. The method of any one of the preceding claims, wherein generating the mock executable statement (155, 365) comprises incorporating the tainted data (355) in place of a parameter of the syntax attack detection template (160, 360, 560, 660); and/or wherein the data to be included in the executable statement originates as string data received from the client computer (110, 310, 510, 1205) in response to an HTML form (130); and/or wherein the mock executable statement (155, 365) comprises an SQL statement in string form.
  7. The method of any one of the preceding claims, wherein: detecting syntax manipulation comprises: parsing the mock executable statement (155, 365) into multiple parsed tokens based on syntax of a language of the executable statement; and determining that a unit of tainted data (355) spans more than one parsed token, optionally wherein: the parsing parses into keywords and literals; and determining that a unit of tainted data (355) spans more than one parsed token comprises determining that the unit spans a keyword-literal boundary.
  8. The method of any one of the preceding claims, wherein: detecting syntax manipulation comprises: parsing the mock executable statement (155, 365) into multiple parsed tokens based on syntax of a language of the executable statement; determining that a unit of tainted data (355) increases a number of parsed tokens as compared to the syntax attack detection template.
  9. The method of any one of the preceding claims, wherein the method further comprises: responsive to the alert (170, 380), locking an account of a user that was used for sending an incoming request that provided the input data (140, 320, 705) from the client computer (110, 310, 510, 1205); and/or wherein the method further comprises: responsive to the alert, assembling details of an incoming request that provided the input data (140, 320, 705) from the client computer (110, 310, 510, 1205); and sending the details to an incident response destination.
  10. A computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) comprising: at least one hardware processor (1305, 1410); at least one memory coupled to the at least one hardware processor (1305, 1410); an executable application (120, 330, 520, 640, 715, 1110, 1240) configured to receive input (140, 320, 705) from a browser (610, 1210); a stored syntax attack detection template (160, 360, 560, 660); a tainting engine (150, 350, 550) configured to identify an input string received by the executable application (120, 330, 520, 640, 715, 1110, 1240) from the browser (610, 1210) that is incorporated into an executable statement generated by the executable application (120, 330, 520, 640, 715, 1110, 1240), wherein the tainting engine (150, 350, 550) is further configured to generate a mock executable statement (155, 365) by incorporating the input string into a syntax attack detection template (160, 360, 560, 660), the mock executable statement (155, 365) comprising the input string as well as the body of the syntax attack detection template (160, 360, 560, 660), determine that the input string manipulates syntax of the mock executable statement (155, 365), wherein the mock executable statement (155, 365) is analyzed to determine whether the input string has manipulated the syntax of the mock executable statement (155, 365), and generate an alert (170, 380) upon determining that the input string does manipulate syntax of the mock executable statement (155, 365).
  11. The computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) of claim 10 wherein: non-intrusive instrumentation (125, 335, 525) within the executable application (120, 330, 520, 640, 715, 1110, 1240) detects the input string and provides the input string to the tainting engine (150, 350, 550).
  12. The computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) of claim 10 or 11 wherein: the tainting engine (150, 350, 550) is configured to determine whether syntax manipulation by the input string is categorized as malicious or malformed, wherein a determination of malformed is indicated by introduction of a syntax error; and wherein the alert (170, 380) indicates whether the syntax manipulation is categorized as malicious or malformed.
  13. The computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) of any one of claims 10 to 12 wherein: the executable application (120, 330, 520, 640, 715, 1110, 1240) is configured to successfully block an attack of an attack type detected by the tainting engine (150, 350, 550); and the tainting engine (150, 350, 550) separately detects the attack.
  14. The computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) of any one of claims 10 to 13 further comprising: a reverse proxy (620) configured to collect details regarding a session from which the input string originated.
  15. One or more non-transitory computer-readable media (1310, 1315, 1420, 1425) comprising computer-executable instructions that, when executed by a computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500), cause the computing system (100, 300, 500, 600, 700, 800, 1100, 1200, 1300, 1400, 1500) to perform operations comprising: via non-intrusive instrumentation (125, 335, 525) within a cloud application (120, 330, 520, 640, 715, 1110, 1240) configured to communicate with a client-side browser (610, 1210), identifying input string data received from the client-side browser (610, 1210) that is included in an executable statement generated by the cloud application (120, 330, 520, 640, 715, 1110, 1240); generating a mock executable SQL statement (155, 365), wherein generating the mock executable SQL statement (155, 365) comprises incorporating the input string data into a syntax attack detection template (160, 360, 560, 660), and wherein the mock executable SQL statement (155, 365) comprises the input string data as well as the body of the syntax attack detection template (160, 360, 560, 660); detecting syntax manipulation by the input string data in the mock executable SQL statement (155, 365), wherein the mock executable SQL statement (155, 365) is analyzed to determine whether the input string data has manipulated the syntax of the mock executable statement (155, 365), and wherein the syntax manipulation comprises alteration by the input string data of syntax structure of the mock executable SQL statement (155, 365); and responsive to detecting the syntax manipulation by the input string data, sending an alert (170, 380) indicative of an attempted malicious attack against the cloud application (120, 330, 520, 640, 715, 1110, 1240).

Description

FIELD The field generally relates to computer network security, and particularly to computer network security in a cloud context. BACKGROUND Document PARAMESHWARAN INIAN INIAN@COMP NUS EDU SG ET AL: "Auto-patching DOM-based XSS at scale", USER INTERFACE SOFTWARE AND TECHNOLOGY, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 30 August 2015 (2015-08-30), pages 272-283, XP058522217, DOI: 10.1145/2786805.2786821, ISBN: 978-1-4503-4531-6 discloses a technique to generate secure patches that replace unsafe string interpolation with safer code that utilizes programmatic DOM construction techniques. The system transparently auto-patches the vulnerable site while incurring only 5.2 - 8.07% overhead. The patching mechanism requires no access to server-side code or modification to browsers, and thus is practical as a turnkey defense. Maintaining computer network security remains an elusive goal, especially in the cloud context. A number of approaches have been tried, such as web application firewalls, intrusion detection systems, and static code analysis. Early intrusion detection is helpful, but it is no easy task to determine when an attempt is successful, let alone when unsuccessful attacks are being attempted. One nagging problem with many solutions is that they attempt to generically solve a problem that unfortunately manifests itself in the particularities of a given software application. For example, web application firewalls can inspect data, but are removed from the actual execution within an application. Static code analysis on the other hand is close to the internal logic of the application but does not benefit from observing how actual data coming into the application affects execution. There thus remains a need for improved methods of detecting network intrusion attempts by threat actors. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of an example system implementing an injection attack sensor with a syntax attack detection template.FIG. 2 is a flowchart of an example method of sensing an injection attack with a syntax attack detection template.FIG. 3 is a block diagram of example system implementing an injection attack sensor with a syntax attack detection template via an executable statement parser.FIG. 4 is a flowchart of an example method of sensing an injection attack with a syntax attack detection template via parsing a mock executable statement.FIG. 5 is a block diagram of an example system that detects an attack, even if the application is not vulnerable to the attack.FIG. 6 is a block diagram of an example software architecture for implementing the technologies described herein.FIG. 7 is a block diagram illustrating a computing environment where tainting framework is implemented, according to one embodiment.FIG. 8 is a block diagram illustrating a computer system, enabling the replacement of an original data class with a taint-aware class, according to one embodiment.FIG. 9 is a flow diagram that illustrates a process to track tainting, according to one embodiment.FIG. 10 shows example Java based code snippets illustrating bytecode code instrumentation, according to one embodiment.FIG. 11 is a block diagram illustrating a system dynamically instrumenting bytecode, according to one embodiment.FIG. 12 is a block diagram illustrating cloud-based computing environment where taint-tracing is implemented, according to one embodiment.FIG. 13 is a block diagram of an example computer system to execute taint-tracking, according to one embodiment.FIG. 14 is a block diagram of an example computing system in which described embodiments can be implemented.FIG. 15 is a block diagram of an example cloud computing environment that can be used in conjunction with the technologies described herein. DETAILED DESCRIPTION Example 1 - Overview The invention is defined by the appended claims. One particularly troublesome form of computer network attack is the code injection attack. Such attacks can involve client-side cross-site scripting (XSS), tampering with structured query language clauses, and the like. In such attacks, incoming data (e.g., ostensibly user input) can affect the execution flow of an application beyond what was intended by the software developers. Clever threat actors can use such vulnerabilities in creative ways to gain unauthorized access to the computing system. Techniques such as web application firewalls (WAF) and intrusion detection systems (IDS) can be used to address such attacks, but they are prone to both false positives as well as false negative alerts. False positives lead to alert fatigue, where auditors miss real attacks because they appear to be yet another false positive. False negatives serve as a blind spot for auditors. An attack-aware application is able to detect when it is attacked and can react accordingly (e.g., by sending an alert to an on-duty monitoring team). Having the application perform detection has a dual advantage in that it can be more accur