[Owasp-testing] Can you please give me some guidence on the Business Logic Section?

Andrew Muller andrew at ionize.com.au
Sun Jan 6 22:16:29 UTC 2013


I like Marco's approach. I note that many of the concepts we're talking about (permission boundaries and boundary value analysis) are the domain of functional testers. Should we try to draw a line in the sand between us and them for this version of the Testing Guide to avoid duplication or just go for it? 

----- Original Message -----

From: "James McGovern" <james.mcgovern at hp.com> 
To: "marco m morana" <marco.m.morana at gmail.com>, "Andrew Muller" <andrew at ionize.com.au> 
Cc: owasp-testing at lists.owasp.org 
Sent: Sunday, 6 January, 2013 3:14:23 AM 
Subject: RE: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 



I agree with Marco that misuse and abuse cases should be captured, analyzed and used to get at some aspects of business logic attacks. I would also say that the notation of UML is somewhat weak in describing attacks that are based on either “order” or “concurrency” and therefore we may need to go a little deeper in our guidance. 
  
In thinking about automation, I think I would clarify my response to say that there is value in using it, for example in driving load, etc. The thing I think I would emphasize is that automation doesn’t really have the ability to always provide the idiot light to blink in that it may not detect anything is wrong. 
  
I think our guidance should align somewhat with the architecture-style chosen by the application. Consider the scenario where you have a dumb front end that calls a service orchestration. From an IT perspective, developers may technically make a “service” stateless, but from a business process perspective may still have state. What happens if service A runs before service B, etc. Another dimension that is frequently ignored is time. What if I find a way to delay execution of a given service without altering either its request or response. This could be highly useful if I want to front-run a few trades on Wall Street for example. 
  
Another architecture style may be if the application leverages a business rules engine. Consider the scenario of someone wanting to get cheaper auto insurance and wants to get the Gecko to give them more than 15%. An attacker would for gaps in logic where they may be flawed logic in how drivers are classified: 
  
               Noobs: 18 to 25  - Add on 88% 
               Average 27 to 34 – Add on 44% 
               Mature 35 to 55 – Add on 33% 
               Old Fars 56 and older – Add on 77% 
  
Notice that I skipped the 26 year old. So, finding this type of scenario could be uncovered by doing all permutations of low value to high value and looking for data response outliers vs just response codes. 
  
In the above, it is important to know that the business logic is actually public. Within insurance, it is known as a rate filing and therefore discoverable by someone who wants to exploit it. I think I am saying that we also need to have definitions that understand who has access to what beyond the typical implementation-level of access control. 
  


From: marco.m.morana at gmail.com [mailto:marco.m.morana at gmail.com] 
Sent: Saturday, January 05, 2013 10:04 AM 
To: Andrew Muller 
Cc: McGovern, James; owasp-testing at lists.owasp.org 
Subject: Re: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 
  

A possible way to test for business logic flaws is to derive abuse cases from business logic use cases, data flow analysis and business transaction analysis. The key is model threats, business logic attacks and vulnerabilities that can be exploited. Common application vulnerabilities such as forceful browsing, privilege escalation because of lack of enforcement of role base controls as well business logic design flaws in enforcement of strict business logic rules can be exploited  by business logic attacks. Understanding the business logic of the application is critical to derive a set of test cases for identifying business logic flaws. Ideally abuse of business logic should also be reviewed during design and coding as long as the business rules can be reviewed and tested at these stages of the implementation of the application. From security testing perspective you can also think about deriving a set of test cases after threat modeling an application and use and abuse cases have been identified. I have rationalized these ideas in this prezo I did some time ago: http://www.slideshare.net/marco_morana/issa-louisville-2010morana 

  

Regards,  Marco 


Sent from my iPad 


On 5 Jan 2013, at 09:26, Andrew Muller < andrew at ionize.com.au > wrote: 




Well put James. So would you suggest we include some advice to testers as to how they can engineer Business Process test cases based on Threat Modelling? 


----- Original Message -----


From: "James McGovern" < james.mcgovern at hp.com > 
To: "Jim Manico" < jim.manico at owasp.org >, "Andrew Muller" < andrew at ionize.com.au > 
Cc: owasp-testing at lists.owasp.org 
Sent: Saturday, January 5, 2013 1:15:36 AM 
Subject: RE: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 

The challenge of automation is a failure in how testing tools operate. Most tools are wired about the notion of point, shoot, aim and have no understanding of the business process itself. One thing I observed as an employee of The Hartford was how QA folks would recreate the same test case hundreds of times just so it could fit into the testing tool paradigm. For example, hundreds of applications all used say Siteminder that bound to Active Directory. So, authentication is something that should be done once provided it is implemented consistently and reused in multiple places. 

Functional test tools unlike web vulnerability scanners are taking a step in aligning with the notion of business process testing. HP and others in the functional test tool world are releasing functionality in order to enable. See: http://www8.hp.com/us/en/software-solutions/software.html?compURI=1174789#.UObjK3ca7aE 

One dimension of testing that I think we should noodle is to not be caught up in just testing of code. While OWASP is developer-centric, we shouldn't be developer-only. If we start with the mindset of automation against code vs starting with the mindset of finding weaknesses in how business processes are defined, we aren't doing the ultimate job of protecting the business. One way to find weaknesses in business processes is through threat modeling where we could provide guidance on identifying invariants, processes run out of sequence, etc 

-----Original Message----- 
From: owasp-testing-bounces at lists.owasp.org [ mailto:owasp-testing-bounces at lists.owasp.org ] On Behalf Of Jim Manico 
Sent: Thursday, January 03, 2013 7:18 PM 
To: Andrew Muller 
Cc: owasp-testing at lists.owasp.org 
Subject: Re: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 

The problem with business logic flaws is that they are often part of a complex multi-step workflow that can be difficult to automate. 

- Jim 


> There is also the other question raised by David, which relates to how we write test cases. A test case should simple and testable. The most understandable security test cases are those that test for a specific vulnerability or class of vulnerabilties. The more specific, the less confusion for the tester and the application owner when they receive the report. 
> 
> regards, 
>   Andrew 
> 
> 
> ----- Original Message ----- 
> 
> From: "Eoin" < eoin.keary at owasp.org > 
> To: "James McGovern" < james.mcgovern at hp.com > 
> Cc: "David Fern" < dfern at verizon.net >, "Andrew Muller" 
> < andrew at ionize.com.au >, owasp-testing at lists.owasp.org 
> Sent: Friday, 4 January, 2013 4:12:29 AM 
> Subject: Re: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 
> 
> 
> Business logic testing/verification: 
> ensure the app only does what is is designed to do and nothing more. 
> Anything more (which it was not designed to do) may introduce a 
> security issue as it breaks the business process the software was 
> designed to reflect. - owasp code review guide v2 2013 
> 
> 
> 
> Eoin Keary 
> Owasp Global Board 
> +353 87 977 2988 
> 
> 
> 
> On 3 Jan 2013, at 12:46, "McGovern, James" < james.mcgovern at hp.com > wrote: 
> 
> 
> 
> 
> 
> 
> I think the challenge is observing the fact that the phrase: Business Logic is heavily overloaded in all of the three links provided. The traditional "infosec" view defines a lot more things under the business logic banner than say a traditional software view would do. 
>   
> May I propose that we focus our usage of the term towards concepts of the business domain itself? For example, if you are developing an insurance quoting application, the business logic would be comprised of the rules and calculations required to price a combination of drivers and vehicles. The stuff regarding AuthN, AuthZ, etc would be outside of it. 
>   
> If you look at calculations for say taxes, we would then test for invariants. This could include looking at how validation is handled, the order in which processes/steps are executed and of course transactional considerations (e.g. ACID). 
>   
> 
> 
> From: owasp-testing-bounces at lists.owasp.org [ 
> mailto:owasp-testing-bounces at lists.owasp.org ] On Behalf Of David Fern 
> Sent: Thursday, January 03, 2013 6:38 AM 
> To: Andrew Muller 
> Cc: owasp-testing at lists.owasp.org 
> Subject: Re: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 
>   
> 
> 
> Here is where the lists came from and I like them: 
> 
>     Business Logic CWES - 
> http://cwe.mitre.org/data/definitions/840.html 
> 
>     7 Business Flaws - 
> https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf 
> 
>     Busines Logic Attack Vectors - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/       
> 
> The "Propoposed" came from - https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents  and this is what I thought I was to write to but then I started researching and found the other three. 
> 
> I am just not clear on which type of list I should use for the driving force of this section: the weaknesses(CWE), how to test, or risk   
> 
>   
> 
> What fits the guide best? 
> 
>   
> 
> I think once I get the groups thoughts on which way to go the other catagoies will be added in infomation and I can look through and use other related parts of the TOC as you indicated.     
> 
>   
> 
> Any thoughts?   
> 
>   
> 
> I like this section but an having trouble organizing. 
> 
>   
> 
> Thanks, 
> 
> David :) 
> 
> 
> 
> From: Andrew Muller < andrew at ionize.com.au > 
> To: David Fern < dfern at verizon.net > 
> Cc: owasp-testing at lists.owasp.org 
> Sent: Wednesday, January 2, 2013 8:22 PM 
> Subject: Re: [Owasp-testing] Can you please give me some guidence on the Business Logic Section? 
>   
> 
> 
> 
> 
> Hi David, 
> 
>   Looks like a great compilation of business logic weaknesses and attacks. How did you derive the list from each of the four sources? i.e. why did you pick those weaknesses from the CWE? 
> 
>   
> 
> My comments are: 
> 
> 1) there is a lot of commonality between the four sources (as well as other areas within the Test Guide TOC, e.g. weak password recovery, see 4.4.11). Reconciling these will reduce the length of the list. 
> 
> 2) some of the sources have different functions. CWE identifies a weakness that we can test for, the Business Logic Attack Vectors mostly identifies how these can be tested, and the Business Flaws mostly highlights the high level risks to the business if the vulnerability exists and is exploited. However, as some of the sources appear to be cross purpose, this isn't consistent. 
> 
> My understanding of how you add them to the TOC is to just add them and see if anyone argues :) However, a more active discussion of each section would be good too. 
> 
>   
> 
> regards, 
> 
>   Andrew 
> 
> 
> From: "David Fern" < dfern at verizon.net > 
> To: owasp-testing at lists.owasp.org 
> Sent: Thursday, 3 January, 2013 11:55:37 AM 
> Subject: [Owasp-testing] Can you please give me some guidence on the        Business Logic Section? 
> 
> 
> Can you please give me some guidence on the Business Logic Section? 
> 
> 
> 
> 
> 
> 
>   
> 
> I have done alot of research and come up with teh attached spread sheet and 4 different lists of Busines Logic issues. 
> 
>   
> 
> I have not been able to easily combine them. 
> 
>   
> 
> Should I just write to your list? 
> 
>   
> 
> Do I create a separate page for each?   
> 
>   
> 
> Any ideas/thoughts? 
> 
>   
> 
> Thanks, 
> 
> David 
>   
> 
> _______________________________________________ 
> Owasp-testing mailing list 
> Owasp-testing at lists.owasp.org 
> https://lists.owasp.org/mailman/listinfo/owasp-testing 
>   
>   
> 
> 
> <blockquote> 
> 
> _______________________________________________ 
> Owasp-testing mailing list 
> Owasp-testing at lists.owasp.org 
> https://lists.owasp.org/mailman/listinfo/owasp-testing 
> 
>  
> 
> 
> 
> 
> _______________________________________________ 
> Owasp-testing mailing list 
> Owasp-testing at lists.owasp.org 
> https://lists.owasp.org/mailman/listinfo/owasp-testing 
> 

_______________________________________________ 
Owasp-testing mailing list 
Owasp-testing at lists.owasp.org 
https://lists.owasp.org/mailman/listinfo/owasp-testing 
  
</blockquote>

<blockquote>


_______________________________________________ 
Owasp-testing mailing list 
Owasp-testing at lists.owasp.org 
https://lists.owasp.org/mailman/listinfo/owasp-testing 
</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-testing/attachments/20130107/0271b8c7/attachment-0001.html>


More information about the Owasp-testing mailing list