Are interchangeable types a security vulnerability? Are they good vectors for attack?

Question

Suppose you are given a python API:

def onArgumentReceived(x):
    doWhatever(x) # expects a unicode string

I am not a security expert by any stretch of the imagination, however on the face of this, without explicit checking, this just instinctively feels like an obvious place to find a vulnerability laid bare.

Whereas:

void onArgumentReceived( const QString &x )
{
    doWhatever(x); 
}

seems inherently safe because the static typing will prevent strange types being fed into the function.

• Am I right to assume the latter probably is more secure?
• Is the former a good place to discover vectors of attack?

Thanks.

Answer 1

If you're calling a Python API, you're already inside the security boundary. This cannot be a meaningful security risk. Only things from outside the program entirely count as security risks. Such as data from I/O.

What is more dangerous is implicit conversion. Automatically converting strings to numbers or boolean values. For example, this discussion of DOS and security issues arising from string to int conversions. Automatically converting "0" or "false" or "null" to 0 or false or null can cause problems.

See also NULL license plate

See also WAT

(more generally, to look for attack vectors, look over the list of CVEs and see what techniques come up again and again. Can you find one which relies on type confusion?)

Answer 2

Am I right to assume the latter probably is more secure?

This is the wrong question. First of all, there's no linear scale of security. There are approaches that are more robust to certain classes of errors. But an approach can be less vulnerable to one kind of attack and more vulnerable to another. That's why it's important to have some idea of your threat model.

Given that we don't know anything about the context of how the code would used it's impossible to say.

Consider a scenario, such as in a drag-and-drop interface where a type B ends up being passed into a function designed to work with type A. In Python that might 'work' and do something unexpected (perhaps completely benign) or it might fail because the type supplied doesn't support the necessary methods. In the alternate strong-typing path, let's assume a cast fails. All of these could represent security vulnerabilities and there's no way to say which is worse, in general.

The only thing I would say is that the scenario where passing the wrong type 'works' might present more interesting types of vulnerabilities than an exception/fault. The Log4Script vulnerability comes to mind. Generally speaking, it's better to crash than do something unknown and strong-typing can facilitate crashes. Strong-typing can also help protect against other programming errors. But it is not a panacea and thinking that it's better in general is wrong.

Is the former a good place to discover vectors of attack?

Perhaps but I would think it's better to take it up one level and look for ways you might end up with the wrong type of thing being passed into a method and how you can prevent that.

Answer 3

Am I right to assume the latter probably is more secure?

No, it is not "more or less secure", whatever that means.

If doWhatever interprets x as an sql string and runs it against a database without any previous validation, this would be a security risk, regardless if it is done in Python or C++, and the security risk would not be smaller in C++.

To be fair, as JimmyJames pointed out, passing a non-string into a function which expects a string in Python can have a certain risk of causing some unexpected behaviour, in case the function starts to iterate over the content of the string (or what it expects to be a string).

So in the end, it boils down to two things:

• what happens inside the function in stake?

• in what context is the function called, and is x some input created by an unreliable source?

Both questions are mostly language agnostic, and are not really restricted just by typesafety.