This Is OWASP Zap- Network Proxy For Tester
In this blog on Network Proxy- the information revolves around the very basic concepts that QAs at Anarock Tech came across regularly while testing mobile applications.
This would be helpful for all the QAs in the IT industry. This is primarily useful for the black-box tester who is working in Mobile App Testing. So without any further adieu, let’s get started!
Witin the tester’s daily working life, there are a few issues which occur quite often specifically on staging servers. This can be very annoying at times as the Black box tester doesn’t get to see what is happening at the back-end. Common examples for such instances are:
1. Server responding with 5xx, 4xx.
2. Random API responding with 5xx, 4xx.
In such cases, the tester simply reports it as a bug and assigns it to the Developer (Front-end developer), then the front-end (FE) developer starts debugging the issues and after finding out that this issue is from the back-end (BE), he assigns that issue to the BE developer. As testers were not aware of what the problem was, they may assign it to the wrong developer which in-turn costs debugging time to the FE developer.
To overcome this problem, this blog will help the reader understand what can be taken into consideration. Here, black box testers need to upgrade themselves and develop a firm understanding of how APIs work.
Now, you must be thinking ‘Yes, we got your point, but how to solve this problem? How can one see API calls happening on Mobile Apps?’
Let’s now take a look at the available tools first for reading network calls.
Tools Available in the Market:
1. Charles Proxy
2. OWASP Zap
3. Flipper
There are so many other proxy tools available in the market. All these tools have their own limitations. From the list of the above mentioned tools, we prefer to go with the “OWASP Zap” tool as it has some of the key advantages over other tools. Let’s have a look at what OWASP is, Why OWASP, and How useful it can be?
What Is OWASP Zap?
OWASP stands for “Open source web application security testing”, and it is a widely-used open-source tool for Security testing, pen-testing, and for ethical hacking. This tool can be used for finding Vulnerability or security concerns present in the system.
Now, one might think, ‘If this tool is used for Security testing, then why are we using this tool for network calls testing when we have available the CharlesProxy?’
We have an answer to this question as well. First, let’s understand the importance of “OWASP”.
Why OWASP For Network Call Testing?
The top reasons why we chose OWASP over other tools are:
1. It is an open-source tool, which means we can use it for free.
2. Has a wide Community which can be useful for resolving problems we are stuck on.
3. Easy-to-use and supports features which are “paid” features of other available options (Eg. Reading “https:” calls).
4. Provide an option to save sessions and reuse them.
How Do OWASP Work?
Zap creates a proxy server and makes your website traffic pass through that server. Using OWASP zap we can manipulate all the API calls through the proxy server, including the “https:” calls. In simple words, the Zap Proxy server seats between the client (front-end) and the actual server.
First, we need to install OWASP Zap on your machine. After that, for checking network calls of a mobile application we need to set up a proxy on our testing device as well so that device network traffic will be routed through the Proxy server. We will have to pass the machines’ IP address, port number and will have to install a “Dynamic SSL Certificate” on the testing device, as it is mandatory for reading “https:” calls.
As shown in the above illustration, once proxy setup is done, your device network traffic will be routed through OWASP Zap using your machines’ IP address and then will hit a request to the actual server. In this flow, all the outgoing and incoming requests and responses will be passed through the Zap Proxy.
Setting Up OWASP Zap On Android & iOS Devices
Now, let’s go to the next step “how to set up OWASP Zap” on android and iOS devices.
i. Set up OWASP Zap on Android devices
ii. Set up OWASP Zap on iOS devices
We hope the above links will be useful in setting up OWASP Zap on android and iOS devices respectively. Furthermore, you must have understood how the OWASP Zap tool works on a basic level, now let’s understand how it can be useful in the everyday testing cycles of a tester. We have listed some of the basic points with examples for better understanding.
Common Problems Faced By Tester While Testing
When testers start testing any Application specifically in the development phase, there are high chances of invalid requests or responses and there can be multiple reasons for them. Let’s have a look at some of them with examples.
• Recognizing Server down or a single API:
A majority of the time when the tester is testing any application on the staging server, there is a major possibility of the server going down or some of the APIs stops responding due to any reason and starts responding with 4XX or 5XX error code as various development activities happens of staging server on daily basis. In this case, the tester takes the developer’s help for rectifying the exact problem or reports an issue for the same.
Some testers look for APIs which can cause the problem with the help of any API testing tool like Postman. Here, if the OWASP setup is ready then the tester can get an exact API with the exact cause for failure which will help the tester to understand the problem and get it fixed by the appropriate person.
Example:
When the server is down all the APIs will start receiving responses with a 5xx error code, and this simply tells us that the server is down due to some reason. By looking at the response we got to know that this issue is from the server and we can report it to the back-end developer and get it fixed.
This is a very basic example which we have discussed above. This will help us in increasing the efficiency of the team since we work to provide the root cause of the issues that occurred during the test, whether it is related to the whole back-end server or with some random APIs that are failing to respond.
This will help the developer to concentrate on that specific part of the code and resolve it in less time as we have provided the exact pain point of the system. This also helps in saving the time of front-end developers that they could have been spent on debugging the same issue.
Now, let’s go to the next section where we will be analyzing the problem when servers and APIs are working fine. Now, the question is if servers are working fine then why do we need to check network calls? Let’s go to the next section to know more use cases for identifying basic causes.
• Recognizing Issue from FE or BE:
This is one of the issues which might come in tester life when they are testing any new product or feature, as the product is in the early stage some issues can occur due to reasons like “BE is Not responding with correct response” or “The client (FE) request is invalid”.
In this case, the black-box tester simply reports an issue with the steps but QA won’t be able to make sure from whose end this issue is, and then they follow the default process (i.e. Assign issues To FE Developer). But assigning the task to the wrong developer leads to an increase in time for fixing the issue and as the developer will spend time in debugging the issue and then proceed further.
Examples:
a) Invalid Client Request:
GET https://lead.example.com/***app_name: com.example.agentsappapp_version: 1.23.0app_native_version: 1.23.0auth_token:content-type: application/jsonHost: lead.example.com
In this case, auth_token is being passed as a “Null” value and the server will not respond to such requests raised by the client. Here, the tester can get to know that this issue is from FE as the Front-End (FE) is not passing auth_token in the request. Similarly, there might be some other issues as well from the FE.
b) Invalid Server Response:
Assuming we undertake testing and the app is not able to load users data created or on which user has access, but the server responds with the following response:
It can be due to some implementation issue, that even with valid authentication and with the right request user is not able to access their data. Now, by looking at the response we can understand that it is a BE issue, as the server is not responding with an appropriate response.
These are very basic examples and can be rectified at our end only and then assign them to the right developer with the exact problem. This will reduce developers debugging time and will be very much helpful for increasing teams’ efficiency.
For such cases, OWASP Zap comes into the picture. If Zap setup is already there on the system, then Zap can help testers to identify issues happening between the client (FE) and the server while testing the Mobile application by looking at the network calls.
We have been using OWASP Zap at Anarock technology to check whether network calls are working fine or not on production and to check issues when the server is not responding or throwing any errors.
We hope testers find this information useful for network call testing using OWASP- and if you have any doubts or suggestions, then do comment below.
================
Originally published on LinkedIn
