...
As said above, for every sink there will appear the list of sources that are “feeding” that sink.
But you might be wondering why are there 5 sources with the same file name and line.
We’ve selected this specific example because it shows something that would be possible to happen in your own code. Let’s go in detail exploring the 2nd source.
In the 2nd source you can see that the propagation nodes are different from the previous one.
While in the 1st the propagation was through Delete_User.java, in the 2nd goes through a different file: Insert_Raw_Text.java
Remainder sources for the same sink shows that there are still other different propagation paths between same source and sink.
This example is a special case where the call sequence consists of 5 servlets calling a utility (ParameterNullFix.sanitizeNull(..)) to recover some request parameters, building a SQL sentence with those tainted data and sending the sql sentence to another utility (UpdateUtil.executeUpdate(…) ) to execute the database update.
This is the reason Kiuwan shows one sink with 5 different sinks. That difference is because the propagation paths are through the different servlets. In this case, the easiest fix would be to sanitize the user data at the source, therefore remediating 5 found defects with only one fix.
| Info |
|---|
As a summary, you can understand any injection vulnerability as a unique propagation path from source to sink, regardless source and sink be the same. |
Configuration (parametersAsSources)
| Info |
|---|
Some injection rules provide the ability to behave differently depending on |
a configuration parameter: |
parametersAsSources This parameter makes the rule to consider the function/method parameters where the sink is contained as "sources". |
If parametersAsSources=trueIn this case, the rule performs a tainting path analysis to check if the parameters are neutralized since being received by the function/method until are consumed by the sink. If no neutralization is donefound, an injection vulnerability is raised. By default, this parameter is set to parametersAsSources=false.
Why should you change it to true ?
If your software being analyzed by Kiuwan is a complete application (i.e. it contains presentation plus logic and ddbb layers), you should let it be as false. This way, Kiuwan will make a full tanting path analysis over the whole application code.
But, if your software is a "library", i.e. a software component that will be used by 3rd parties to build their own applications, you should configure this property to true to detect injection flaws in your library code., making Kiuwan to perform that local tainting path analysis, thus guaranteeing that your library is protected against injection vulnerabilities regardless the usage by third parties.
As you can guess, setting to true and analyzing a complete application will result in a number of false positives.