Attacking Application Logic
- This chapter lists 12 different examples of poor logic in an application.
- This was shortened to 3 to just provide sufficient examples and demonstrate the purpose of the chapter.
The Nature of Logic Flaws
- Logical flaws vary greatly with each web application.
- May be simple to complex.
- There is no common 'signature' with logical flaws.
- Some categories of flaws have become less common.
- Hard to eliminate with just simple standards, normal penetration testing, or code-audit tools.
- Need to pay attention to logic used to really even notice them.
Real-World Logic Flaws
- Example 1: Oracle
- The Functionality
- "Remember me" function
- Avoid logging in on every visit
- The Assumption
- ScreenName cookie is used as part of the security information, and encrypted.
- Can specify ScreenName and view it on screen, so there is access to both the encryption function and encryption key
- The Attack
- Input the RememberMe key into the ScreenName cookie.
- Given an encrypted RememberMe cookie, an attacker can list contents like username, UserID, and IP address.
- Example 2: Fooling a Password Change Function
- The Functionality
- Password change functionality for end users
- The Assumption
- The admin interface didn't contain a field for the existing password.
- The application uses the existence or lack thereof to determine if request was done by admins or users.
- The Attack
- Issue a request without an existing password
- Example 3: Proceeding to Checkout
- The Functionality
- Browse products, adding items to a cart
- Return to cart, and finalize order
- Enter payment and delivery info
- The Assumption
- Developers expected users to always access stages in proper order
- The Attack
- Skip directly from stage 2 (shopping/finalizing) to 4 (delivery info) to skip having to pay for an order.
Avoiding Logic Flaws
- Ensure all aspects of an application's design are documented well
- Mandate all code is comented
- Purpose and intended use
- Assumptions
- References to all client code used by components
- Reflect on every assumption made in the design
- How unexpected input is handled
- Side effects of dependencies
- Know that users control all aspects of every request
- Use the session to determine identity and status
- Consider impacts of updating session data based on input