5

Inspired by this question: How to approach API testing.

The first point of a checklist in the above question is "API Endpoints".

But, what to do when you don't have the endpoints documented because either the developers don't have the time to do it or it is a legacy project with unexisting documentation or such?

Do you need to guess the endpoints or examine the network traffic to discover them or is there another way?

Improve this question

4 Answers 4

Reset to default
4

You can use tools like owasp zap to find all the API calls. It spiders through most of the endpoints in search of security vulnerabilities.

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Read about different scans:

https://github.com/zaproxy/zaproxy/wiki/ZAP-Full-Scan

https://github.com/zaproxy/zaproxy/wiki/ZAP-API-Scan

https://zaproxy.blogspot.com/2017/06/scanning-apis-with-zap.html

Improve this answer
7
  • That looks nice. Is it legal? :)
    – Mate Mrše
    Nov 19, 2019 at 13:35
  • @MateMrše it depends on the test artifact and the testers scope of work. Spider scan is passive scan and does not actually attack the end point so you are mostly safe to use it. But stay away from active scan, because passive scan is just finding possible vulnerable end points and active scan is actually attacking the endpoints to verify the identified vulnerability
    – PDHide ♦
    Nov 19, 2019 at 13:37
  • Have you had the experience of usage of such tools? Can you explain in couple of words how it can find endpoints we do not know about?
    – Alexey R.
    Nov 19, 2019 at 13:46
  • 1
    I used it for webapi , just install the application and provide the web index url. Eg: www.home.com/ . It will go through all the endpoints like www.home.com/user , www.home.com/page2 bla bla and reports vulnerabilities in it.
    – PDHide ♦
    Nov 19, 2019 at 13:56
  • Give url and click start scan ,
    – PDHide ♦
    Nov 19, 2019 at 13:56
4

If you have no endpoint documentation then the things are really bad. I would use the following aproach:

  • examine known clients which use the api
  • extract all possible invokations which the client can do
  • guess what is the client missing but might be supported by server like if you have order/create then there is a chance the server has order/update as well
  • guess what could be the meaning of data that is sent to the api
  • guess data types and ranges which are implied
  • prepared the tests basing on this guess

Or if you have server code

  • examine server code to extract api

Or if you have server binary

  • decompile binary
  • extract api from decompiled code
Improve this answer
3

My approach would be to examine the network traffic.

If the application operates over HTTP/HTTPS, the easiest way to do this is to use a tool called mitmproxy as a proxy that sits between the client and the server, and examines and logs all requests that pass between them. Using this tool, you can see all the endpoints the client hits during normal operation and the payloads, headers, parameters, etc of each request.

With this proxy up and running, you'd then need to explore all features of the app that you can (perhaps with some form of automation), and document all the endpoints it hits during your exploration.

Hope that helps. I just used this technique this past weekend to reverse engineer the private, undocumented API of an investing app I use. It worked wonderfully!

Improve this answer
2

My experience is that even if there is some documentation, it's quite often rather vague and incomplete. So, you should never completely rely on just documentation even if it's presented to you as good documentation (you want to be a sceptical tester).

Therefore, the following points are pretty much valid in any situation - if you have or don't have documentation:

  • read whatever you can - documentation, former bug reports, code, old emails/discussions where developers talked about endpoints
  • ask developers - I guess there will not be as unhelpful and busy as they can't spend 15 minutes talking to you
  • ask consumers of the API - those endpoints might be used by a completely different team, you might want to ask them, not people on your team
  • read the code - you can find paths/conditions/... that documentation doesn't mention, so I'd always try to read at least some of the code for API endpoints, I have had only good experience with this point, having found bugs that were lying in the code for months undetected by other testers
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.