>>We need a paradigm shift in programming from "allow all but the
>>known bad" to "disallow all but the known good", don't we?
>
>
> We need a little bit more than that, because our understanding of
> "what's bad" increases with time, and that frequently reduces the set
> of "what's good."
Yes.
But wrongly rejecting good input has no security implications.
But wrongly accepting bad input has.
> Unfortunately, it was subject to a CRLF injection vulnerability, which
> was not publicly known at the time the application had been developed.
> And the CRLF injection attack normally would not have worked thanks to
> the app's design, except the web application had a "feature" (perhaps
> accidental) in which a customized control file could define new fields
> that should have been labeled immutable, but were not.
But this is a case of wrongly accepting bad input.
Only accepting known good inputs would reject CRLF...
> As a different example, consider directory traversal issues in which
> ".." sequences are separated by illegal characters that are filtered
> out only *after* the ".." check is performed. The process goes like:
>
> 1) Software checks for ".." sequences and generates an error if any
> are found
> 2) Software cleanses and canonicalizes the input
>
> Such software could be subject to directory traversal via a ".|."
> sequence that isn't found in step 1, but the "|" gets removed in step
> 2; or maybe a "%2e%2e" URL encoding would work.
Here we have 2 problems:
1. The processing of the input was done in the wrong order.
2. The software shold not filter out illegal input,
but reject it.
With that the order of the input processing would not matter
You have to:
1. cannonilaize the input
2. check for any not allowed characters
3. check for ".." sequences.
And all 3 steps should generate an error
if something illegal was found.
> While this may be an example of an "allow all but known bad" approach,
> there are also lessons to be learned about designing the software so
> that security-sensitive operations are performed in the proper order.
Yep.
> In addition, there's a need to know and explicitly model which
> vulnerabilities a piece of data may be exposed to at different points
> in time. It's not just "known good," it's "known good under a
> specific context at a specific time."
I don't think we should primarily look for vulnerabilities,
but we all should spend more time on the definition of allowed input
and reject all that is not in these limits.
Steven M. Christey wrote:
> Paul Schmehl said:
>>We need a paradigm shift in programming from "allow all but the
>>known bad" to "disallow all but the known good", don't we?
>
>
> We need a little bit more than that, because our understanding of
> "what's bad" increases with time, and that frequently reduces the set
> of "what's good."
Yes.
But wrongly rejecting good input has no security implications.
But wrongly accepting bad input has.
> Unfortunately, it was subject to a CRLF injection vulnerability, which
> was not publicly known at the time the application had been developed.
> And the CRLF injection attack normally would not have worked thanks to
> the app's design, except the web application had a "feature" (perhaps
> accidental) in which a customized control file could define new fields
> that should have been labeled immutable, but were not.
But this is a case of wrongly accepting bad input.
Only accepting known good inputs would reject CRLF...
> As a different example, consider directory traversal issues in which
> ".." sequences are separated by illegal characters that are filtered
> out only *after* the ".." check is performed. The process goes like:
>
> 1) Software checks for ".." sequences and generates an error if any
> are found
> 2) Software cleanses and canonicalizes the input
>
> Such software could be subject to directory traversal via a ".|."
> sequence that isn't found in step 1, but the "|" gets removed in step
> 2; or maybe a "%2e%2e" URL encoding would work.
Here we have 2 problems:
1. The processing of the input was done in the wrong order.
2. The software shold not filter out illegal input,
but reject it.
With that the order of the input processing would not matter
You have to:
1. cannonilaize the input
2. check for any not allowed characters
3. check for ".." sequences.
And all 3 steps should generate an error
if something illegal was found.
> While this may be an example of an "allow all but known bad" approach,
> there are also lessons to be learned about designing the software so
> that security-sensitive operations are performed in the proper order.
Yep.
> In addition, there's a need to know and explicitly model which
> vulnerabilities a piece of data may be exposed to at different points
> in time. It's not just "known good," it's "known good under a
> specific context at a specific time."
I don't think we should primarily look for vulnerabilities,
but we all should spend more time on the definition of allowed input
and reject all that is not in these limits.
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
[ reply ]