Recently at a meetup about microservices, RESTful & Co. I thought about the following conversation, just before the next talk started:
‚We are now doing Microservices and the first dozen is already in production.‘ ‚Quite nice, and how do you do security?‘ the other guy asked. A few seconds of silence followed. ‚Actually we do not need security, they are just used internally and everything is behind a firewall‘. The next talk began – about bounded contexts.
However, security is not only a matter of preventing attacks and threats from outside of the own systems. Even internal clients like other services could run mad and harm a service. I.e. security is also a matter of misusage or unexpected usage of a service.
One weak part of a RESTful service is its interface and the possibilities how to use it, respectively how to ensure that is used as it is intended to be used. Of course, validation is one part of the story how to deal with harming usage, but the story starts before validation and does not end with it, as described by the Open Web Application Security Project (OWASP):
Assist the user > Reject input > Sanitize (filtering) > No input validation
Covering all that aspects in one small blog post won’t fit – but it’s worth skimming the OWASP advice how to secure and validate RESTful services.
If you work on the validation part of your service i.e. validating of parameters, URLs, payload, attributes etc., testing the interface is obligatory and must be done as early as possible. Having tests in place, to get an idea how a service works in case of unexpected usage, could be a good idea too. In addition to lots of security advice, the OWASP initiative provides the tool Zed Attack Proxy (ZAP). Besides automated security testing, ZAP can help you to get an idea how the application responses in case of the unexpected usage – even automated. To get an overview about automated test-support of ZAP in terms of the unexpected usage of a service, have a glance at ZAP’s Fuzzer Concept:
Fuzzing is a technique of submitting lots of invalid or unexpected data to a target.
Basic components of the Fuzzer are:
Payload Generators: Payload Generators generate the raw attacks that the fuzzer submits to the target application.
Payload Processors: Payload Processors can be used to change specific payloads before they are submitted.
Fuzz Location Processors: Fuzz Location Processors can be used to change all of the payloads before they are submitted.
Message Processors: Message Processors can access and change the messages being fuzzed, control the fuzzing process and interact with the ZAP UI.
… quite a lot of possibilities to create unexpected messages.
At the end of the day the first step is to be aware of possible misusage and unexpected usage of a service and the issues that could occur. Unfortunately it is not possible to anticipate all unexpected usage issues – but that’s immanent in this case.
