Rest API penetration testing

[Ivan Ivanov]

Hi, Everyone!!
Can i test Rest API with ZAP? Can i perform something like JSON injection by means of ZAP?
Maybe you advise me what kind of tools i should use to check it?

[Simon Bennetts]

Yes you can :)
As of 2.2.2 ZAP understands and can attack JSON.
You will need to explore your API while proxying through ZAP - eg using your browser or unit tests.
You can then perform an active scan on the API.
Make sure that you have the 'JSON' option selected in Tools / Options / Active Scan / Parameters to scan.
Note that in the weekly release this is under 'Active Scan Input Vectors' instead of 'Active Scan'.
Let us know how you get on and if you have any more questions.

Cheers,

Simon

[Dan Billing]

I've used this already, and it works really well!

[Ivan Ivanov]

Yep, i understand how works this.Thank you!!

среда, 12 марта 2014 г., 13:39:40 UTC+4 пользователь Dan Billing написал:

[Jason Weden]

I've been searching around the forum for ZAP REST API security testing information and found this thread.  We have started experimenting with putting ZAP passive scanning in the middle of our tests against our stateless REST API.  It uses an oauth token in the Authorization header and the HTTP conversation is completely stateless barring when we actually obtain the oauth token.  If we exclude the obtaining oauth token, I'm wondering how much value ZAP passive scanning could get us.  We have a large battery of tests which use a java http client (read: not a browser) going against a service which accepts json and, in a few cases, a specifically formatted multipart file upload; said service always returns json.  I'm having trouble finding the complete, comprehensive description of the scan rules...I see the passive scan rules in the GUI and something called vulnerabilities.xml in the source.  Looks like the ZAP output report has the most information but would be nice to see a wiki page with all that information.

Q1. Is there a central place to see the name, description and proposed solution that align to ALL the scan rules?  I'm trying to find what's applicable to stateless REST API security testing.

Q2. Given our architecture, is there a benefit to using ZAP passive scanning to test a stateless REST API?  

Q3. Are ZAP REST API tests limited to json injection during active scans? This is easy enough for us to put into our homegrown test framework (maybe point me to the source code that does it and I can replicate it)?  Or is there some other kind of valuable testing ZAP could have in passive or active scans?

Q4. We have a different set of tests which goes a/g our web application (right up ZAP's alley) and so is there a way to blacklist urls we do not wish to passively scan or show in the report?  This is because ZAP might be flagging security issues in the report a/g our REST API urls that are only applicable to stateful sessions.

Seems with REST API security tests, one almost needs to always build custom testing tools after looking at OWASP REST cheat sheets -- a lot of it seems to be related to the specifics of the API under test (e.g. params, ids in url, api biz logic).

[kingthorin+owaspzap]

This discussion will probably lead you to some good info:
https://groups.google.com/forum/#!searchin/zaproxy-develop/wiki/zaproxy-develop/Re0D8zROVbM/i5Q4lffu9tcJ

Help pages are being updated for the forthcoming 2.4 release.

Q1. Is there a central place to see the name, description and proposed solution that align to ALL the scan rules?  I'm trying to find what's applicable to stateless REST API security testing.

The docs mentioned above will be a good starting place. I don't think we have tables that break it down the way you're asking about.

Q2. Given our architecture, is there a benefit to using ZAP passive scanning to test a stateless REST API? 

Sure, it'll help you identify misconfigurations and weaknesses. (Keep in mind that just because you've built the API to be consumed by a specific Java client doesn't mean that someone won't use a standard browser or something other than your intended Java client to abuse it.)

Q3. Are ZAP REST API tests limited to json injection during active scans? This is easy enough for us to put into our homegrown test framework (maybe point me to the source code that does it and I can replicate it)?  Or is there some other kind of valuable testing ZAP could have in passive or active scans?

The code is quite extensive, I don't really think it would be practical to try and implement ZAP code outside of ZAP. You'd probably be best off leveraging the ZAP API to call ZAP from your framework.

Q4. We have a different set of tests which goes a/g our web application (right up ZAP's alley) and so is there a way to blacklist urls we do not wish to passively scan or show in the report?  This is because ZAP might be flagging security issues in the report a/g our REST API urls that are only applicable to stateful sessions.

You can establish exclude URLs for ZAP. (https://code.google.com/p/zaproxy/wiki/HelpStartConceptsGlobalexcludeurl)