Fortify Custom Rules
The reason for this is to be able to give custom descriptions via SQL injection in Java and .NET, for example, and custom references so that they can be language-specific. It seems that Fortify maps custom rules by category, but the problem occurs when we have two packages, one for .NET and one for Java, and both expose a category called Cross-Site Scripting. In this repository.xml there is an example where all the rules have been added. The demonstration can be performed with the following commands. Note: When using characterization rules, analyses must include the default rule set that applies the built-in relays required for data flow analysis. Looking for a Fortify rule that combines the power of structural rules with flow analysis capabilities? The characterization rule (currently poorly documented) is an excellent type of rule that allows you to go beyond the limits of traditional flow analysis rules by allowing you to define flow analysis statements based on structural code matching. These rules use structural signatures to add vulnerabilities to AST elements. We will use them to add a +PRIVACY task to the return to GetPrivateData. We then create a rule to push the data flaw to the Request object, and then another rule passes to SendResponse. Do you know how to make these rules specific to the language? The first step in writing structure rules is (usually) to empty the structure tree to see which nodes we need to work with.
This dump is targeted at a specific line of code in which the signature must be written. Once found, the line number in the DumpLine.xml rules file must be updated. After that, a Fortify scan can be performed with a specific hidden indicator that places the structure tree in the specified location. Multithreaded scanning must be disabled for this approach to work. The following code indicates who should perform this operation. It should be noted that not all nodes are polymorphic, and although they appear to be a child node on the dumped structure tree, Fortify`s structural rule front end generally does not accept the decent node type. This sometimes occurs when an AssignmentStatement is used as a pivot. In such cases, it is usually recommended to start at the lowest branch of the AST at this line number and climb the tree to the pivot point, and then return to the other side. Structure and characterization rules use Fortify`s query language to match specific coding patterns in the AST. This paper will examine the methodology needed to develop these types of rules. Note: When developing characterization rules, it is best to add a structure rule for testing to verify that the signature is applied correctly, such as getting a determination on the desired line number and then applying the odor characteristics.
A technique for developing Fortify structure rules and characterization rules. Let`s develop some structural rules (and characterization rules) for a real application. This application sends a response to a recipient when it is run. It has a GetPrivateData() member who returns data that will never leave the system. It also has a SendResponse() function that sends the data specified by the developer to the receiver. The data is sent in the Response structure. As part of the security model with this application, private data should never leave the system, so data derived from GetPrivateData should never be loaded into a Response object and then sent via SendResponse. This sequence results in a data breach in the system in question. The developer has implemented the following code. But wait, says the developer, sometimes we put private data in a Response object, but we don`t send it to the customer.
This rule would then be a false positive in these cases. Noise may not be enough to warrant more rules, but for fun, we`ll improve this rule to detect when a call to SendResponse occurs. Note: This can be done with traditional XML-based DataFlowSource and DataFlowSink rules, but the purpose of this exercise is to write structure-based rules, which is how we will do it. I`m in the process of creating customs rules using Fortify, but I`m wondering if there`s a way to customize these rules so they can be language-specific. As mentioned earlier, this type of rule is not currently fully documented, but some syntax guidance is available in the Fortify SCA structural type system documentation. You can also use the custom Fortify Rules Editor for syntax completion and validation of the XML structure. We already have the signature to map the smell of the GetPrivateData call to the rhs of the assignment statement. This is an adaptation to the previous rule. Note that the XML tags for characterization rules are slightly different from those for a structure rule, but the syntax is always the same.
If nothing happens, download GitHub Desktop and try again. With a starting point, we can now start mapping relationships with other nodes in the AST. One approach would be to assign each time private data is assigned to a Response object, a result must be generated. In this case, we try to bind the FunctionCall event to AssignmentStatement, where rhs is of type Request. So let`s start by saying that our pivot is the allocation statement. But wait!, there is no AssignmentStatement node. This is because when objects are assigned, it is not an assignment statement, but a call to a copy constructor, which is actually a FunctionCall. If primitive types had been used, an AssignmentStatement would have occurred.
If we look at our AST, we see that (specifically for C++) the actual call is basic_string::operator=. This is the real mission we are looking for and will begin as a turning point. If we explore the AST, we can see the following as a relationship: FunctionCall (operator=) -> arguments -> lhs -> FunctionCall (GetPrivateData). We can also observe that the bounding statement is an AssignmentStatement that we can add to reduce false positives. This information can be used to create the following rule. Scan with the ruler and see that we find the node correctly.