[langsec-discuss] Tainting input for better security
Michael E. Locasto
locasto at ucalgary.ca
Thu Jun 14 22:05:20 UTC 2012
On 6/14/12 3:05 PM, Carter Schonwald wrote:
>> What that means for me practically is that any input I have from the
>> client, in the form of headers, parameters, cookies or form fields,
>> should be automatically tainted by the system unless an appropriate
>> validator is found for it.
>> 1) Why don't all web frameworks do this out of the box?
How deeply do you want to track/propagate this taint into the
application logic? You'd need a part of the runtime system that does
this implicitly for most data movement, copy, and transformation
primitives. The performance impact may be prohibitive on a case-by-case
I suppose you're arguing for validation at the point of input, but I
suppose it is possible for two systems to be composed in such a way that
input D passes through the validation for the first system, is somehow
transformed by that system, and then is passed to the second system to
consume (and exploit). Alternatively, the composed & transformed input
could pass both validation phases, but still exercise a vulnerability
that emerges from the composition of the two systems.
I think internal processing has a tendency to diverge from the
validation logic, which is another potential source of failure.
>> 2) Why is validation in such a terrible state? It seems like people
>> just throw regexps at the problem and hope for the best.
Because a traditional CS undergraduate education introduces parsing in
the context of recognizing computer languages rather than validating
input arguments, function parameters, protocol messages, or file formats?
I know that before thinking deeply about langsec, I had a "natural" bias
to think about those sorts of inputs in terms of flat strings rather
than naturally recursive (or composed) structures.
More information about the langsec-discuss