[Owasp-leaders] Business Logic Cheatsheet
jim.manico at owasp.org
Thu Oct 24 14:41:33 UTC 2013
Interesting analysis. While I do not agree, I think your comments are fair.
I'll add a "counterpoint" section that describes your critique.
On Oct 24, 2013, at 9:38 AM, Jeff Williams <jeff.williams at owasp.org> wrote:
I think this is a worthy and important effort, and I appreciate the work so
far, but this draft mostly focuses on problems that are better suited to
remain in other categories. I apologize for the severe comment, but I would
delete 90% of what is in this cheatsheet and focus on the core problem and
To me, it's only a business logic problem if you have to know the business
rules in order to identify it. A business rule is like "only IRA holders
over age 55 can trade index funds." Notice that it's not about any
security mechanism. Instead, business logic vulnerabilities represent a
mismatch between business expectations and the application's code. You
can't find a business logic problem without first talking to the business
about their rules and understanding their business. Almost nothing in the
article really talks about this kind of problem.
I think it might help to quote the "Business Logic Vulnerability" page from
OWASP (2008) --
Most security problems are weaknesses in an application that result from a
broken or missing security control (authentication, access control, input
validation, etc...). By contrast, business logic vulnerabilities are ways
of using the legitimate processing flow of an application in a way that
results in a negative consequence to the organization. For example:
- Purchase orders are not processed before midnight
- Written authorization is not on file before web access is granted
- Transactions in excess of $2000 are not reviewed by a person
Many articles that describe business logic problems simply take an existing
and well understood web application security problem and discuss the
business consequence of the vulnerability. True business logic problems are
actually different from the typical security vulnerability. Here are some
examples of problems that are not business logic vulnerabilities:
- Performing a denial of service by locking an auction user's account
- Posting unvalidated input publically
- Cracking MD5 hashes
- Brute forcing a password recovery scheme
Too often, the business logic category is used for vulnerabilities that
can't be scanned for automatically. This makes it very difficult to apply
any kind of categorization scheme. Business logic problems are different
from authentication problems and every other category. There are many
signficant business logic vulnerabilities, but they are far less common
than the type of items in the OWASP Top Ten for example.
A nice rule-of-thumb to use is that if you need to truly understand the
business to understand the vulnerability, you might have a business-logic
problem on your hands. If you don't understand the business, you can't see
business logic flaws.
Again, I apologize for the harsh comment. I think this is important and we
should get it as good as we can.
On Wed, Oct 23, 2013 at 1:20 PM, Jim Manico <jim.manico at owasp.org> wrote:
> Hello folks,
> We just released a new cheatsheet, the business logic cheatsheet for
> developers. Kudos to Ashish Rao and David Fern for working on this together.
> Feedback is always appreciated.
> Jim Manico
> OWASP Board Member
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders