RASP technology detects exploitation attempts by instrumenting web applications. There can be multiple ways to detect exploitation attempts. We will discuss some of the approaches by which RASP can detect exploitation attempts along with the pros and cons of each technique.
To better explain each of the approaches, we will take an example of a code prone to SQL injection vulnerability and how each of these approaches will detect SQL injection exploitation in the vulnerable code. Code vulnerable to the SQL injection vulnerability is shown in Figure 1.0
As shown in Figure 1.0, “SELECT Host FROM mysql.user WHERE User =‘bob’;”, is an example of the legitimate SQL query executed by the application. The legitimate query sent to the database is defined in the application. The variable user’s value as ‘bob’ is taken from the value field of the methods that accept user input, such as the GET, POST, etc.
In the case of an SQL injection exploit, a threat actor will insert a malicious SQL clause along with a value into the methods that accept user or external inputs (such as GET, POST). This malicious clause will get executed by the application along with the legitimate query. Explaining it with an example, if the threat actor injects malicious SQL clause “UNION SELECT username, Password FROM Users”, by appending it to the value of the variable user “bob”, the query that gets executed by the application becomes “SELECT Host FROM mysql.user WHERE user= ‘bob’ UNION SELECT username, Password FROM Users;”
To detect the SQL injection vulnerability by instrumenting web applications, below are some of the approaches.
Detection at the methods which accept User Inputs:
In this architecture, RASP will instrument the HTTP methods which accept user inputs such as GET, POST, HTTP Headers etc. The detection algorithm will detect the exploitation by validating the values entered by a user. The architecture provides an inherent advantage that the exploits can be stopped before reaching the execution functions. However, the approach provides the following inherent limitation.
- Alert, which detects exploitation by using the architecture, will denote that a threat actor is executing exploits. It does not mean the code is vulnerable or can be exploited.
- The approach of instrumenting methods at user input overlaps with the network inspection devices which inspect the packets and validates the arguments of HTTP headers.
Detections at the Execution Functions using Program Dependency Graph
In this approach to detect injection-based exploitation, the algorithm to detect the injection attack uses the application-level hooks to construct a program dependency graph (PDG). The PDG captures data and controls flow from methods that accept external or user input, such as GET, POST, Cookies, etc. to the execution functions. Any injected malicious SQL clause by a threat actor to the legitimate SQL query will get reflected by the additional or deleted node in the parse tree of the normalized legitimate SQL query.
The approach provides an inherent advantage since it get triggered during the execution function's invocation, it detects the exploitation attempt by a threat actor, and with each detected attempt of exploitation the vulnerable code path gets identified.
However, this approach has a limitation. For example, for the vulnerable code shown in figure 1.0, if the exploit is test';SELECT PG_SLEEP(5)-- it will result in a new node in the query's postgres parse tree, and the exploit will get detected. However, if the exploit is 10) ORDER BY 1-- TduL, even though the code is vulnerable, it will not result in a new node in the original query's parse tree. The right exploit is required to detect the injection-based exploitation by analyzing the data flow.
Detections at the Execution Functions using Program Dependency Graph, Parsers, Honey Queries.
In this approach, to detect injection-based exploitation, the detection algorithm will make use of the program dependency graph as discussed above. Besides using the approach discussed above, once the user input values reach the execution functions, these values are extracted and further validated if these are data or these input values will add a node to the program dependence graph of the original code or query.
The additional validation can be done in many ways. For example, in SQL injection exploits, the input values can be passed to the honey queries. Figure 2.0 shows examples of some of these honey queries. When the user input is plugged into the honey query, any addition or deletion of the nodes in the honey query's progress parse tree will denote the threat actor's exploitation attempt.
- SELECT * WHERE id = '[values passed to methods accepting user inputs]' AND honey_value = '2' ,
- (SELECT * WHERE id = '[values passed to methods accepting user inputs]' AND honey_value = '1')
- (SELECT * WHERE id = [values passed to methods accepting user inputs] AND honey_value = '1')
- SELECT * WHERE id = [values passed to methods accepting user inputs] AND honey_value = '1'
Figure 2.0 Honey queries which can be used to compute the changes in the parse tree.
Besides using honey queries, other approaches such as running the input against parsers can be taken to determine if the user input has a code or a clause as per the exploitation techniques. For example, to detect XSS exploits having a javascript function, user inputs can be passed through the esprima javascript parser, and the abstract syntax tree can be validated to check if there is "CallExpression". If the “CallExpression" is presented it will denote the presence of javascript functions in the user inputs.
The approach provides two inherent advantages:
- It detects the exploitation attempt at the execution functions. Alert for exploitation will denote vulnerability exists in the code.
- Approach to detect exploitation makes use of changes in the PDG of the original code (or changes in the parse tree of the query) and makes uses of honey queries, parsers, and emulators. Hence, the method will detect exploits even though the exploit may not lead to the additional node in the vulnerable code's PDG or parse tree.
Conclusion
RASP is one of the recommended technologies to detect web application vulnerabilities. The algorithm detects exploitation; responsive measures can be applied to stop exploitation; it also provides remedial action, which will increase the exploitation complexity for a threat actor. Corrective action is patching the vulnerable code path, which automatically gets identified with each detected attempt of exploitation. If the code gets fixed, detection alerts will decrease, increasing the exploitation complexity for a threat actor. Detection algorithms should not only rely on the changes of PDG of the original code, but also make use of parsers, emulators, and honey queries to detect injection-based exploitation.