6

Our application is being dinged several hundred times CWE-ID 100 "flaws" related to Technology-Specific Input Validation Problems according to Veracode.

According to their docs, the remediation is to check the ModelState.IsValid property on a model before using it. We do this on every controller action yet we are still dinged. An example controller action follows.

public async Task<ActionResult> DeliverySummary (ReportsViewModel Model)
{
    if (ModelState.IsValid)
    {
        /* Other processing occurs here */ 

        //finally return View
        return View(Model);
    }
    else 
    {
        return View();
    }
}

We have the System.ComponentModel.DataAnnotations on our model properties.

Has anyone ever encountered this?

adiga
  • 34,372
  • 9
  • 61
  • 83
mituw16
  • 5,126
  • 3
  • 23
  • 48
  • Post your model properties & which properties dinged CWE problem. I searched similar problem on SO and just found single entry here: https://stackoverflow.com/questions/44289347/veracode-throws-technology-specific-input-validation-problems-cwe-id-100-for. – Tetsuya Yamamoto Jun 08 '17 at 02:49
  • 1
    Our view models are huge..Do you want to see the entire thing? They did not say which properties dinged the scan results. That's the entire problem here.. I don't know what they're dinging us for :/ – mituw16 Jun 08 '17 at 11:38

1 Answers1

5

I've been dealing with this myself. The basic culprit is you don't have [Bind] set on your argument, specifying the properties that are allowed.

My old sign-in controller action was like this

public ActionResult SignIn(SignInViewModel viewModel)

And to correct it, I need it to read like this

public ActionResult SignIn([Bind(Include = "Email,Password,UtcOffset")]SignInViewModel viewModel)

What this says to MVC is only the properties Email, Password and UtcOffset will be read from SignInViewModel, so if a hacker also set LastLogonTime it would be ignored.

As an aside, due to the security checks from Veracode, I'm thinking this kind of model-binding is now incredibly awkward, considering devs now have to keep strings in sync with prop names at the target. What a hassle.

Todd Sprang
  • 2,899
  • 2
  • 23
  • 40
  • 1
    I came across the `Bind` possible solution as well and implemented that on a few controller actions to test, but the "flaws" were still present in the scan results. We've opened a tech support ticket with veracode after one of their security techs found no problems with our code on a consultation call. He was baffled as to why we were being dinged. I'll post back what I hear once they figure this out – mituw16 Jun 13 '17 at 16:15
  • 1
    I also completely agree that having to add `Bind` to each and every controller action is incredibly clumsy. Almost all of the research I've done into this flaw in particular seems to revolve around Entity framework and direct db changes from your model that is passed into a controller. We don't use EF at all and have completely abstracted our DAL following a repository pattern with stored procedures. I wish Veracode's platform was smart enough to realize when EF is being used or not, and report EF "flaws" accordingly – mituw16 Jun 13 '17 at 16:18
  • @mituw16 did you hear back from veracode regarding your query? We are also facing same issue in our application. – hgarg Feb 13 '18 at 19:17
  • 1
    @hgarg I did actually, yes. They needed to make changes in their scanning engine. They had a problem in their scanning engine related to our use of an async controller action that was causing an issue.I finally noticed their scanners didn't have problems with non async controller actions. After we figured that out, they fixed a problem with their scanner engine and all was well. The entire process was honestly a huge run around that took almost 2 months to resolve before they *finally* admitted there was a bug in their engine. – mituw16 Feb 13 '18 at 19:47