Difference between revisions of "Testing for business logic"

From OWASP
Jump to: navigation, search
m (proofreading)
m (Andrew Muller moved page Testing for business logic (OWASP-BL-001) to Testing for business logic over redirect: Testing for business logic is now a chapter heading supported by several test cases rather than being the only test case.)
 
(84 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v4}}
{{Template:OWASP Testing Guide v2}}
 
  
== Brief Summary ==
 
  
Business logic comprises:
+
== Summary ==
* Business rules that express business policy (such as channels, location, logistics, prices, and products); and
+
 
* Workflows that are the ordered tasks of passing documents or data from one participant (a person or a software system) to another.
+
Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application's authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user. What happens if the user goes from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?
 +
 
 +
 
 +
There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, and usually application specific but, at the same time, usually one of the most detrimental to the application, if exploited.
 +
 
 +
 
 +
The classification of business logic flaws has been under-studied; although exploitation of business flaws frequently happens in real-world systems, and many applied vulnerability researchers investigate them. The greatest focus is in web applications. There is debate within the community about whether these problems represent particularly new concepts, or if they are variations of well-known principles.
 +
 +
 
 +
Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing. These types of tests require that security professionals think a bit differently, develop abused and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules.
 +
 
 +
 
 +
==Business Limits and Restrictions==
 +
 
 +
Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.
 +
 
 +
 
 +
Sometimes, in very complex applications, the tester will not have a full understanding of every aspect of the application initially. In these situations, it is best to have the client walk the tester through the application, so that they may gain a better understanding of the limits and intended functionality of the application, before the actual test begins. Additionally, having a direct line to the developers (if possible) during testing will help out greatly, if any questions arise regarding the application's functionality.
  
The attacks on the business logic of an application are dangerous, difficult to detect and specific to that application.
 
  
 
==Description of the Issue==
 
==Description of the Issue==
 
Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than is allowed? Or perhaps you are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently these business logic security checks simply are not present in the application.
 
  
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests.
+
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to completely subvert the application.
 +
 
 +
 
 +
'''Example 1''':
 +
 
 +
Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out? 
 +
 
 +
 
 +
'''Example 2''':
 +
 
 +
Holding/locking resources and keeping others from purchases these items online may result in attackers purchasing items at a lower price. The countermeasure to this problem is to implement timeouts and mechanisms to ensure that only the correct price can be charged.   
 +
 
 +
 
 +
'''Example 3''':
 +
 
 +
What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to their account cancel out of the transaction?  Will the points/credits still be applied to their account?
 +
 
 +
 
 +
==Business Logic Test Cases==
 +
 
 +
Every application has a different business process, application specific logic and can be manipulated in an infinite number of combinations. This section provides some common examples of business logic issues but in no way a complete list of all issues.
 +
 
 +
 
 +
'''Business Logic exploits can be broken into the following categories''':
 +
 
 +
[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]]
 +
 
 +
In business logic data validation testing, we verify that the application does not allow users to insert “unvalidated” data into the system/application. This is important because without this safeguard attackers may be able to insert “unvalidated” data/information into the application/system at “handoff points” where the application/system believes that the data/information is “good” and has been valid since the “entry points” performed data validation as part of the business logic workflow.     
 +
 
 +
 
 +
[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]]
 +
 
 +
In forged and predictive parameter request testing, we verify that the application does not allow users to submit or alter data to any component of the system that they should not have access to, are accessing at that particular time or in that particular manner. This is important because without this safeguard attackers may be able to “fool/trick” the application into letting them into sections of thwe application of system that they should not be allowed in at that particular time, thus circumventing the applications business logic workflow.
 +
 
 +
 
 +
[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]
 +
 
 +
In integrity check and tamper evidence testing, we verify that the application does not allow users to destroy the integrity of any part of the system or its data. This is important because without these safe guards attackers may break the business logic workflow and change of compromise the application/system data or cover up actions by altering information including log files. 
 +
 
 +
 
 +
[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]
 +
 
 +
In process timing testing, we verify that the application does not allow users to manipulate a system or guess its behavior based on input or output timing. This is important because without this safeguard in place attackers may be able to monitor processing time and determine outputs based on timing, or circumvent the application’s business logic by not completing transactions or actions in a timely manner.
 +
 
 +
 
 +
[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]
 +
 
 +
In function limit testing, we verify that the application does not allow users to exercise portions of the application or its functions more times than required by the business logic workflow. This is important because without this safeguard in place attackers may be able to use a function or portion of the application more times than permissible per the business logic to gain additional benefits.
 +
 
 +
 
 +
[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]
 +
 
 +
In circumventing workflow and bypassing correct sequence testing, we verify that the application does not allow users to perform actions outside of the “approved/required” business process flow. This is important because without this safeguard in place attackers may be able to bypass or circumvent workflows and “checks” allowing them to prematurely enter or skip “required” sections of the application potentially allowing the action/transaction to be completed without successfully completing the entire business process, leaving the system with incomplete backend tracking information. 
 +
 
 +
 
 +
[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]
 +
 
 +
In application mis-use testing, we verify that the application does not allow users to manipulate the application in an unintended manner.
 +
 
 +
 
 +
[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]
 +
 
 +
In unexpected file upload testing, we verify that the application does not allow users to upload file types that the system is not expecting or wanted per the business logic requirements. This is important because without these safeguards in place attackers may be able to submit unexpected files such as .exe or .php that could be saved to the system and then executed against the application or system. 
 +
 
 +
 
 +
[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]
 +
 
 +
In malicious file upload testing, we verify that the application does not allow users to upload files to the system that are malicious or potentially malicious to the system security. This is important because without these safeguards in place attackers may be able to upload files to the system that may spread viruses, malware or even exploits such as shellcode when executed.
 +
 
  
'''Business Limits and Restrictions'''<br>
+
==Tools==
  
Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.
+
While there are tools for testing and verifying that business processes are functioning correctly in valid situations these tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a user is able to circumvent the business process flow through editing parameters, predicting resource names or escalating privileges to access restricted resources nor do they have any mechanism to help the human testers to suspect this state of affairs.  
  
'''Example''': Setting the quantity of a product on an e-commerce site as a negative number may result in funds being credited to the attacker. The countermeasure to this problem is to implement stronger data validation, as the application permits negative numbers to be entered in the quantity field of the shopping cart.
 
  
==Black Box Testing and Examples==
+
The following are some common tool types that can be useful in identifying business logic issues.
  
Although uncovering logical vulnerabilities will probably always remain an art, one can attempt to go about it systematically to a great extent. Here is a suggested approach that consists of: 
+
'''HP Business Process Testing Software '''<br>
* Understanding the application
+
*http://www8.hp.com/us/en/software-solutions/software.html?compURI=1174789#.UObjK3ca7aE
* Creating raw data for designing logical tests
 
* Designing the logical tests
 
* Standard prerequisites
 
* Execution of logical tests
 
  
===Understanding the application===
 
  
Understanding the application thoroughly is a prerequisite for designing logical tests. To start with:
+
'''Intercepting Proxy - To observe the request and response blocks of HTTP traffic.'''<br>
* Get any documentation describing the application's functionality. Examples of this include:
 
** Application manuals
 
** Requirements documents
 
** Functional specifications
 
* Explore the application manually and try to understand all the different ways in which the application can be used, the acceptable usage scenarios and the authorization limits imposed on various users
 
  
===Creating raw data for designing logical tests===
+
*Webscarab - https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
  
In this phase, one should ideally come up with the following data:
+
*Burp Proxy - http://portswigger.net/burp/proxy.html
* All application '''business scenarios'''. For example, for an e-commerce application this might look like,
 
** Product ordering
 
** Checkout
 
** Browse
 
** Search for a product
 
* '''Workflows'''. This is different from business scenarios since it involves a number of different users. Examples include:
 
** Order creation and approval
 
** Bulletin board (one user posts an article that is reviewed by a moderator and ultimately seen by all users)
 
* Different '''user roles'''
 
** Administrator
 
** Manager
 
** Staff
 
** CEO
 
* Different '''groups or departments''' (note that there could be a tree (e.g. the Sales group of the heavy engineering division) or tagged view (e.g. someone could be a member of Sales as well as marketing) associated with this.
 
** Purchasing
 
** Marketing
 
** Engineering
 
* '''Access rights of various user roles and groups''' - The application allows various users privileges on some resource (or asset) and we need to specify the constraints of these privileges.  One simple way to know these business rules/constraints is to make use of the application documentation effectively.  For example, look for clauses like "If the administrator allows individual user access..", "If configured by the administrator.." and you know the restriction imposed by the application.
 
* '''Privilege Table''' – After learning about the various privileges on the resources along with the constraints, you are all set to create a Privilege Table. Get answers to:
 
** What can each user role do on which resource with what constraint?  This will help you in deducing who cannot do what on which resource. 
 
** What are the policies across groups?
 
  
<span style="display: block; margin-left: 15px;">Consider the following privileges: "Approve expense report", "Book a conference room", "Transfer money from own account to another user's account". A privilege could be thought of as a combination of a verb (e.g. Approve, Book, Withdraw) and one or more nouns (Expense report, conference room, account). The output of this activity is a grid with the various privileges forming the leftmost column while all user roles and groups would form the column headings of other columns. There would also be a “Comments” column that qualifies data in this grid.</span>
+
*Paros Proxy - http://www.parosproxy.org/
  
<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
 
{| class="wikitable" style="margin: 1em auto 1em auto"
 
| '''Privilege''' || '''Who can do this''' || '''Comment'''
 
|-
 
| Approve expense report || Any supervisor may approve report submitted by his subordinate ||
 
|-
 
| Submit expense report || Any employee may do this for himself ||
 
|-
 
| Transfer funds from one account to another || An account holder may transfer funds from own account to another account ||
 
|-
 
| View payslip || Any employee may see his own ||
 
|-
 
|}
 
</blockquote>
 
  
This data is a key input for designing logical tests.
+
'''Web Browser Plug-ins - To view and modify HTTP/HTTPS headers, post parameters and observe the DOM of the Browser'''<br>
  
===Developing logical tests===
+
*Tamper Data (for Internet Explorer) - https://addons.mozilla.org/en-us/firefox/addon/tamper-data/
 +
 +
*TamperIE (for Internet Explorer) - http://www.bayden.com/tamperie/
  
Here are several guidelines to designing logical tests from the raw data gathered.  
+
*Firebug (for Internet Explorer) - https://addons.mozilla.org/en-us/firefox/addon/firebug/ and http://getfirebug.com/
  
* '''Privilege Table''' - Make use of the privilege table as a reference while creating application specific logical threats. In general, develop a test for each admin privilege to check if it could be executed illegally by a user role with minimum privileges or no privilege.  For example:
 
** Privilege: Operations Manager cannot approve a customer order
 
** Logical Test: Operations Manager approves a customer order
 
  
* '''Improper handling of special user action sequences''' - Navigating through an application in a certain way or revisiting pages out of synch can cause logical errors which may cause the application to do something it's not meant to. For example:
+
'''Miscellaneous Test Tools'''<br>
** A wizard application where one fills in forms and proceeds to the next step. One cannot in any normal way (according to the developers) enter the wizard in the middle of the process. Bookmarking a middle step (say step 4 of 7), then continuing with the other steps until completion or form submission, then revisiting the middle step that was bookmarked may "upset" the backend logic due to a weak ''state model''.
 
  
* '''Cover all business transaction paths''' - While designing tests, check for all alternative ways to perform the same business transaction. For example, create tests for both cash and credit payment modes.
+
* Web Developer toolbar - https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
 +
The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.
  
* '''Client-side validation''' - Look at all client side validations and see how they could be the basis for designing logical tests. For example, a funds transfer transaction has a validation for negative values in the amount field.  This information can be used to design a logical test such as "A user transfers negative amount of money".
+
* HTTP Request Maker - https://chrome.google.com/webstore/detail/kajfghlhfkcocafkcjlajldicbikpgnp?hl=en-US
 +
Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests
  
===Standard prerequisites===
+
* Cookie Editor - https://chrome.google.com/webstore/detail/fngmhnnpilhplaeedifhccceomclgfbg?hl=en-US
 +
Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies
  
Typically, some initial activities useful as setup are:  
+
* Session Manager - https://chrome.google.com/webstore/detail/bbcnbpafconjjigibnhbfmmgdbbkcjfi
* Create test users with different permissions
+
With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e. the opened tabs and windows. Once a session is opened, the browser is restored to its state.
* Browse all the important business scenarios/workflows in the application
 
  
===Execution of logical tests===
+
* Cookie Swap - https://chrome.google.com/webstore/detail/dffhipnliikkblkhpjapbecpmoilcama?hl=en-US
 +
Swap My Cookies is a session manager, it manages your cookies, letting you login on any website with several different accounts. You can finally  login into Gmail, yahoo, hotmail, and just any website you use, with all your accounts; if you want to use another account just swap profile!
  
Pick up each logical test and do the following:
+
* HTTP Response Browser - https://chrome.google.com/webstore/detail/mgekankhbggjkjpcbhacjgflbacnpljm?hl=en-US
* Analyze the HTTP/S requests underlying the acceptable usage scenario corresponding to the logical test
+
Make HTTP requests from your browser and browse the response (HTTP headers and source). Send HTTP method, headers and body using XMLHttpRequest from your browser then view the HTTP status, headers and source. Click links in the headers or body to issue new requests. This plug-in formats XML responses and uses Syntax Highlighter < http://alexgorbatchev.com/ >.
** Check the order of HTTP/S requests
 
** Understand the purpose of hidden fields, form fields, query string parameters being passed
 
* Try and subvert it by exploiting the known vulnerabilities
 
* Verify that the application fails for the test
 
  
 +
* Firebug lite for Chrome - https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench
 +
Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties.
  
  
 
==References==
 
==References==
 +
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
* Business logic - http://en.wikipedia.org/wiki/Business_logic
 
* Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570<br>
 
  
'''Tools'''<br>
+
*Business Logic Vulnerabilities in Web Applications - http://www.google.com/url?sa=t&rct=j&q=BusinessLogicVulnerabilities.pdf&source=web&cd=1&cad=rja&ved=0CDIQFjAA&url=http%3A%2F%2Faccorute.googlecode.com%2Ffiles%2FBusinessLogicVulnerabilities.pdf&ei=2Xj9UJO5LYaB0QHakwE&usg=AFQjCNGlAcjK2uz2U87bTjTHjJ-T0T3THg&bvm=bv.41248874,d.dmg
 +
 
 +
*The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities - NISTIR 7864 - http://csrc.nist.gov/publications/nistir/ir7864/nistir-7864.pdf
 +
 
 +
*Designing a Framework Method for Secure Business Application Logic Integrity in e-Commerce Systems, Faisal Nabi - http://ijns.femto.com.tw/contents/ijns-v12-n1/ijns-2011-v12-n1-p29-41.pdf
 +
 
 +
*Finite State testing of Graphical User Interfaces, Fevzi Belli - http://www.slideshare.net/Softwarecentral/finitestate-testing-of-graphical-user-interfaces
 +
 
 +
*Principles and Methods of Testing Finite State Machines - A Survey, David Lee, Mihalis Yannakakis - http://www.cse.ohio-state.edu/~lee/english/pdf/ieee-proceeding-survey.pdf
 +
 
 +
*Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi -  http://homepages.cs.ncl.ac.uk/jeff.yan/TEL.pdf
 +
 
 +
*Securing Virtual Worlds Against Real Attack, Dr. Igor Muttik, McAfee - https://www.info-point-security.com/open_downloads/2008/McAfee_wp_online_gaming_0808.pdf
 +
 
 +
*Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security - https://www.whitehatsec.com/resource/whitepapers/business_logic_flaws.html
 +
 
 +
*Toward Automated Detection of Logic Vulnerabilities in Web Applications - Viktoria Felmetsger Ludovico Cavedon Christopher Kruegel Giovanni Vigna - https://www.usenix.org/legacy/event/sec10/tech/full_papers/Felmetsger.pdf
 +
 
 +
*2012 Web Session Intelligence & Security Report: Business Logic Abuse, Dr. Ponemon - http://www.emc.com/collateral/rsa/silvertail/rsa-silver-tail-ponemon-ar.pdf
 +
 
 +
*2012 Web Session Intelligence & Security Report: Business Logic Abuse (UK) Edition, Dr. Ponemon - http://buzz.silvertailsystems.com/Ponemon_UK.htm
 +
 
 +
 
 +
'''OWASP Related'''<br>
 +
 
 +
*Business Logic Attacks – Bots and Bats, Eldad Chai - http://www.imperva.com/resources/adc/pdfs/AppSecEU09_BusinessLogicAttacks_EldadChai.pdf
 +
 
 +
*OWASP Detail Misuse Cases - https://www.owasp.org/index.php/Detail_misuse_cases
 +
 
 +
*How to Prevent Business Flaws Vulnerabilities in Web Applications, Marco Morana -  http://www.slideshare.net/marco_morana/issa-louisville-2010morana
 +
 
 +
 
 +
'''Useful Web Sites'''<br>
 +
 
 +
*Abuse of Functionality - http://projects.webappsec.org/w/page/13246913/Abuse-of-Functionality
 +
 
 +
*Business logic - http://en.wikipedia.org/wiki/Business_logic
 +
 
 +
*Business Logic Flaws and Yahoo Games -  http://jeremiahgrossman.blogspot.com/2006/12/business-logic-flaws.html
 +
 
 +
*CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html
 +
 
 +
*Defying Logic: Theory, Design, and Implementation of Complex Systems for Testing Application Logic - http://www.slideshare.net/RafalLos/defying-logic-business-logic-testing-with-automation
 +
 
 +
*Prevent application logic attacks with sound app security practices - http://searchappsecurity.techtarget.com/qna/0,289202,sid92_gci1213424,00.html?bucket=NEWS&topic=302570
 +
 
 +
*Real-Life Example of a 'Business Logic Defect - http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581
 +
 
 +
*Software Testing Lifecycle - http://softwaretestingfundamentals.com/software-testing-life-cycle/
  
Automated tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a bank’s "fund transfer" page allows a user to transfer a negative amount to another user (in other words, it allows a user to transfer a positive amount into his own account) nor do they have any mechanism to help the human testers to suspect this state of affairs.
+
*Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
  
'''Preventing transfer of a negative amount''': Tools could be enhanced so that they can report client side validations to the tester. For example, the tool may have a feature whereby it fills a form with strange values and attempts to submit it using a full-fledged browser implementation. It should check to see whether the browser actually submitted the request. Detecting that the browser has not submitted the request would signal to the tool that submitted values are not being accepted due to client-side validation. This would be reported to the tester, who would then understand the need for designing appropriate logical tests that bypass client-side validation. In our "negative amount transfer" example, the tester would learn that the transfer of negative amounts may be an interesting test. He could then design a test wherein the tool bypasses the client-side validation code and checks to see if the resulting response contains the string "funds transfer successful". The point is not that the tool will be able to detect this or other vulnerabilities of this nature, rather that, with some thought, it would be possible to add many such features to enlist the tools in aiding human testers to find such logical vulnerabilities.
 
  
 +
'''Books'''
  
<br>
+
*The Decision Model: A Business Logic Framework Linking Business and Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC Press, ISBN1420082817 (2010)
{{Category:OWASP Testing Project AoC}}
 

Latest revision as of 07:29, 5 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Summary

Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application's authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user. What happens if the user goes from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?


There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, and usually application specific but, at the same time, usually one of the most detrimental to the application, if exploited.


The classification of business logic flaws has been under-studied; although exploitation of business flaws frequently happens in real-world systems, and many applied vulnerability researchers investigate them. The greatest focus is in web applications. There is debate within the community about whether these problems represent particularly new concepts, or if they are variations of well-known principles.


Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing. These types of tests require that security professionals think a bit differently, develop abused and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules.


Business Limits and Restrictions

Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application.


Sometimes, in very complex applications, the tester will not have a full understanding of every aspect of the application initially. In these situations, it is best to have the client walk the tester through the application, so that they may gain a better understanding of the limits and intended functionality of the application, before the actual test begins. Additionally, having a direct line to the developers (if possible) during testing will help out greatly, if any questions arise regarding the application's functionality.


Description of the Issue

Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to completely subvert the application.


Example 1:

Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out?


Example 2:

Holding/locking resources and keeping others from purchases these items online may result in attackers purchasing items at a lower price. The countermeasure to this problem is to implement timeouts and mechanisms to ensure that only the correct price can be charged.


Example 3:

What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to their account cancel out of the transaction? Will the points/credits still be applied to their account?


Business Logic Test Cases

Every application has a different business process, application specific logic and can be manipulated in an infinite number of combinations. This section provides some common examples of business logic issues but in no way a complete list of all issues.


Business Logic exploits can be broken into the following categories:

4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)

In business logic data validation testing, we verify that the application does not allow users to insert “unvalidated” data into the system/application. This is important because without this safeguard attackers may be able to insert “unvalidated” data/information into the application/system at “handoff points” where the application/system believes that the data/information is “good” and has been valid since the “entry points” performed data validation as part of the business logic workflow.


4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)

In forged and predictive parameter request testing, we verify that the application does not allow users to submit or alter data to any component of the system that they should not have access to, are accessing at that particular time or in that particular manner. This is important because without this safeguard attackers may be able to “fool/trick” the application into letting them into sections of thwe application of system that they should not be allowed in at that particular time, thus circumventing the applications business logic workflow.


4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)

In integrity check and tamper evidence testing, we verify that the application does not allow users to destroy the integrity of any part of the system or its data. This is important because without these safe guards attackers may break the business logic workflow and change of compromise the application/system data or cover up actions by altering information including log files.


4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)

In process timing testing, we verify that the application does not allow users to manipulate a system or guess its behavior based on input or output timing. This is important because without this safeguard in place attackers may be able to monitor processing time and determine outputs based on timing, or circumvent the application’s business logic by not completing transactions or actions in a timely manner.


4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)

In function limit testing, we verify that the application does not allow users to exercise portions of the application or its functions more times than required by the business logic workflow. This is important because without this safeguard in place attackers may be able to use a function or portion of the application more times than permissible per the business logic to gain additional benefits.


4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)

In circumventing workflow and bypassing correct sequence testing, we verify that the application does not allow users to perform actions outside of the “approved/required” business process flow. This is important because without this safeguard in place attackers may be able to bypass or circumvent workflows and “checks” allowing them to prematurely enter or skip “required” sections of the application potentially allowing the action/transaction to be completed without successfully completing the entire business process, leaving the system with incomplete backend tracking information.


4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)

In application mis-use testing, we verify that the application does not allow users to manipulate the application in an unintended manner.


4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)

In unexpected file upload testing, we verify that the application does not allow users to upload file types that the system is not expecting or wanted per the business logic requirements. This is important because without these safeguards in place attackers may be able to submit unexpected files such as .exe or .php that could be saved to the system and then executed against the application or system.


4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)

In malicious file upload testing, we verify that the application does not allow users to upload files to the system that are malicious or potentially malicious to the system security. This is important because without these safeguards in place attackers may be able to upload files to the system that may spread viruses, malware or even exploits such as shellcode when executed.


Tools

While there are tools for testing and verifying that business processes are functioning correctly in valid situations these tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a user is able to circumvent the business process flow through editing parameters, predicting resource names or escalating privileges to access restricted resources nor do they have any mechanism to help the human testers to suspect this state of affairs.


The following are some common tool types that can be useful in identifying business logic issues.

HP Business Process Testing Software


Intercepting Proxy - To observe the request and response blocks of HTTP traffic.


Web Browser Plug-ins - To view and modify HTTP/HTTPS headers, post parameters and observe the DOM of the Browser


Miscellaneous Test Tools

The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.

Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests

Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies

With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e. the opened tabs and windows. Once a session is opened, the browser is restored to its state.

Swap My Cookies is a session manager, it manages your cookies, letting you login on any website with several different accounts. You can finally login into Gmail, yahoo, hotmail, and just any website you use, with all your accounts; if you want to use another account just swap profile!

Make HTTP requests from your browser and browse the response (HTTP headers and source). Send HTTP method, headers and body using XMLHttpRequest from your browser then view the HTTP status, headers and source. Click links in the headers or body to issue new requests. This plug-in formats XML responses and uses Syntax Highlighter < http://alexgorbatchev.com/ >.

Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties.


References

Whitepapers


OWASP Related


Useful Web Sites


Books

  • The Decision Model: A Business Logic Framework Linking Business and Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC Press, ISBN1420082817 (2010)