Differences between Persistent XSS Plugins

[TW]

I've noticed that there are the following persistent XSS plugins available in ZAP's weekly release (perhaps elsewhere, too?):

  Cross Site Scripting (Persistent)
  Cross Site Scripting (Persistent) - Prime
  Cross Site Scripting (Persistent) - Spider

Could someone please explain the differences between these three?  When I look at my scan policy, I can see that each of these plugins is considered "release" quality.  Is there significant overlap among them, or do they each check for persistent XSS weaknesses in completely different ways?

I've been unable to find anything relevant in ZAP's help docs or elsewhere.

[TW]

Actually, I just stumbled onto this short description:

  https://groups.google.com/d/msg/zaproxy-users/WZyQuAF3qB8/aJ6ov302BwAJ

However, if anyone has more detail to offer with respect to how these plugins cooperate, that would be interesting to know.  For example, if all three are required to sufficiently check for persistent XSS weaknesses, why permit one or two to be disabled in a policy?

Thanks in advance!

[kingthorin+owaspzap]

They're all part of the same thing. Prime and Spider are components/dependencies of the core rule.

[TW]

Is there any circumstance in which one would want to disable one or two of the plugins (in a policy), though?

Thanks

[kingthorin+owaspzap]

No. They're declared as dependencies in the code so if the main one is on I don't think you can actually disable (or prevent use of) the others ...

Unfortunately I can't look at the behavior right now.

I did just have a quick look at the policy dialog and while it does enable them all when switching from off to another state, it isn't totally consistent as it likely should be. Might be worth opening an issue to fix or enhance to how the policy UI operates with dependent scanners (rules): https://github.com/zaproxy/zaproxy/issues

[Simon Bennetts]

The 'Prime' rule injects a 'safe' but unique value into all of the input vectors that you are scanning.
The 'Spider' rule then spiders the whole application looking for the values.
These 2 rules tell us which input values are persisted, but not if they are vulnerable to XSS.
The main 'Persistent' rule then works in the same way as the 'Reflected' rule except that instead of checking the immediate response it checks the 'destination' pages found previously by the spider.
So these rules are all part of the same process, you need all of them to run in order to find persistent XSSs.

Does that help?

Cheers,

Simon

[TW]

This does help (thanks, Simon).

However (and I do apologize for belaboring this), it just so happens that I have two different ZAP scans happening this moment.  If I open up scan progress details and look at the Progress tab for each scan, I can see that the "Cross Site Scripting (Persistent)" plugin is executed before the Prime and Spider plugins.  Shouldn't the Prime and Spider plugins execute ahead of the "Cross Site Scripting (Persistent)" plugin?  Or, perhaps I'm just not reading the Progress tab correctly?

[Simon Bennetts]

Had they ran before you looked at the Progress tab?
They could be in any order before they run, but they will actually run in order, and the order should be right after they have run :)

[TW]

They have yet to execute.  Both scans are still ongoing, and it turns out that the very next plugin to execute is "Cross Site Scripting (Persistent)."  So, in the case of both scans, none of the XSS plugins in question have executed, yet.

I'll report back when they do, however.

[TW]

Okay:  I now see that the plugins don't necessarily execute in the order they are presented on the Progress tab.  Didn't realize that was the case!  (Though, it does beg the question:  why not just present the plugins in the order they are to execute?)

The upshot is that the XSS plugins ran in the order noted noted above:  Prime, Spider, main.

[thc...@gmail.com]

> (Though, it does beg the question: why not just present the plugins in the
> order they are to execute?)

Please, raise an issue, [1] that surely can be improved.


[1] https://github.com/zaproxy/zaproxy/issues/new

Best regards.

[TW]

Done!

[thc...@gmail.com]

Thank you!

Best regards.

[Lokesh Singhal]

Are we testing DOM based XSS vulnerabilities as well with ZAP?

[thc...@gmail.com]

Yes, if DOM XSS Active scanner rule add-on is installed:
https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsDomxssDomxss

Best regards.