Utilizing ZAP for RESTAPI testing - api

I'm curious as to how ZAP can be used to test RESTAPIs in the context of API security. Is it just the OpenAPI add on that can be used or are there other(more effective) methods?

Theres a ZAP FAQ for that :) https://www.zaproxy.org/faq/how-can-you-use-zap-to-scan-apis/ :
ZAP understands API formats like JSON and XML and so can be used to scan APIs.
The problem is usually how to effectively explore the APIs.
There are various options:
If your API has an OpenAPI/Swagger definition then you can import it using the OpenAPI add-on.
If you have a list of endpoint URLs then you can import these using the Import files containing URLs add-on.
If you have regression tests for you API then you can proxy these through ZAP
The add-ons are available from the ZAP Marketplace.
Once ZAP knows about the URL endpoints it can scan them in the same way as it scans HTML based web sites.
If you don't have any of these things then post to the ZAP User Group explaining what you are trying to do and the problems you are having.
For more details see the blog post Scanning APIs with ZAP.

Also the good idea is using Fuzzer from OwaspZap.
Fuzzing allows you to trigger an unexpected behavour from API server by submitting malformed requests, malformed parameters and guessing unpublished API methods.
You can read what is fuzzing here:https://owasp.org/www-community/Fuzzing
It will allow you to fuzz URL string or a single parameter.
To start fuzzer you will need to:
Right click on the request -> attack -> Fuzz..
Highlight the parameter you want to use and click "Add" button
Click Add in the new payloads window, choose the appropriate option and click add payload.
I would recommend to choose "file fuzzers" options at step 3 and choose one of the pre-defined wordlists, or export your own one. You can use Seclists to find a bunch of fuzzing wordlists. Here is the set of wordlists designed for API fuzzing https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
Furthermore, OwaspZap allows you to perform manual API testing if you know the methodology.
Here you can find some links related to REST security:
https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html

Related

Can Zap be used as a DAST tool via API without spidering?

I'm trying to use Zap as a DAST tool via the API and it's getting a bit annoying.
Can i use the tool as an attack tool instead of a proxy tool? what i mean is, currently i can't launch an active scan without the url being in the tree, which is only done via the spider afaik right?
What i want is to provide the url and launch an active scan based on a policy and get results, now that i think about it, this is similar to fuzzing just with attack vectors, although i see the logic of what to do with URL X if there is no history or scanning done, can't it just scan the page for actions and variables? the main difference is page\url scanning contrary to spidering which assumes there are other urls.
After writing this i'm not sure it can be done without a spider unless you're in my situation so let me explain it.
Lets say for example's sake i just want to scan the login page for SQLI and i'm using Owasp JuiceShop to make things easier, can i tell zap to attack the one page? the only way i found on that example is via the POST method since the url is not a static page and isn't being pick up by Zap unless it's an action, but then i can't launch it without spidering so this is like a loop.
Sorry for the long post hopefully you can provide some insights.
Update in comments
ZAP has to know about the site its going to attack. We deliberately separate the concepts of discovery and attacking because theres no one discovery option thats best for all. You can use the standard spider, the ajax spider, import urls, import defns like OpenAPI, proxy your browser, proxy regression tests or even make direct requests to the target site via the ZAP API.
It looks like you have quite a few questions about ZAP. The ZAP User Group is probably a better forum for them: https://groups.google.com/group/zaproxy-users

How to call Google NLP Api from a Google Chrome extension

My aim is to select some text from a web page, start a google chrome extension and give the text to a google cloud api (Natural Language API) in my case.
I want to do some sentimental analysis and then get back the result to mark/ highlight positive sentences in green and negative ones in red.
I am new to this and do not know how to start.
The extension consists of manifest, popup etc. How should I call an API from there that does Natural Language Processing?
Should I create a Google Cloud Application with an API_KEY to call? In that case I would have to upload my credentials right?
Sorry sounds a bit confusing I know but I just don't know how I can bring this 2 things together an would be more than happy about any help
The best way to authenticate your app will depend on the specific needs and use cases of your application. You can see an overview of all the different methods here.
If you are not planning on identifying users nor on using a back end server that handles authenticating (as I assume to be your case), the best option would indeed be to use API keys. They do not identify the user, but are enough for the Natural Language APIs.
To do this you will need to create an API key for the services you want and add the necessary restrictions to make the key as secure as possible. Detailed instructions on how to do this and how to use the key in a url can be found here.
The API call could be made from within the Chrome extension with any JavaScript method capable of performing POST requests. For example using XMLHttpRequest or the Fetch API. You can find an example of the parameters that need to be included in the request here.
You may run into CORS issues when making the request directly from the extension. I recommend reading this answer, where a couple of workarounds for these issues are suggested.

Selenium and Postman integration or other approach?

I am looking for general idea, approach and subsequently a right tool.
I plan to start testing administration panel. Stable parts of it can be tested by mean of selenium-python scripts. But the challange starts when before testing some funcionalities in panel I need to sent a batch of data via Postman to API endpoint.
As you know Postman is a native app, so it doesn't offer a url which selenium driver could access (browser extension is deprecated.
So the question is. Would it be possible to integrate and automate the process in one selenium script?
Is it possible to do it with Postman or there is another tool that can send a request to endpoint and can be integrated with selenium script?
One more thing. The best approach would be: Sending request and few second after that action start selenium test on data which have been delivered via request to panel. I need to fully automate the process and set those actions with no sighnificant time delay.
Curious about possible solutions.
For API Automation purpose, Use Rest Assured. Its easy to learn, implement. You'll be able to fully automate apis(both JSON & XML). All the validation will be done in seconds. If you integrate RestAssured & Selenium, you'll be able to validate data with API & front end.
Please let me know if you need to know more on this.
Sample GET Code :-
RestAssured.baseURI="base url Eg :- https://www.google.com/";given().header("Accept","application/json").header("Authorization","Value").when().get("rest of the part of the url").then().assertThat().statusCode(200).and().contentType(ContentType.JSON).and().body("name[0]",equalTo("Location"));
Sample POST Code :-
RestAssured.baseURI="https://www.google.com/";
Response res=given().header("Authorization","Value").header("cache-control","no-cache").header("content-type","application/json").body("{"+"\"format\":[\"live-blog\",\"video-story\",\"Photo Gallery\",\"photo-gallery\",\"blank\",\"breaking-news\",\"photo-story\"],"+"\"language\": \"english\""+"}").when().post("Rest of the url`enter code here`").
then().assertThat().statusCode(200).and().contentType(ContentType.JSON).extract().response();
String res_string= res.asString();
System.out.println(res_string);
JsonPath jpath = new JsonPath(res_string);
String articleid = jpath.get("[0].articleId");
System.out.println(articleid);
You can find all the jar files online.
Apologies for the format.
Selenium purpose is not testing your app's APIs, but web. I would suggest as someone commented here, use Java with Rest-Assured, it's very reliable, easy to learn, and fast.
You can use Java's API call if you need anything specific for your web testing, as a requirement or something else.
Since you are using Python already, you could easily use the 'requests' python package to send your API requests and parse the responses as required. This would allow you to easily integrate this into your overall script, sending the api requests, ensuring the necessary response, then starting the selenium steps.

How is api testing different from regular testing?

I don't know about testing but I would like to have a clear picture on how is API testing different from other testing methods.
API testing will not include UI as regular testing have
API testing requires basic networking knowledge such as what is the use of GET, POST, PUT, etc commands used.
API testing includes having knowledge of how various html elements work. For example, If I press a button, what will be the next function call. We need to know how 'button' element works
In API only API functions are tested, but in regular testing all the elements are tested
There are different tools used in API testing. POSTMAN is one of them
In API Testing we test Backend functionality while in Regular testing we check UI + Functional testing.
API Testing is helpful in testing Core Functionality.It helps us to reduce the risks.
Steps to Test API Manually:-
To use API manually, we can use browser based REST API plugins.
a)Install POSTMAN(Chrome) / REST(Firefox) plugin
b)Enter the API URL
c)Select the REST method
d)Select content-Header
e)Enter Request JSON (POST)
f)Click on send
g)It will return output response
Steps to start API Automation using REST
in general API testing is made for not doing many similar actions, when we can easily measure the result.
For example if you app button is not on the right place, it is hard to measure using code.
Another example is when you write a library for collections you can say just once:
CheckIntersect method:
result = mylibrary.getIntersection([1,2,3,4], [3,4,5,6])
if result != [3,4]
postTestError("CheckIntersect [1,2,3,4], [3,4,5,6]" + result.ToString() )
In this case you can easily measure the result, and not have a fear of you can't even find the problem in code.
I would like differentiate API vs. Other Testing instead looking into technical details.
API: Testing point of view the API is so important because, we can prepare independent test cases that are separate files. This makes our test approach relatively simple.
For better understanding, "Web API is typically done as HTTP/REST, nothing is defined, output can be eg. JSON/XML, input can be XML/JSON/or plain data. There are no standards for anything => no automatic calling and discovery."
API is a simple interface using HTTP protocol.
Other Testing:
Other testing like GUI, Regression, Unit, etc. Testing is absolutely essential for any application has to be in user friendly. The end user should be comfortable while using all the components should also perform their functionality with utmost clarity. Different Functional and GUI Testing can refer to just ensuring that the look and feel and Functional usability of the application is acceptable to the user.
Conclusion:
API can be:
Developed by one company, used by another company, and hosted by a third company Such involvement of several companies is a business cases for independent testing of API.
Example: Weather information API Developed and Tested by One & Accessed by many.
General Testing is testing each and every feature of the application from UI like web or mobile .
But,
API Testing is to verify the JSON Request to Server and Response from the Server .
If the application is using API all the content and Features based on the API Response from the Server .
For Example In FB app Profile screen, if the name is wrong ,
you can check from UI that general Testing, The same thing you can
Check it from API Response from the server , like below.
{"name":"Dharma","friends":450}

What should a developer know before building an API for a community based website?

What things should a developer designing and implementing an API for a community based website know before starting the heavy coding? There are a bunch of APIs out there like Twitter API, Facebook API, Flickr API, etc which are all good examples. But how would you build your own API?
What technologies would you use? I think it's a good idea to use REST-like interface so that the API is accessible from different platforms/clients/browsers/command line tools (like curl). Am I right? I know that all the principles of web development should be met like caching, availability, scalability, security, protection against potential DOS attacks, validation, etc. And when it comes to APIs some of the most important things are backward compatibility and documentation. Am I missing something?
On the other hand, thinking from user's point of view (I mean the developer who is going to use your API), what would you look for in an API? Good documentation? Lots of code samples?
This question was inspired by Joel Coehoorn's question "What should a developer know before building a public web site?".
This question is a community wiki, so I hope you will help me put in one place all the things that should be addressed when building an API for a community based website.
If you really want to define a REST api, then do the following:
forget all technology issues other than HTTP and media types.
Identify the major use cases where a client will interact with the API
Write client code that perform those "use cases" against a hypothetical HTTP server. The only information that client should start with is the response from a GET request to the root API url. The client should identify the media-type of the response from the HTTP content-type header and it should parse the response. That response should contain links to other resources that allow the client to perform all of the APIs required operations.
When creating a REST api it is easier to think of it as a "user interface" for a machine rather than exposing an object model or process model. Imagine the machine navigating the api programmatically by retrieving a response, following a link, processing the response and following the next link. The client should never construct a URL based on its knowledge of how the server organizes resources.
How those links are formatted and identified is critical. The most important decision you will make in defining a REST API is your choice of media types. You either need to find standard ways of representing that link information (think Atom, microformats, atom link-relations, Html5 link relations) or if you have specialized needs and you don't need really wide reach to many clients, then you could create your own media-types.
Document how those media types are structured and what links/link-relations they may contain. Specific information about media types is critical to the client. Having a server return Content-Type:application/xml is useless to a client if it wants to do anything more than parse the response. The client cannot know what is contained in a response of type application/xml. Some people do believe you can use XML schema to define this but there are several disadvantages to this and it violates the REST "self-descriptive message" constraint.
Remember that what the URL looks like has absolutely no bearing on how the client should operate. The only exception to this, is that a media type may specify the use of templated URIs and may define parameters of those templates. The structure of the URL will become significant when it comes to choosing a server side framework. The server controls the URL structure, the client should not care. However, do not let the server side framework dictate how the client interacts with the API and be very cautious about choosing a framework that requires you to change your API. HTTP should be the only constraint regarding the client/server interaction.