...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
While Data Flow Analysis (DFA) is the computer technique to extract info about values at each program site, Tainting Flow Analysis (TFA) is a special case of DFA between sources/sinks for checking if non-neutralized external inputs may reach vulnerability sinks.
...
...
...
...
Tainting Propagation Algorithm: for each sink detected (typically, an argument expression to a call to a sick function), follow backwards the variable value propagation in the CGF (Control Flow Graph) that could affect the sink site, until a source site that “taints” any of the candidate variables is reached.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Neutralization elements
...
...
...
<!ELEMENT neutralization (#PCDATA)*>
<!ATTLIST neutralization
argpos CDATA #REQUIRED
kind CDATA #IMPLIED
resource %resource; #IMPLIED
>
argpos:
argpos attribute specifies what object (or objects) are “untainted” by the routine. Indicates which element is being neutralized by this neutralization. Depending on how your custom neutralization routine works, you should code a differente value in this argument. Allowed values are:
- 0..n: A non negative value indicates that the argument at the given index (starting at 0)is being neutralized.
obj.call(arg1, arg2)
--> arg1 is neutralized when argpos="0"
arg2 is neutralized when argpos="1"
Both are neutralized when argpos="0,1"
...
language | xml |
---|
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Neutralization routines could be defined in the same class where they are used, or in a different one, where you can invoke them through an object instantiation call or by an static call. Any combination of this and the argpos attribute values is possible.
kind
A neutralization routine is usually applied to a specific vulnerability type (or “kind”). kind attribute indicates the type of vulnerability affected by this neutralization, like "xss", "sql_injection", "open_redirect", etc. Use "string" for general purpose neutralizations.
...
<neutralization argpos="-1" kind="sql_injection"/>
<neutralization argpos="-1" kind="xss"/>
In case you want the neutralization applies to ALL the vulnerabilities (i.e. it’s not specific to any vulnerability), set “string” as the value for “kind” attribute
resource
A neutralization routine also can be specifically suited to a particular resource type.
For example, your neutralization routine could be applied to “database” or “filesystem” resource types.
Valid values of resource can be one of (memory |os |configuration |environment |filesystem |formatstr |database |web |network |gui |crypto |other
).
As above, check the Sink Data to set the appropriate value. That’s the value you must indicate in “kind” attribute.
Reference
Structure of Custom Neutralization File (CNF)
Info |
---|
Any CNF must be an XML file with the following structure:
|
Next sections describe this structure.
Reference to master DTD file
Reference to master DTD must be specified in the 1st line.
Next table shows specific content depending on the technology:
...
Tech
...
DTD specification
...
DTD location
...
abap
...
<!DOCTYPE library SYSTEM "abap_library.dtd">
...
[agent_home_dir]/libraries/abap
...
c / cpp
...
<!DOCTYPE library SYSTEM "cpp_library.dtd">
...
[agent_home_dir]/libraries/c
...
csharp
...
<!DOCTYPE library SYSTEM "library_metadata.dtd">
...
...
java
...
<!DOCTYPE library SYSTEM "library_metadata.dtd">
...
...
javascript
...
<!DOCTYPE library SYSTEM "js_library_metadata.dtd">
...
[agent_home_dir]/libraries/javascript
...
objectivec
...
<!DOCTYPE library SYSTEM "library_metadata.dtd">
...
...
php
...
<!DOCTYPE library SYSTEM "php_library.dtd">
...
python
...
<!DOCTYPE library SYSTEM "python_library_metadata.dtd">
...
...