« Web Application Security Scanner Evaluation Criteria v1.0 released! | Main | Why Your Static Analysis Scanner Should Use String Analysis »

November 13, 2009


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


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".

The comments to this entry are closed.

Follow us on Twitter

AppScan Free Trial

Try IBM Security AppScan software at no charge.

Become a Fan