1. Overview of IAST and JD IAST Architecture
1. IASTOverview
IAST itself is a fusion technology, including white-box, black-box, and agent technologies
White-box testing is mainly composed of source code analysis and bytecode analysis, involving taint analysis and symbolic execution technologies
Through white-box testing, two important outputs can be obtained: the first is input parameters and constraints, and the second is unsafe method calls. Unsafe method calls generally have two sources: one is commonly existing standard functions, such as SQL exceptions, component calls, file reading, network access, etc.; the other is scenario-based calls related to the business, such as payment, checking inventory, order transactions, etc.
The black box mainly utilizes response testing for external APIs. Common methods include various POCs or fingerprint scanning, FUZZ fuzzy testing technology, and dynamic taint analysis technology
In addition to this, IAST also relies on agent technology, among which, Java mainly includes Java agent and native agent. The Java agent can inject classes before the main method, while the native agent can use JVMTI to manipulate agent methods at the JVM startup stage
2. JD Security IAST Architecture
The overall structure of JD Security IAST is very simple, including the client, cloud, and user interface
On the client side, JD Security adopts the container design pattern to manage the lifecycle with a state machineThere are two types of containers: one is an execution container, which ends after a single run and is mainly used for probe loading and system configuration; the other is a management container, which runs in the form of a thread, including probe management and system management, which can realize dynamic injection, system monitoring and start/stop, etc. The client's data can be transmitted to the cloud through a message queue. JD Security has designed two independent channels - data channels and management channels - to increase reliability while decoupling.
In the cloud, it is divided into three parts - cloud computing, cloud management, and scanner.The cloud management mainly coordinates with the user interface to complete testing tasks; the cloud computing performs preprocessing of the agent's log, associates the testing tasks with the logs, performs runtime analysis, and at the same time generates new scanning tasks. Among them, scanning tasks are divided into two types: one that can be detected by a single POC test, and another that needs to be combined with runtime information to judge; finally, the vulnerabilities detected at runtime and the vulnerabilities detected by the scanner are output to the user after passing through a strategy module, through which security R&D and testing personnel can make adjustments, thereby reducing false positives.
Secondly, the key technologies of JD IAST
1. Taint Propagation Technology
When mentioning IAST, the taint propagation model is often mentioned. For Java, there are generally two implementation methods: one is to rewrite Java basic data structures such as String, collections, etc., using injection technology to add taint variables for tracking, and some functions may use native agents to implement; the other is to maintain a metadata table to record the conversion and propagation of taint variables. Both of these will introduce a massive amount of data, especially in large systems, where testing is a scaled event, thereby presenting a huge challenge to data mining and analysis.
In the Java Tomcat environment, there is a simple implementation method, which is to add a taint magic number during scanner or functional testing, such as in parameters, payloads, and headers, because Tomcat uses a thread pool mechanism to allocate a thread to handle each request. This allows the construction of a runtime taint propagation path with a request as the unit. Since taint variables are not implemented, it is not possible to determine消毒点, but if combined with stack information and sink point parameter detection, it may compensate for this problem in most cases.
2. Stack Signature Algorithm
The main task of the stack signature algorithm is to standardize runtime information, so that runtime information can be analyzed and detected.
In detail, a request may hit several hooks, which construct an ordered sequence to form a vector. When multiple requests arrive, multiple vectors form a matrix, and then the matrix is used as input to build a trie tree. When the tree branches, the sequence of hooks before it is recorded, forming a stack signature, creating a rule. Taking the left figure as an example, two rules are generated here.
In actual use, a test is divided into two stages. The first stage is normal input, i.e., passing the functional test run by QA, in this stage, IAST will generate a rule set based on runtime information; the second stage, IAST constructs some POCs, fuzzy testing inputs through scanners, and performs blacklisting on the newly generated rules and business rules.
The figure on the right shows the test results of JD Security on a small dataset, which includes normal input, abnormal input, error-type injection, and time-based blind injection. Among them, error-type input and abnormal input will produce exceptions, and time-based blind injection is similar to normal input, but using stack signature algorithms, the vast majority of signatures can correctly identify the path of vulnerability exploitation.
3, Component Analysis Technology
Compared to white-box testing, IAST has certain advantages in component analysis because Java itself performs runtime loading, so it can obtain more information when applied, while white-box testing may encounter some difficult-to-solve packaging issues when performing component analysis.
4Logical Vulnerabilities
JD Security has two theoretical foundations for logical vulnerabilities (welcome to discuss if there are any differences):
1) Unit testing and integration testing are still the best stages for discovering logical vulnerabilities, and they are superior to security testing approaches.
Because at this stage, R&D and QA testers have a better understanding of code logic and functionality, making it easier to discover logical vulnerabilities,
2) Utilizing IAST, logical vulnerabilities can be discovered through fuzzy testing in the CD phase.
In the aspect of testing abstraction, for web asset A and parameter P, the process of security testing is denoted as f, and IAST identification of logical vulnerabilities needs to be divided into three steps:
First step, determine the permission factor in parameter P (for the set of parameters, if fuzzy testing is performed on one of the parameters, it will result in a different f, then this parameter itself has permission restrictions, abbreviated as permission factor; otherwise, it is a non-permission factor, and non-permission factors may have logical vulnerabilities);
Second step, for the permission factor, conduct another round of fuzzy testing. The main purpose of this test is to determine whether there is a reentrancy restriction for this factor; if not, it is downgraded to a non-permission factor;
Third step, for a node A in the asset tree that has not passed the logical vulnerability test, perform a deep traversal of the link where this node is located in the asset tree, as there is a risk of vertical privilege.
Three, IAST Research Recommendations
1, Do not make IAST into RASP or waf. The latter two are detection tools rather than tests; what IAST does is to identify paths or patterns.
2, Do not equate IAST with black-box testing. IAST itself is a technology that integrates the advantages of black-box and white-box testing and can do better than black-box testing.
3, Do not over-rely on the functional testing of QA, and fuzzy testing should be conducted. IAST has issues with code coverage, but QA testing actually cannot cover logical vulnerabilities, so fuzzy testing is needed to compensate for the shortcomings in unit testing and integration testing.
4, IAST can leave the vast majority of vulnerabilities offline.
ArchKeeper (Introduction): Issues and concepts of the architecture protection platform
3 JD open-source hotkey—Automatic detection of hotkey, distributed consistency caching solution
Dubbo Architecture Design and Source Code Analysis (Part Three) Chain of Responsibility Pattern
Analysis of the reflective class loading of high-version JDK in practical network defense and attack
Key Challenges and Architectural Design of Live CDN Scheduling Technology

评论已关闭