Support 'pre defined' applications to invoke

[GoogleCodeExporter]

Currently, the ability to run applications from ZAP is quite limited, in that 
all of the parameters to the application must be statically defined, when 
setting up the application under "Tools -> Options -> Applications".  This is 
useful for running GUI based tools, which require user interaction for 
instance, but is not very useful in terms of further assessing / exploiting a 
specific vulnerability found by ZAP.

What I'd propose is for ZAP to make most message / alert attributes available 
to external programs directly from ZAP using environment-variable-like 
placeholders such as ${method} ${url} ${parametername} ${dbms}. If an external 
program was configured to run with ${url}, ${postparams}, and ${parametername} 
for instance, and the user right-clicked a SQL Injection alert and  selected 
"Run Application -> Sqlmap dump database", Zap would pass the parameters to 
SQlmap, which would exploit the vulnerability for that parameter and URL.  Zap 
would capture the output as normal, or the external program could be configured 
to dump the results to file.

This would open up all sorts of new angles regarding interoperability between 
ZAP and other tools such as Nmap, Sqlmap, etc. 

Original issue reported on code.google.com by colm.p.o...@gmail.com on 27 Mar 2015 at 9:27

[GoogleCodeExporter]

Er, we support a load of those already, and have done since this feature was 
implemented :/
Click on the Help icon in the Options Application screen to see the ones 
supported.
Very happy for more to be added - suggestions always gratefully received.
Was going to link to this help page but it doesnt seem to be on the wiki - I'll 
look into that.

Original comment by psii...@gmail.com on 27 Mar 2015 at 9:39

[GoogleCodeExporter]

I tried to do that, but the feature didn't work, so there was no indication 
that this was supported.  It turns out that an exception is being thrown (see 
below).  I'll try a weekly release to see if it works there, because I'm 
working from 2.4 trunk.

error loading help with index: addon.invoke.options
java.lang.IllegalArgumentException: view is invalid
    at javax.help.search.MergingSearchEngine.merge(Unknown Source)
    at javax.help.JHelpSearchNavigator.merge(Unknown Source)
    at javax.help.plaf.basic.BasicSearchNavigatorUI.addSubHelpSets(Unknown Source)
    at javax.help.plaf.basic.BasicSearchNavigatorUI.reloadData(Unknown Source)
    at javax.help.plaf.basic.BasicSearchNavigatorUI.installUI(Unknown Source)
    at javax.swing.JComponent.setUI(JComponent.java:656)
    at javax.help.JHelpNavigator.setUI(Unknown Source)
    at javax.help.JHelpNavigator.updateUI(Unknown Source)
    at javax.help.JHelpNavigator.<init>(Unknown Source)
    at javax.help.JHelpSearchNavigator.<init>(Unknown Source)
    at javax.help.SearchView.createNavigator(Unknown Source)
    at javax.help.JHelp.setupNavigators(Unknown Source)
    at javax.help.JHelp.<init>(Unknown Source)
    at javax.help.WindowPresentation.createJHelp(Unknown Source)
    at javax.help.WindowPresentation.createHelpWindow(Unknown Source)
    at javax.help.WindowPresentation.setDisplayed(Unknown Source)
    at javax.help.DefaultHelpBroker.showID(Unknown Source)
    at org.zaproxy.zap.extension.help.ExtensionHelp.showHelp(Unknown Source)
    at org.parosproxy.paros.view.AbstractParamContainerPanel$ShowHelpAction.actionPerformed(Unknown Source)

Original comment by colm.p.o...@gmail.com on 27 Mar 2015 at 9:52

[GoogleCodeExporter]

You might not have the help add-on?
Just checked and its an add-on which is why its not on the main wiki.
If help does work for you look under Add Ons / Invoke Applications / Options
The help file in svn is here: 
https://code.google.com/p/zap-extensions/source/browse/branches/beta/src/org/zap
roxy/zap/extension/invoke/resources/help/contents/options.html
So we currently support:
        %url%   the full url, e.g. 'http://localhost/test?a=b'
        %site%  the site, e.g. 'http://localhost:8080/'
        %host%  the hostname, e.g. 'localhost'
        %port%  the port, e.g. '80'
        %cookie%    the first cookie field from the request header (if any)
        %postdata%  the POST data sent, if any, with any newlines replaced with "\n"

Original comment by psii...@gmail.com on 27 Mar 2015 at 9:57

[GoogleCodeExporter]

Hm. I do have it, but it doesn't appear to be functional.

This list of parameters is a very good start.  It would probably benefit from 
some additional parameters relating to alerts raied, to allow exploitation.  
I'll document the most useful suggested ones.

Perhaps we should also configure ZAP with a sample application or two, in the 
same way that Textpad appears to be configured to compile Java code directly 
from within the tool? That might be useful.

Thanks!

Original comment by colm.p.o...@gmail.com on 27 Mar 2015 at 10:32

[GoogleCodeExporter]

Why doesnt it appear to be functional? What doesnt work?
Currently apps are invoked from HistoryReferences (or an eqiv class) - so we 
can easily get any params related to those.
Alerts are harder, as there could be multiple alerts per ref - which one to 
choose?
I'm not saying we cant do it, but we'll probably have to make some changes to 
allow that to work well.
Freakyclown also suggested preconfiguring ZAP for well known apps, and I really 
like that idea. We'd have to make some more tweaks, eg prompting the user for 
the location if we cant find it in any of the standard places.
This will also make it more obvious that we support this sort of functionality, 
so its doubly useful.
Worth changing this issue into one to support that?
I'd hope the changes wouldnt be too tricky...

Original comment by psii...@gmail.com on 27 Mar 2015 at 10:38

[GoogleCodeExporter]

The Help doesn't work (for me).  That's probably just my setup, and I don't 
consider it part of this issue.

For alerts, it sounds like the call would need to be made directly against the 
alert, rather than against the history reference, in order to avoid the issue 
you describe.  An alert maps back to the history reference, so we can get that 
information to support all the parameters that are currently supported.

The only other issue I can think of with supporting a predefined set of apps 
(which does sound really nice) is that ZAP will be running on different OSs 
(Linux, MAC, Windoze), and the paths will obviously be different for each. We'd 
need to handle that somehow.  Yes, I think it's worth changing this issue to 
support that.

I've got some other related work that I need to complete, but if this task is 
still outstanding when I complete, I'll dig in. It does sound like more than 
just a quick fix is required.

Original comment by colm.p.o...@gmail.com on 27 Mar 2015 at 11:06

[GoogleCodeExporter]

Title changed :)
We also need to handle users who have installed apps in 'non standard' 
locations.
I think the easiest option is for us to have a set of known locations for each 
app, which will be platform dependent.
The first time someone invokes an app we look throught those.
If we find it great, we can set the path, but still allow users to change it.
If we dont find it we can just prompt them to select it via the std open file 
dialog.

+1 to supporting them for alerts as well

Original comment by psii...@gmail.com on 27 Mar 2015 at 11:25

• Changed title: Support 'pre defined' applications to invoke

[GoogleCodeExporter]

The help page is in the main wiki, under add-ons ;)

https://code.google.com/p/zaproxy/wiki/HelpAddonsInvokeOptions

Original comment by THC...@gmail.com on 27 Mar 2015 at 2:27

[GoogleCodeExporter]

Oh course - doh!

Original comment by psii...@gmail.com on 27 Mar 2015 at 2:28

[GoogleCodeExporter]

ZAP has been migrated to github

This issue will be on github issues with the same ID: 
https://github.com/zaproxy/zaproxy/issues

Original comment by psii...@gmail.com on 5 Jun 2015 at 9:18

• Changed state: Done