Date: Thu, 28 Mar 2024 19:03:20 +0100 (CET) Message-ID: <10022236.1249.1711649000351@localhost> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1248_2124848659.1711649000350" ------=_Part_1248_2124848659.1711649000350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This section explains in detail how you can undestand a vulnerabilty as = reported by Kiuwan.
Contents:
The explanation is focused on injection-related vulnerabilities, as an e= xample of complex vulnerabilities.
We will first provide an overview of Tainted F= low Analysis (the theoretical basis behind the scenes),= and then we will focus on Kiuwan vul= nerability reporting.
The root cause of many security breaches is trusting u= nvalidated input:. This could be:
Source locations are those code places from = where data comes in, that can be potentially controlled by the user (or the= environment) and must consequently be presumably considered as tainted (it may be used to build injection attacks).
Sink locations are those code places where c=
onsumed data must not be tainted.
The goal of Tainted Flow Analysis
Prove, for all possible sinks, that tainted data will never be used wher= e untainted data is expected.
Kiuwan implements Tainted Flow Analysis by inferring flows in the = source code of your application:
When inferring flows from an untainted sink to a tainted source, K= iuwan can detect if any well-known sanitizer&nbs= p;is used, dropping those flows and thus avoiding to raise false vulnerabil= ities.
Kiuwan contains a built-in library of sanitizers for every support= ed programming language and framework.
These sanitizers are commonly used directly by programmers or by f= rameworks. And Kiuwan detects their use.
Vulnerabilities are reported under Code Securi= ty > Vulnerabilities.
All the vulnerabilities of the same type (i.e. coming from the same Kiuw= an rule that checks for it) are grouped under the Kiuwan rule name, indicat= ing how many files are affected and how many vulnerabilities were found.
For our explanation, we will follow an example based on Waratek =E2=80= =93 Spiracle software, focusing on SQL injection vulnerabilities.
Search for the SQL injection vulnerabilities by entering "SQL" in the Search by rule name field.
In this image, we can see that 2 files are affected: there is a sink tha= t is being fed tainted data. An injection point.
For every file there are a number of vulnerabillities:
Every vulnerability offers the possibility to view a graph view of all t= he propagation paths for this item.
Click the icon on the right:
The following graph will open:
Tainted data flows are represented as directed graphs f= rom sources (at the top) to sinks (at the bottom).
Any element may have a number that indicates in how many tainted data fl= ows it participates.
You can see the detail of any element (source, sink or propagation node)= by hovering the mouse overt it. A dialog will be displayed as in the image= below:
Clicking on the affected file will open all its affected sinks.
In this case, there=E2=80=99s only one sink for every file (only one inj= ection point), but it could be many. Kiuwan will display all the line numbe= rs of the affected sinks.
If you want to see a graphical view of all the sources,= sinks and tainted data flows for a file you can also clic= k on the icon.
And the following graph will be displayed:
Clicking a sink displays its details as well as all the sources where data is collected from an untrusted source a= nd flows to the sink without being neutralized (or sanitized).
Sink data
The sink details include the following information:
Most commonly, every source will be a different file. But depending on t= he flow path, you could find same source and line many times.
Let=E2=80=99s see how to understand every source.
Clicking on a source will open a frame with its detailed information.
Source data
Source detail includes following information:
Propagation Path
<= /span>Important: You should not understand the propagation p= ath as a typical stack of method calls. It=E2=80=99s not that= .
You should understand it as a data-flow path.
Let=E2=80=99s look at the following example:
You can also view it in graphical mode:
<= /p>
Any propagation path is composed of a source no= de, a sink node and as many propagation n= odes as different methods are involved in the propagation path.
In the example, we can see the next propagation path (flowing from sourc= e to sink):
Let=E2=80=99s go back to the initial sink information.
As said above, for every sink there will appear the list of sources that= are =E2=80=9Cfeeding=E2=80=9D that sink.
But you might be wondering why there are 5 sources with the same fi= le name and line.
We=E2=80=99ve selected this specific example to show something that coul= d happen in your own code. Let=E2=80=99s explore the second source into det= ail.
In the 2nd source you can see that the propagation nodes are = different from the previous one.
While in the 1st the propagation it was through Delete_Us= er.java, in the 2nd, it goes through a different file: = Insert_Raw_Text.java.
Reminder sources for the same sink show that there are still other diffe= rent propagation paths between the same source and the sink.
This example is a special case where the call sequence consists of 5 ser= vlets calling a utility (ParameterNullFix.sanitizeNull(..)) to rec= over some request parameters, building an SQL sentence with this tainted da= ta and sending the SQL sentence to another utility (UpdateUtil.executeU= pdate(=E2=80=A6) ) to execute the database update.
This is the reason Kiuwan shows one sink with 5 different sinks. That di= fference is because the propagation paths are through the different servlet= s. 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.
As a summary, you can understand any injection vulnerability as a unique= propagation path from source to sink, regardless of whether source and sin= k are the same.
A vulnerability= 's data path information is complementary to its propagation path. Although= they may similar, the data path adds detailed information on how the data = flows through your code making it vulnerable.
A data path is composed of a series of steps that show = how tainted data flows through the source code.
The data path shown in the example consists of (from source to sink):
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". And sources are always = being considered as "tainted".
If parametersAsSources=3Dtrue, the rule performs a= tainting path analysis to check if the parameters are neutralized since be= ing received by the function/method until are consumed by the sink. If no n= eutralization is found, an injection vulnerability is raised. By de= fault, parametersAsSources=3Dfalse.
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 b= e as false. In 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 wil= l be used by 3rd parties to build their own applications, you shoul= d configure this property to true, making Kiuwan perform that= local tainting path analysis, thus guaranteeing that your library is prote= cted against injection vulnerabilities regardless the usage by third partie= s.
As you can guess, setting to true and analyzing a complete application w= ill result in a number of false positives.