Breaking Bad - Business Logic Abuse.
There was a recent discussion on the OWASP Testing guide list, a project I used to lead, in relation to "How to test for business logic issues"
This is a real tough one to document in terms of "How to..."
In saying that some of the biggest simulated financial fraud attacks I have ever committed for clients were based around business logic and authorization logic attacks.
So how do we do it?
This how is see the world, you may or may not agree.
I look at an apps functionality as a Finite State Machine
Certain inputs make the machine transition to a different state. Some states can only be reached from certain other states. Certain states are idempotent and others are transactional and have a permanent impact.
We have a number of use cases to test this machine.
1. Positive use case - App does what it is meant to (positive sense)
2. Negative use case - App does what it is meant to (negative sense)
3. Abuse Case - User or data is trying to force app to do stuff it was not meant to do.
#3 above can be further broken down:
3a: Apps logic is broken by abuse: The app is forced to skip or ignore or revert certain state conditions. - breaking-out of the state transition model. - Forceful browsing, Wizard bouncing etc.
3b: Apps logic is broken by supplying it with data it did not expect. The app reacts and its state machine is broken by reacting in a certain way.
3c: App processes data albeit out of range or in wrong format and produces a useful result.
So we have a couple of types of test in order to break business logic:
Data manipulation (3b) - confusing the apps state based on input data.
State Transition attacks (3a) - break the apps transition model by sending it requests out of sequence for example.
Data Range attacks (3c) -
In many cases breaking the business logic of an application can be a combination of 3a and 3b above.
You say Tomato I say Tomato: (advice for QA and Developers):
Reverse Polarity - Introduce some chaos......
Build abuse test cases for positive business outcomes (1): Remove, add, corrupt, reverse input to the function. - Can you achieve a positive business outcome without obeying the state model or without supplying the function all the appropriate data.
Do the same with the negative outcomes(2).
Can we get the application to throw unexpected errors by breaking the assumptions of the state model?
Can we skip state transitions (A->B->C can we go from A->C or C->B)?
Break roles - become somebody!
Vertical:
Role Based Access Control is great for vertical sand boxing functionality. Well designed systems do not need to expose role based decisions to the client and such data does not need to go outside of the zone of trust (the server session state).
Horizontal:
This is generally less thought out. For some reason we obsess with RBAC.
Peer user types accessing each others information. Generally testing such controls yields returns. Such controls are critical in social networking environments; 100000's of peer users interacting in a complex discretionary access control modelled environment.
This is a real tough one to document in terms of "How to..."
In saying that some of the biggest simulated financial fraud attacks I have ever committed for clients were based around business logic and authorization logic attacks.
So how do we do it?
This how is see the world, you may or may not agree.
I look at an apps functionality as a Finite State Machine
Certain inputs make the machine transition to a different state. Some states can only be reached from certain other states. Certain states are idempotent and others are transactional and have a permanent impact.
We have a number of use cases to test this machine.
1. Positive use case - App does what it is meant to (positive sense)
2. Negative use case - App does what it is meant to (negative sense)
3. Abuse Case - User or data is trying to force app to do stuff it was not meant to do.
#3 above can be further broken down:
3a: Apps logic is broken by abuse: The app is forced to skip or ignore or revert certain state conditions. - breaking-out of the state transition model. - Forceful browsing, Wizard bouncing etc.
3b: Apps logic is broken by supplying it with data it did not expect. The app reacts and its state machine is broken by reacting in a certain way.
3c: App processes data albeit out of range or in wrong format and produces a useful result.
So we have a couple of types of test in order to break business logic:
Data manipulation (3b) - confusing the apps state based on input data.
State Transition attacks (3a) - break the apps transition model by sending it requests out of sequence for example.
Data Range attacks (3c) -
In many cases breaking the business logic of an application can be a combination of 3a and 3b above.
You say Tomato I say Tomato: (advice for QA and Developers):
- Build your test case for positive data flow for business positive outcomes.
- Build your test case for positive data flow for business negative outcomes. - access denied, insufficient funds etc
- Build your expected error condition test cases.
- Build your test cases for each stateful condition the function can be in.
- Map out state transitions from one state to another.
Reverse Polarity - Introduce some chaos......
Build abuse test cases for positive business outcomes (1): Remove, add, corrupt, reverse input to the function. - Can you achieve a positive business outcome without obeying the state model or without supplying the function all the appropriate data.
Do the same with the negative outcomes(2).
Can we get the application to throw unexpected errors by breaking the assumptions of the state model?
Can we skip state transitions (A->B->C can we go from A->C or C->B)?
Break roles - become somebody!
Vertical:
Role Based Access Control is great for vertical sand boxing functionality. Well designed systems do not need to expose role based decisions to the client and such data does not need to go outside of the zone of trust (the server session state).
Horizontal:
This is generally less thought out. For some reason we obsess with RBAC.
Peer user types accessing each others information. Generally testing such controls yields returns. Such controls are critical in social networking environments; 100000's of peer users interacting in a complex discretionary access control modelled environment.
Comments
Post a Comment