Burp Suite User Forum

Create new post

How do i detect Second-order SQL injection by scanner?

Andy | Last updated: Sep 28, 2016 07:26AM UTC

Hi. I'm trying arises new scan check for second-order SQL injection vulnerabilities.(its has been Implemented ver 1.7.06) Now,I made programs for detect it. 1,Entry form User-supplied data is stored by the application. (database is MySQL) 2. Retrieval form User-supplied data embedded into the application's responses. Submit the form, and then run the SQL in an unsafe way. The SQL query included the data that user-supplied which stored. I did Active scan Entry form and then Retrieval form. But Scanner showed only just a SQL Injection. I checked option by scan Options. SQL injection, Error-based,Time-delay checks,Boolean condition checks,MySQL-specific checks. How can i detect Second-order SQL injection? Many thanks for the response:)

PortSwigger Agent | Last updated: Sep 28, 2016 08:07AM UTC

Burp carries out the logic for second-order SQL injection when it observes stored user input being returned by the application. To detect stored inputs, you need to scan the entry point followed by the retrieval point, and the input needs to still be present in the retrieval point. You can determine whether Burp is actually observing the stored input by turning on the active scan check called "Input returned in response (stored)". With this check enabled, scan the entry and retrieval points, and confirm that Burp reports the stored data. If that happens then it should also carry out the logic for second-order SQLi. If that still isn't being reported, we would suggest using an extension like Custom Logger in the BApp Store to monitor the requests and responses processed during scanning. This should indicate whether Burp is indeed performing the relevant logic, and why an issue is not being reported.

Burp User | Last updated: Sep 29, 2016 02:39AM UTC

Hi THX for the response. I see. With “Input returned in response (stored)” check enabled, do an active scan the entry and retrieval points. But Burp didn't reports the stored data. I was confirmed, a data embed response at retrieval point that same requested entry point. Are there any other conditions? Many thanks for the response:)

PortSwigger Agent | Last updated: Sep 29, 2016 02:12PM UTC

The stored data that Burp looks for to report this issue is a long alphanumeric string that is sent in the scan of each insertion point. This string has the same form as Burp uses for random Collaborator subdomains, and Burp also recognizes any stored Collaborator payloads as representing stored data. To detect the stored data issue, the data item that Burp is looking for needs to be present in the base response of a page at the time that it is later scanned, either actively or passively, There are no other conditions. The most common reason for failing to detect stored data is that the application only stores a single value, and this value has been overwritten by other actions by Burp or application users before Burp later scans the retrieval point.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.