5

We use Acunetix at work to do security scans on our applications. Recently we came across the following Integer Vulnerabilities error below:

Integer Vulnerabilities

From what I can tell, it looks like the report is telling us that we are not stopping integer overflow attacks within querystrings. While we do use querystrings that eventually resolve to integers, they are first encrypted and then decrypted and converted to int using Convert.ToInt32() before we use them. I know that we should use TryParse() instead, but even if a hacker were to enter an integer value higher than max, they would fail when trying to decrypt before even trying to convert to integer, which is where the integer overflow would occur in my opinion. That is unless the error happens when the decryption fails?

I'm pretty confused about this and google searches haven't been much help as most pertain to unmanaged languages like c++ rather than c# and asp.net. Any help would be much appreciated.

ryanulit
  • 4,983
  • 6
  • 42
  • 66
  • 5
    IMO, this is where automated scans fail. In a similar vein ReSharper reports a lot of things as warnings and errors that an adept developer knows are nothing to worry about. From your explanation you're covered. – Yuck Jul 29 '11 at 19:53
  • 3
    Unless your encryption is HMAC signed and you validate the digest before parsing the input you're widely exposed. Encryption on its own does not detect/prevent tampering. – Remus Rusanu Jul 29 '11 at 20:02

1 Answers1

3

I don't think this is an integer overflow vulnerability, I suspect it refers to integers as this is the type that has been manipulated in the querystring (although I know you said they were encrypted). If you're doing a direct conversion of untrusted user input to an integer and not first validating the type (as you say, TryParse it first), you're probably going to throw an internal error (short of any try/catches) and this is what they're likely picking up on.

Automated scanners go a bit nuts over HTTP 500 errors. They don't know what's actually happening under the covers and how severe the error is so you could argue that it's a false-positive. On the other hand, your security folks will argue that websites readily returning HTTP 500 are more likely to be probed further if a bot picks up that you're regularly throwing these errors out as a result of manipulated querystrings.

Easy answer: "All input must be validated against a whitelist of acceptable value ranges." (from here).

Troy Hunt
  • 20,345
  • 13
  • 96
  • 151