Technical & Logical Vulnerabilities == Design & Implementation Vulnerabilities

Hi,

While at the OWASP DC conference, an interesting thought came to me, which I’d like to hear people’s opinion about. So you all probably know about technical vs. logical vulnerabilities, right? I think it was Jeremiah Grossman who came up with this classification. Anyway, while thinking about this classification, I noticed that (almost) all technical vulnerabilities stem from insecure software implementation and (almost) all logical vulnerabilities, stem from insecure software design and/or architecture. If you think about it some more, most technical vulnerabilities, are fixed by repairing your code, and most logical vulnerabilities, are fixed by applying secure design patterns (fixing your design), or modifying your architecture to be more secure.

So, IMHO:

Technical vulnerabilities == Implementation vulnerabilities

Logical vulnerabilities == Design & Architecture vulnerabilities

What do you think? I’d love to hear your comments.

Comments

[Jeremiah Grossman]

Arian Evan's has also said as much in the past that this would (have) made a better terminology description. Easier to understand.

[Arian Evans]

Nice analysis. Fully agreed. I'm glad you are finally catching up with me :) (j/k)

I label these in talks:

1. Syntax Attack Issues

vs.

2. Semantic (Semantic entailment & Workflow issues)

Jer and I have been discussing this for years. I think there is probably a better phrasing than I use, since no one understands mine, and everyone groks Jer's explanation. But I've noticed even on the WASC list people have started using the phrase "Syntax Attacks" for technical vulns in the way I've been using it the last few years.

Basically Syntax Attacks aka "technical" vulns are mostly implementation issues with the code that we identify by their ability to be attacked by injecting rogue code or metacharacters that some layer of the app interprets in an "additive" behavioral fashion. At the code level these are almost always errors of "commission" or explicit mistake in coding.

Notable exceptions: There are cases - like an app with global Sql injection that are arguably a Design Issue with the data access layer. Distinguishing from Design-to-Implementation at a syntax level can quickly become a slippery slope (up and down) which is why I stay away from a hard line of calling these Implementation vs. Design issues. Years ago I used this notion but I found that it led to ugly endless debates with developers and architects I worked with, so I avoid it today.

Semantic Weakness Exploits aka "Business logic" vulns are attacks that leverage code or functionality that is already in the application. The attacker simply makes it execute in a manner unintended or unforseen by the Designer(s). These are usually errors of omission in the design or specification. By this I mean that most features in an application have a *clear* semantic notion of workflow, use-case, and privilege entailment inherent in their Design. The problem arises when the business or the Designer specifies a feature, but forgets to specify enforcing "only" the specification. If (this) Then (this) And (ONLY this).

Example: a feature specifies that Rob and Sally should both be able to receive custom coupon codes for discounts through the application, and the degree of discount is tied to a unique customer status (each gets different discounts). But the designer fails to specify that ONLY Rob can use Rob's coupon codes (AuthC and/or Z requirements) and vice-versa. So now, if Sally can figure out Rob's coupon code (AuthZ), she can get a better (or worse) discount. Or perhaps an anonymous entity can steal Rob's coupon codes, or fuzz them out of the application (AuthC). Etc.

Usually the Design intention (in this case AuthC/Z requirements) is clear from the use-case of the app. In the case above the specification omitted an "ONLY" regarding the distribution and enforcement control of the coupon discount mechanism. It was there and implied even though they failed to explicitly define it in the specification. So at Implementation time the developer omitted any form of security controls to enforce ONLY the intended use-case.

Make sense?

[Ory Segal]

Hmmm, I agree that things are not clear cut with regards to Design vs. Implementation, but I still prefer to avoid the (overloaded) term "Semantic".