Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Stored XSS - detection tweaks

Andrej | Last updated: Jul 24, 2015 06:41AM UTC

Hi, Usually, when I'm going through some wizard, e.g. "Create new XXX", all that is required is to create new item XXX is to do a simple POST with all data included. I can then send this POST into the Burp and run active scan. It does populate DB with plenty (thousands) of new entries (which I wanted to achieve). However, if I want to scan for the persistant issues, like stored XSS, how should I proceed? The data isn't reflected in the response after POST being issued; and there is separate URL where there are plenty of new XXX items. I was thinking about 2 approaches: 1) I could go into intruder, iterate through some IDs (if it could be done and ID would not be randomly assigned); 2) I could start spider to access all pages. Is it possible to run spider/Intruder after active scan is finished? Will the passive scan alone detect vulnerabilities which were posted by Burp in active scan? Or is there some other approach to detect stored issues? Many thanks for the response:)

PortSwigger Agent | Last updated: Jul 24, 2015 08:48AM UTC

Burp Scanner is able to detect most instances of stored XSS provided you do the following steps in order: 1. Perform an active scan of the entry point for the data. 2. Perform an active scan of the retrieval point for the data. Provided at step 2 Burp observes the stored payloads that it submitted earlier, it will perform a full XSS check using the entry and retrieval points, and should report any issues. If you are testing a large application and aren't sure about getting the order of 1 and 2 right, you can complete all of your normal active scanning, and then configure Burp to only do stored XSS checks and do a second pass of active scanning. This will just look for retrieval of stored data and perform any applicable logic to find stored XSS.

PortSwigger Agent | Last updated: Feb 19, 2016 09:50AM UTC

Hi Dan, We attempt to handle this scenario by sending the stored canary as the final payload. Have you tried using the XSS scanner as described? You may find it just works. If not, this may be caused by other requests made by the scanner to a different insertion point, which cause the vulnerable parameter to reset to its base value. You may have some luck turning off non-relevant insertion points in Scanner > Options > Attack Insertion Points. Failing that, unfortunately, such vulnerabilities are difficult for a scanner to detect in an automated way, at least, without greatly increasing the numbers of requests needed for a scan.

Burp User | Last updated: Jun 08, 2018 09:00PM UTC

Dafydd, Is there a way to automate this when there is only one storage location that gets overwritten? I'm testing an application that lets you change your display name with a POST, but the response to the POST does not show the displayed name. The problem is that when I do an active scan on the parameter (your step 1), it changes the name many times. So if I do a follow-up stored XSS scan (your step 2) of the page that includes the display name, it is only going to check the very last name that was set by the active scanner.

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