I'm desperately looking for tools, preferably with some guide, also preferably open-source, to detect stored xss vulnerabilities. It is observed that a handful of them doesn't give the expected results with stored XSS.

I have tried with ZAP Proxy and xsser, but only found documentation on reflected XSS for those tools.

For stored XSS the "injected" page may be different from the vulnerable page.

I'm benchmarking tools on a simple vulnerable app found here: https://hack.me/101061/persistent-xss.html

Manual exploitation took seconds, but so far I was not able to use automatic tools, even in a "guided" mode where I specify the URL of the form and let the tool find vulnerable pages.

I suspect that both cited tools are able to do that, but it's either too trivial or too complicated to be shown in examples/blog posts. I would be really grateful if someone could show such use case.

closed as off-topic by Anders, techraf, Matthew, Xander, Steffen Ullrich Oct 18 '16 at 19:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • Some tools browse the site as a guest and try to find vulnerabilities. Similar to a black-hat pen-test. Automated tools are quite limited when using this perspective and will inevitably miss vulnerabilities that a human would be able to detect. On the other hand, if you have the application source code, there are tools which can check for correct encoding to prevent XSS. This is more like a white-hat pen-test and is much easier for an automated tool to be effective. Do you have the source code available? Also be advised that some vulnerabilities cannot be detected by any tool. – Bryan Field Oct 18 '16 at 13:41
  • 1
    I have indeed access to the source code of some apps I want to test but not all. Here my question was about the black-box mode where I can only interact with the application like any user – user2245644 Oct 18 '16 at 13:41
  • Requests for software recommendations are not on topic here. Try asking here, but make sure to read the help center first and follow their guidelines. – Anders Oct 18 '16 at 13:42
  • Thank you for the clarification. I have not used such tools personally, but hopefully someone else here will be able to help. :-) – Bryan Field Oct 18 '16 at 13:42

Here are a few problems with what you are looking for and why they are virtually non-existent.

  1. Tools find reflected XSS by searching for the injected script snippet in the HTML source of the immediate response to request which injected the script.
  2. The same tools will detect stored XSS as well if the script is reflected in the immediate response.
  3. But sometimes the immediate response may not reflect the script even if it is vulnerable to XSS. For example a user submits an internal form to a high privileged user which won't be visible to him/her immediately. In this case if the form is vulnerable to persistent XSS it will execute at the browser of high privileged user.
  4. Persistent XSS mostly happen on POST request. Scanning post request usually lead to database exhaustion.

What you can do to automate:

At this point I am unaware of any tool which can be used for the same. However I would like to suggest a work around.

  1. Use Burp Professional trial version [It will take a day or two for them to send the trial license.]
  2. In User Options > Misc in Logging Section click the checkbox to log all the responses.
  3. Browse through the application, spider it, Select the requests you want to scan, send them to the scanner tab. It will identify the usual vulnerabilities, but it may miss some persistent XSS.
  4. Browse and spider again through the entire application after the scan with all the user privilege levels.
  5. Check in the log file for scripts. Burp injected scripts can be distinguished as they usually carry a signature of random characters with them. For example the script injected might look like

    jklmn |injected script which stackexchange won't let me post| jklmn

  6. So if you identify any injected scripts in the response log file, you can identify the page, parameter and the source of the reflection.

  • ok great. The unique tag approach is also used by xsser, so it might be the way to automatically locate potential injection points. – user2245644 Oct 18 '16 at 17:02
  • concerning the database issue, there may sometimes be ways to 'clean-up the mess' (for example for website comments we could do cycles of create-check xss-delete). Not fully automated but still doable for complicated targets – user2245644 Oct 18 '16 at 17:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.