Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Single-Analysis
    • Neutralizations can apply only to a unique analysis.
    • In this case, the xml file should be located at:
      • [analysis_base_dir]/libraries/[technology]
  • Application-specific
    • Neutralizations can apply to all analyses of a specific application.
    • In this case, the xml file should be located at:
      • [agent_home_dir]/conf/apps/[app_name]/libraries/[technology] 
  • System-wide 
    • Neutralizations can apply to all analyses of all applications.
    • In this case, the xml file should be located at:
      • [agent_home_dir]/conf/libraries/[technology] 
    • Exceptions to this rule are: 
      • cpp engine reads from  …/libraries/c 
      • objective engine reads from …/libraries/objetivec and …/libraries/c

 

Info
titleLegend

...

  • [agent_home_dir] : local installation directory of Kiuwan Local Analyzer (KLA)

  • [analysis_base_dir] : root directory of application source code to be analyzed, as specified by “-s” option of KLA CLI (Command Line Interface), or in “Folder to analyze” input box when using KLA GUI (Graphical User Interface)
  • [app_name] : name of the app to be analyzed, as specified by “-n” option of KLA CLI (Command Line Interface), or in “Application name” input box when using KLA GUI (Graphical User Interface)
  • [technology] : name of the Kiuwan technology, as specified in  [agent_home_dir]/conf/LanguageInfo.properties
Warning
titleBe careful

Never save custom libraries files or edit existing files in folder [agent_home_dir]/libraries/{tech}, because this folder is going to be removed when the engine is updated.

 

As a general recommendation, we suggest to name the xml file as [technology]_custom_neutralizations.xml (this will help to clearly identify your custom files from Kiuwan own files).

...

In this example the method validate is a custom neutralization for a path from a source to a path traversal sink. The input of method validate is neutralized and the output, (referred by argpos -1 in the neutralization definition in the xml library), is untainted after the validation is executed.

The next source code shows an example of how to use the neutralization.:

Code Block
languagejava
package com.mycompany.onepackage;
 
import com.mycompany.otherpackage.MyUtils;
import javax.servlet.http.HttpServletRequest ;
import java.io.FileInputStream;
public class MyClass {
 
   // ...
   public void methodThatAccessToFileSystem(HttpServletRequest req) {
       String inputFile = req.getParameter("file"); //inputFile tainted
       inputFile = MyUtils.validate(inputFile + ".tmp"); //inputFile untainted after validation
       return new FileInputStream(SAFE_DIR.getAbsoluteFile() + inputFile);
   }
   
   // ...
}
 
=======================================
 
package com.mycompany.otherpackage;
 
import com.mycompany.IMyUtilsClass;
 
public class MyUtils implements IMyUtilsClass {
 
	// ....
	public String validate(String value) {
 
		// ...
        // perform string value validation/Canonicalization/Normalization/Sanitization
        // ...
		return value; // once cleaned up
    }
}
Code Block
languagexml
<!DOCTYPE library SYSTEM "library_metadata.dtd">
<library name="java.custom.libraries">
  <class name="com.mycompany.otherpackage.MyUtils" kind="class" supertypes="com.mycompany.IMyUtilsClass">
    <method name="validate" signature="validate(java.lang.String)" match="name">
      <return type="java.lang.String"/>
      <neutralization argpos="-1" kind="path_traversal" resource="web" />
    </method>
  </class>
</library>
Info
titleNote

Do not forget:

  • types has to be fully qualified
  • specify return type if the method has one
  • no need to declare parameters names in the method signature, just the fully qualified types

 

 

 

Example 2 (Java)

In the next example the neutralization only affects to filesystem resources:

...