This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 BusinessLogic

From OWASP
Revision as of 20:28, 30 March 2014 by Larry Conklin (talk | contribs) (Created page with " == 1. Business Logic Understanding == '''Why to understand Business Logic?''' A security review of the application should uncover the commonly known security flaws as well a...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

1. Business Logic Understanding

Why to understand Business Logic? A security review of the application should uncover the commonly known security flaws as well as the ones related to business logic of the application. And in order to enumerate the business logic flaws it is important to develop familiarity with its context/scope of the application.


What points do we need to understand?

The reviewer must develop familiarity with:
  • Application features and Business Rules: The reviewer must understand all the features of the application and capture all the business restrictions/rules related to them.
  • Sensitive Data: The reviewer should also make a note of all the entities like account numbers, passwords that are sensitive to the application. The categorizing the data entities based on their sensitivity will help the reviewer to determine the impact of any kind of data loss in the application.
  • User roles and access rights: It is important to understand the type of users allowed to access the application. Generally, an application that is accessible only for the internal users of an organization might be exposed to threats that are different than the one that is available for anyone on the Internet. Hence, knowing the users of the application and its deployed environment would allow the reviewer to realize the threat agents correctly. In addition to this, the different privileges levels present in the application must also be understood. It would help the reviewer to enumerate different security violations/privilege escalation attacks that can be applicable to the application.
  • Application type – It refers to understanding whether the application is browser based application, a desktop based standalone application, a web-service, a mobile applications or a hybrid application. Different type of application faces different kinds of security threats and understanding the type of the application would help the reviewer to look for specific security flaws, determine correct threats agents and highlight necessary controls suitable to the application.

2. Code Layout Understanding

Why to understand Application? It is required to understand the design and the architecture of the application before reviewing its code for security flaws. It would help the reviewer to understand the data flow for any feature, familiarize with all the entry and exit points present in the application and other integrations involved in it. A gist of all the components present in the application and the way they interact is helpful in threat modeling the whole system and defining a proper scope of the security review.

What points do we need to understand? One must understand:

  • Design: Generally applications have a well-defined code layout if they are developed using MVC design principle. Applications can have their own custom design or they may use some well-known design frameworks like Struts/Spring etc. The reviewer must understand the design of the application mainly with respect to the points listed below.