This project is the CoraxJava Rule Checker
module, which can implement multiple rule checks and compile them into a plugin form, to be loaded and executed by the CoraxJava Core Analysis Engine
module.
It is often necessary to customize CoraxJava rule checkers, including several common scenarios, from simple to complex, and from shallow to deep customization:
- Coarse-grained adjustments to the CoraxJava rule checker module; such as enabling/disabling certain rule checks, adding already implemented rule checkers, and adding some data check properties to already implemented rule checkers.
- Fine-grained adjustments to the CoraxJava rule checker; such as modifying the source, sink, or modifying data transmission rules summary configuration of certain already implemented rule checkers.
- Adding new rules for checks, but using existing checkers as templates, with slight modifications to configurations and code to complete the check.
- Adding new rules for checks, but requiring completely custom development and implementation of their checkers.
Simply modify the yaml configuration file analysis-config/default-config.yml to achieve coarse-grained adjustments to the CoraxJava Rule Checker
module.
For example, to enable/disable specific checkers, you can set enable
to false
in the following configuration:
- !<CheckerUnitOptionalConfig>
name: "feysh-config-community:com.feysh.corax.config.community.checkers.httponly-cookie"
enable: true
options: null
To add options to a checker, including adding TaintTypes
to the checker
- !<CheckerUnitOptionalConfig>
name: "feysh-config-community:com.feysh.corax.config.community.checkers.taint-checker"
enable: true
options: !<com.feysh.corax.config.community.checkers.taint-checker.Options>
kind2Checker:
"command-injection":
checkTaintTypes:
- !<GeneralTaintTypes> "ControlData"
- !<GeneralTaintTypes> "CONTAINS_COMMAND_INJECT"
taintTypeExcludes: []
reportType: !<com.feysh.corax.config.community.CmdiChecker.CommandInjection> {}
msgArgs: {}
enable: true
For more information, refer to analysis-config/default-config.yml and subsequent explanations.
Commonly involves modifying the source, sink, summary, and other configurations of existing rule checkers.
Files with the suffix sources.json
such as general.sources.json contain sources that are grouped together and categorized using kind
, for example:
[
{"kind":"remote","signature":"javax.servlet.ServletRequest: * getInputStream()","subtypes":false,"arg":"ReturnValue","provenance":"manual","ext":""},
{"kind":"remote","signature":"javax.servlet.ServletRequest: * getParameter(String)","subtypes":false,"arg":"ReturnValue","provenance":"manual","ext":""},
...
]
Similarly, files with the suffix sinks.json
such as community.sinks.json contain sinks that are grouped together and categorized using kind
:
[
{"kind":"command-injection","signature":"java.lang.Runtime: * load(String)","subtypes":false,"arg":"Argument[0]","provenance":"ai-manual","ext":""},
{"kind":"command-injection","signature":"java.lang.Runtime: * loadLibrary(String)","subtypes":false,"arg":"Argument[0]","provenance":"ai-manual","ext":""},
...
]
Files with the suffix summaries.json
, such as general.summaries.json, contain summaries related to the rules and configurations.
[
{"signature":"java.lang.AbstractStringBuilder: * <init>(String)","subtypes":true,"argTo":"Argument[this]","propagate":"taint","argFrom":"Argument[0]","provenance":"manual","ext":""},
{"signature":"java.lang.AbstractStringBuilder: * append(**)","subtypes":true,"argTo":"ReturnValue","propagate":"value","argFrom":"Argument[this]","provenance":"manual","ext":""}
...
]
signature
can be in the format ofmatchSoot
or in the format ofmatchSimpleSig
.subtypes
indicates whether to handle overridden methods in subclasses (static methods are always false, interfaces are always true)."propagate": "taint"
means taint kinds propagation. After method execution,to
andfrom
may point to different objects. If they are different, thento
has been tainted or affected, whilefrom
remains unaffected, unless there are alias relationships in the program."propagate": "value"
means value propagation, whereto
andfrom
point to the same object.provenance
is a reserved field and is not closely related toext
.
By modifying some code or parameters, you can customize the rule checker.
Developers can compare the types of vulnerabilities they want to detect with the rules already implemented in the community version and then proceed to implement similar rule codes. For example:
- Command injection rule checker is a typical Taint-type checker, which can be referenced for implementing injection issues (SSRF detection, SQL injection, XSS injection, path traversal, template injection, open redirection, etc.) and sensitive information leakage, both fall under the category of taint issues.
- The implementation of SQL injection rule checker includes not only classic Taint-type checking but also includes support for adapting MyBatis framework injection sink point checking.
- The Spring Response Body injection check for XSS vulnerability is implemented by dynamically checking sink points through matching corresponding Java annotations, similar to SQL injection checks in scenarios with hibernate.jpa
Query
annotations and ibatisSelect
annotations. - The cookie attribute setting check mainly demonstrates API call sequence combination checks and detection of specific parameters, similar to PermissiveCors check.
- Detection of insecure TLS versions mainly involves specific API detection and constant parameter detection, similar to checks for cryptographic misuse, weak hash algorithms, cookie persistent maxAge, Ldap anonymous, etc.
- Omitted, can be found in other open source implementations in this project.
-
Define
Checker
referring to IChecker (if it exists then proceed)- Define
Rule
referring to IRule - Define
BugCategory
IBugCategory
- Define
-
Define
CheckType
referring to CheckType (if it exists then proceed)- Define bug message referring to BugMessage
-
Choose a
CheckerUnit
, based on the bugs and principles to be checked by the checker, choose a suitable Analysis, refer to CheckerUnit -
Once chosen, start writing the checker according to the requirements and corresponding check principles, and when calling
ICheckPoint.report(checkType)
orIOperatorFactory.check(boolExpr, checkType)
, pass in the CheckType from step two.If you need to check for some more direct bugs in your written checker, you can follow these two steps:
- Edit the AnalyzerConfigRegistry file and add the newly added checker registration in
preAnalysisImpl
oraiCheckerImpl
. - After adding it, you can run
gradlew :corax-config-community:test --tests "com.feysh.corax.config.tests.ConfigValidate.validate"
, which can check for some checker writing errors and prompt for corrections.
- Edit the AnalyzerConfigRegistry file and add the newly added checker registration in
-
Go to corax-config-tests/normal/src/main/java/testcode and write corresponding non-compliant and compliant code to test and ensure analysis accuracy, refer to Unit Testing
-
Run
gradlew build
to compile and package the final configuration build/analysis-config -
Follow Readme.md#Getting Started with Analysis to load the configuration and start analysis
-
View the report sarif, if there are any false positives or missed reports, analyze the reasons and consider if corrections or optimizations are needed, refer to Result Output
For more detailed detection methods, you can refer to Detailed Explanation of Custom Rule Checker.