Crispin Cowan wrote:
> mikeiscool wrote:
>> On 7/17/06, Crispin Cowan <[EMAIL PROTECTED]> wrote:
>>> "supposed to" goes to intent.
>> I don't know. I think there is a difference between "this does what
>> it's supposed to do" and "this has no design faults". That's all I was
>> trying to highlight.
> The difference between "supposed to", "design flaw", and "implementation
> flaw" is entirely dependent on your level of abstraction:
>
> * Executive: "build a thingie that lets good guys in and keeps bad
> guys out."
> * Director: "build an authentication engine that uses 2-factor
> tokens to authenticate users and only then lets them in."
> * Manager: "use OpenSSL and this piece of glue to implement that
> 2-factor thingie."
> * Coder: "main() { ..." :)
>
> Errors can occur at any level of translation. When it does something
> "surprising", then the guy at the top can claim that it wasn't
> "supposed" to do that, and if you dig hard enough, you will discover
> *some* layer of abstraction where the vulnerability violates the upper
> intent, but not the lower intent. Hence the bug.
>
> Some example bugs at each level:
>
> * Executive: forgot to specify who is a "good guy"
> * Director: Forgot to provide complete mediation, so the attacker
> could bypass the authenticator.
> * Manager: the glue thingie allowed proper authentication tokens,
> but also allowed tokens with a string value of 0.
> * Coder: "gets(token); ..."
>
> Crispin
>
Yep...there are plenty of things that can go wrong. There are also plenty of
rather clever attacks. Designing a system requires much more complete thought
and a comprehensive viewpoint to have a hope...
As one very very minor example consider:
Authentication only for a payment rather resembles a check with only a
signature.
Glenn Everhart
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
