To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
Why you should check values of public m…

Why you should check values of public methods' parameters

Jun 11 2021

This note will answer the question - why PVS-Studio considers parameters of public methods potential sources of tainted data. The analyzer can issue warnings if such parameters haven't been checked before use.

0835_ParamsAsTaintSource/image1.png

The point is that undue confidence in external data may lead to various vulnerabilities - SQLI, XSS, path traversal and others. Most obvious examples of external data sources: parameter values of requests or text that a user enters (for example, in a text field).

Excessive trust in parameters of public methods can be even more dangerous. Public methods are the ones that can be called from other assemblies. For example, these are public methods of public classes. Most likely, such methods are APIs for interacting with the library.

So, what is the danger?

Developers who use library's APIs may expect data to be verified inside the called method. That's why data from an external source won't be checked before passing to it.

Developers of the library itself may assume that input data is already verified. Therefore, there is no need to check it.

Here's what we may eventually face with. Neither a library user, nor its developer has checked input data. This may lead to vulnerabilities when an attacker passes tainted data.

Note. Below are examples with V5608 diagnostic (search for possible SQL injections). This information relates to other OWASP diagnostics that also consider public methods to be potential sources of tainted data.

Let's see what it might look like in code:

public class DBHelper
{
  public void ProcessUserInfo(String userName)
  {
    ....
    var command = "SELECT * FROM Users WHERE userName = '" + userName + "'";
    ExecuteCommand(command);
    ....
  }

  private void ExecuteCommand(String rawCommand)
  {
    using (SqlConnection connection = new SqlConnection(_connectionString))
    {
      ....
      using (var sqlCommand = new SqlCommand(rawCommand, connection))
      {
        using (var reader = sqlCommand.ExecuteReader())
          ....
      }
    }
  }
}

The DBHelper class provides the ProcessUserInfo method for external use because the method is available from other assemblies. Note that this method's parameter - userName - is not checked before use. The external value is used to create the command directly (command variable). The resulting command is then passed to the ExecuteCommand method. There the command is used without a prior check to create an object of SQLCommand type.

In this case, if you take userName as a source of tainted data, the analyzer will issue a warning about a potential SQLI.

Look at a possible way to use the ProcessUserInfo method by an external application:

static void TestHelper(DBHelper helper)
{
  var userName = Request.Form["userName"];
  helper.ProcessUserInfo(userName);
}

The author of this code fragment might not have access to the DBHelper class code and will hope the data is verified inside the ProcessUserInfo method. Neither the current code, nor the ProcessUserInfo method has checked data. This means the application will be vulnerable to SQL injections.

The analyzer won't warn you about potential SQL injection when checking the TestHelper method's code. It is because the tool doesn't have access to the source code of the ProcessUserInfo method. As we see, the case is tricky, so we'd like to let you know about possible dangers beforehand.

Therefore, the analyzer will issue a warning where it will be able to do so. Which is, when analyzing the ProcessUserInfo method's source code. You will get the V5608 warning at the low certainty level.

If you'd like to rid yourself of such warnings, disable them using the comment //-V::5608:3 in the .pvsconfig file. This way, V5608 warnings (SQLI) of low certainty level won't be in the report. Read more about .pvsconfig files in the documentation (section "Suppression of false positives through diagnostic configuration files (.pvsconfig)").

On the other hand, you might want to set high certainty level for such warnings. If so, use the comment //V_LEVEL_1::5608. For details, see ''How to Set Your Level for Specific Diagnostics'' in the documentation.

Popular related articles
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept