Can other datatypes than Strings be potentially harmful if obtained from external sources?

Question

It's a well known truth, that you don't can trust user inputs. These inputs can be even an security-problem, if they are used unfiltered. XSS and SQL-injections are possible problems coming from using unfiltered user-input (or input, that can be changed by the user).

To avoid such problems, you have to control all strings, that can be influenced by external resources. Perl supports this with it's 'Taint-mode'.

The problems I know about, all are arising from manipulated Strings. Are you know examples of security-problems coming from ints, floats etc. manipulated by external influences? Or can this datatypes assumed to be safe?

Answer 1

Ultimately, all values are passed as strings to your program, whether you eventually convert them or not. All should be seen as potentially harmful, and not just for this reason.

For example, if you put non-numeric characters in a number field, you can get a parsing error. If you put a zero in where it isn't anticipated, you can get a divide by zero error. If you put a much larger value in than is expected, or a negative when not expected, or any number of other things, you can get an error of some sort. And it is quite possible for system errors to leak more information than you want. For instance, in an ASP.NET application, if custom errors aren't turned on, then database connection information, physical path information or information on third part libraries that your site uses can be leaked in the default error messages.

Strings are probably more likely to be problems than other values, but all user input should be treated as potentially harmful.

Answer 2

No, you can have security problems arising from accepting numbers from an external source. If an external source gives you a number of elements in (say) an array that you will need to process, a large number, trusted blindly, can cause denial of service by allocating enough memory to cause slow-down or memory exhaustion. Conversely, if you accept too-low a number and blindly continue reading more elements than you've allocated storage for, you can cause stack or heap over-writes.

Answer 3

It's not the datatypes that would be safe or not -- it's the code underneath that determines this.

That said, strings generally cause problems because of either buffer overruns or injection-style attacks against some underlying interpreter (SQL or some scripting language). You won't see these kinds of problems from numeric-type variables, obviously.

What you can have happen are bugs relating to bad external values which could lend themselves to something like a denial-of-service attack.

Answer 4

You should never trust any data that crosses a trust boundary.

A trust boundary occurs when one component doesn't trust the component on the other side of the boundary. There is always a trust boundary between elements running at different privilege levels, but there sometimes are trust boundaries between different components running at the same privilege level.

Threat Modeling, once again - Larry Osterman

As described in The New Threat Modeling Process on the Microsoft Security Development Lifecycle (SDL) Blog, expanded on by Larry Osterman's series of articles on threat modeling (updated here) and demonstrated by his Threat Modeling Again, Presenting the PlaySound Threat Model post, anywhere data crosses a trust boundary you need to identify the possible threats.