...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
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
...
...
argpos
Info | ||
---|---|---|
| ||
argpos attribute specifies the “tainted” object, i.e. what object (or objects) are “untainted” by the routine. |
...
value = obj.call( arg1, arg2)
The neutralization routine can “untaint” one or many of those objects.
argpos attribute specifies which ones, as follows:
- “-2” : untainted object will the caller to the routine => obj
- “-1” : untainted object will the returned object => value
- “0 … n” : argument with that index will be untainted => arg1 if 0, arg2 if 1, both if 0,1
kind
A neutralization routine is usually applied to a specific vulnerability type (or “kind”).
Info | ||
---|---|---|
| ||
kind attribute indicates the kind of vulnerability affected by this neutralization, like "xss", "sql_injection", "open_redirect", etc. |
To see the exact attribute value, locate the vulnerability you need to neutralize, open the sink data and see Category value.
You can include as many neutralization elements as vulnerability types your routine neutralizes.
<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">
...
<!ELEMENT neutralization (#PCDATA)*>
<!ATTLIST neutralization
argpos CDATA #REQUIRED
kind CDATA #IMPLIED
resource %resource; #IMPLIED
>
...
python
...
<!DOCTYPE library SYSTEM "python_library_metadata.dtd">
...
...