Client Side Attack Testing

Example 1: Hidden Field Price Manipulation

Scenario: E-commerce application transmitting product price in a hidden form field for use at checkout.

Trigger: During application mapping, proxy traffic reveals in the purchase form HTML.

Process: 1. Add item to cart and proceed to checkout in browser 2. Intercept the POST request in Burp Suite when the Buy button is clicked 3. In the intercepted request body, locate quantity=1&price=449 4. Modify price=449 to price=1 and forward the request 5. Also test price=-100 to check for negative-price acceptance

Output: If the order is processed at the modified price, document as CWE-565 (Reliance on Cookies Without Validation) / improper trust in client-submitted data. Remediation: look up price server-side from the product catalog at time of purchase; never trust client-submitted price values.

Example 2: CSRF Against Account Email Change

Scenario: A web application allows users to change their email address via a POST request that relies solely on the session cookie for authentication.

Trigger: Application mapping reveals POST /account/change-email accepts email=new@example.com with no additional token in the request body.

Process: 1. Confirm no anti-CSRF token is present in the request or the form HTML 2. Confirm no SameSite attribute is set on the session cookie 3. Construct the PoC page with an auto-submitting form pointing to /account/change-email with email=attacker@attacker.example.com 4. While authenticated in the target application, load the PoC in the same browser session 5. Confirm that the email address is changed to the attacker-controlled address

Output: Document as CWE-352 (Cross-Site Request Forgery), severity High. Remediation: implement synchronizer token pattern (per-session or per-request CSRF token in request body), or set SameSite=Strict on session cookies.

Example 3: Clickjacking on Fund Transfer Confirmation

Scenario: A banking application's fund transfer confirmation page (/transfer/confirm) lacks X-Frame-Options.

Trigger: Security header review reveals X-Frame-Options is absent from the /transfer/confirm response.

Process: 1. Construct the iframe overlay PoC with the confirmation page loaded transparently 2. Position the transparent iframe so the Confirm button aligns with a decoy "Click to claim reward" button on the attacker page 3. Open the PoC in a browser where the victim user is authenticated to the banking application 4. Click the decoy button — verify the fund transfer is confirmed within the framed application

Output: Document as CWE-1021 (Improper Restriction of Rendered UI Layers / Clickjacking), severity High. Remediation: add X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' to all sensitive pages. Note: JavaScript framebusting is not a reliable substitute — it can be circumvented via sandbox iframe attributes.