Garrett wrote:
>proactively checking for NULL arguments and things
>like that, [...] we assume our API is used correctly
>and if it isn't then we'll fail soon enough when we dereferrence a
>NULL pointer.
Speaking from a security standpoint, this is not a sound policy. The API
represents a security boundary: you have no relationship with or control
over clients using the API. Not validating input coming across the
security boundary puts the system at risk for attack, whether unwitting
or malicious.
There is a world of difference between returning an error from an
incorrectly used API and allowing a null pointer to be dereferenced. The
latter causes the process to terminate, and that is not desirable
behavior for a server. Allowing one user to deprive all other users of
the server will at least tick off the users, and in the hands of a Bad
Guy (TM) allows him stage a denial of service attack.
I'd also question that, in general, allowing the system to fail means
that it will indeed fail "soon enough". What guarantees that "soon
enough" will happen too late, say after something more dire than
terminating the server? What is to say that this can never lead to data
corruption, arbitrary code execution, etc.? The literature on security
and threat modeling [1] says that this laissez-faire approach to
validation is not adequate or appropriate.
The "Ping Of Death" [2] is a classic example of cost of not validating
input. It allowed remote users to bring down a range of systems
(Solaris, Mac, Windows, Linux, etc.) from the command line knowing only
the system's IP address. There is no shortage of other examples.
So what is the benefit of not validating input in APIs?
Best regards,
Stuart
Stuart Celarier | Corillian Corporation
[1] E.g., http://www.insecure.org/reading.html
[2] http://www.ovb.ch/?http://www.ovb.ch/Ping/pod.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 16 02:28:05 2006