performing-second-order-sql-injection

Store a SQL payload through an input like registration or profile update, then exercise every endpoint that reuses that data such as admin panels or exports. Confirm the injection by observing errors, time delays, or out-of-band callbacks at the trigger point, not the storage point.

Use the --second-url flag to specify the trigger endpoint where the stored payload executes, for example sqlmap -u with the storage request plus --second-url pointing to the profile page. For complex triggers, use --second-req with a saved HTTP request file.

The application parameterizes the INSERT query so the payload is stored harmlessly, but a later query retrieves the value and concatenates it unsafely. Developers wrongly assume database-stored data is trusted and skip parameterization on reads.

SQLMap supports second-order attacks via --second-url and --second-req flags. Burp Suite tracks requests across storage and trigger endpoints, while out-of-band confirmation uses collaborators like Burp Collaborator for DNS callbacks.

Do not conclude safety until you have tested multiple storage fields, cross-user contexts like admin views of your data, and deferred triggers such as scheduled reports. A clean response at storage time is expected and proves nothing.