Testing Financially-Oriented WepApps

TOCTOU / Race-Condition Tests

• Attempt concurrent transactions (e.g., two simultaneous money/points transfers) to see if checks are bypassed.

• During checkout: open payment page, then from another tab/session modify basket or amount and return to pay — verify the final transaction reflects correct state (Deposit process when an application can hold user balances).

• After payment completion: attempt to modify the order (items, quantity, details) and see if changes are allowed without fresh payment/validation.

Parameter Manipulation Tests

• Price Manipulation: adjust hidden/posted “price” field (e.g., negative values, 0, manipulated discount) and verify final price is correct.

• Currency Manipulation: change currency parameter in payment request (if multi-currency supported) to a lower value currency and check for inconsistent credit.

• Currency Manipulation: In the Provider Itself

• Quantity Manipulation: test fractional, negative, zero quantities, very large quantities and verify price and quantity enforcement.

• Shipping Address / Posting Method Manipulation: modify shipping address/post method late in checkout (or after payment page loaded) and verify cost/tax adjustments are validated.

• Additional Costs Manipulation: test gift-wrap, expedited shipping, other cost-adders – see if they can be removed or manipulated to reduce cost improperly.

• Response Manipulation: intercept the server response or third-party payment callback and attempt to manipulate it (e.g., change “paid” status) and verify backend rejects tampered responses.

• Repeating Input Parameters: send duplicate parameters (e.g., amount=2&amount=3) or weird arrays and check how the server handles duplicates.

• Omitting Input Parameter or Value: remove a parameter entirely or send null/empty or malformed (e.g., missing equals sign) and check for unintended behaviour.

• Mass Assignment / Auto-Binding / Object Injection: send extra parameters (not expected by front end) to see if internal objects get manipulated (e.g., set “due_date” far in future).

• Combined Parameter Changes: change more than one parameter (e.g., price + quantity, shipping method + address) to detect logical flaws in combination.

---

Replay Attacks

• Replay a successful payment callback (with same transaction id) and see if the system re‐credits or re‐processes the transaction.

• Replay an encrypted parameter request (or reuse encrypted token) and test if the system treats it as new/valid transaction.

---

Rounding & Numerical Processing Tests

• Currency Rounding: deposit/convert currencies (or buy items) where rounding difference is exploited (e.g., $0.20 → £0.1352 → $0.2004) and check for profit behaviour.

• Generic Rounding: deposit e.g., £10.0049 but only £10.00 withdrawn and balance credited incorrectly — repeat many times to verify exploitability.

• Negative Numbers: test negative values for price, deposit, quantity to see if logic is reversed (e.g., user gets credit).

• Decimal Numbers: test decimal values where integers expected for quantity/price and observe rounding or truncation issues.

• Large or Small Numbers: send very large or very small numbers beyond normal bounds and verify validations.

• Overflows/Underflows: test inputs near variable limits (e.g., max int, min int) and check for roll-over behaviour.

• Zero / Null / Subnormal Numbers: test “0”, “0.00”, “-0.00”, “1e-50”, etc and check if system handles them properly.

• Exponential Notation: send numbers like “9e99”, “1e-1” to test parsing and logic bypass.

• Numbers in Different Formats: test “001.0000”, “$10”, “£0”, “-0.00”, etc to verify correct numeric parsing across tech stacks.

---

Card Number / Payment Card Related Tests

• Ensure that saved card numbers are not fully displayed during checkout or in HTTP responses; only last 4 digits if needed.

• Attempt enumeration: test registering duplicate cards across accounts (if site blocks duplicates) to see if card numbers of other users can be deduced.

---

Dynamic Prices / Referral Schemes Tests

• If dynamic pricing exists (based on currency, device, referral code, time), submit a price number close (± 0.01) to original and check if unexpected margin accepted.

• Verify that the dynamic pricing logic is properly signed/cryptographically protected so user can’t manipulate input.

---

Discount Codes / Vouchers / Reward Points / Gift Cards Tests

• Enumeration / Guessing: attempt to guess voucher/gift card codes or loyalty codes for other users; verify code generation randomness/unpredictability.

• Offers/Voucher Stacking: check if multiple promotions (buy-one-get-one, 3-for-2, etc) can be combined incorrectly to reduce cost unfairly.

• Earning More Points/Cash than Price: purchase with points, then verify if points are earned in the same transaction, resulting in net gain.

• Using Expired/Invalid/Other Users’ Codes: apply expired or someone else’s codes to see if system rejects correctly.

• State & Basket Manipulation: modify basket after discount calculation (remove items, mix discounted & non-discounted) and check discount still valid incorrectly.

• Refund Abuse: buy item, refund it, in between spend points or get free items — check full reversal of associated rewards.

• Buy-X-Get-Y-Free: check if cheapest vs expensive items are correctly discounted or if logic allows paying for cheaper and getting expensive item free.

• Ordering Out of Stock or Unreleased Items: attempt to buy items flagged “out of stock” or “not yet released” to check if order is still processed with discount/exploit.

• Bypassing Restrictions: test limited-quantity offers, customer-specific offers, one-time vouchers in multiple accounts to verify restrictions.

• Point Transfer: if users can transfer loyalty points or rewards (e.g., closing account or lost card) test for abuse of transfer + race conditions.

---

Cryptography & Backend/API Tests

• Review cryptography implementation: ensure strong algorithms (avoid custom weak crypto), check for brute-force vulnerability of secret keys.

• Hash/signature concatenation issues: test if signature protects against tampering - e.g., moving part of one parameter into another but same signature.

• Encryption/Decryption misuse: check if encrypted parameters can be used to shape arbitrary data (replay, manipulate).

• Downloadable/Virtual Goods: attempt direct object reference (e.g., guess URL of non-free asset) and check if access is restricted.

• Hidden/insecure backend APIs: discover APIs not exposed in UI (e.g., admin, bulk operations) and test for unauthorized access or balance adjustment.

• Test data in production: check for debug/test payment endpoints, dummy card numbers left in production environment that can be exploited.

---

Currency Arbitrage / Deposit/Refund Tests

• Deposit in one currency, withdraw in another, exploit rounding/exchange rate differences for profit.

• Verify if different parts of system (deposit API / withdrawal API) use inconsistent exchange rates or rounding rules.

---

References

https://soroush.me/downloadable/common-security-issues-in-financially-orientated-web-applications.pdfsoroush.me