How to Prevent Downtime of Web Services, by Automating Your Security Testing.
Each developer who works on a web service bears incredibly huge responsibilities. Especially when it comes to eCommerce platforms, health services, or trading platforms, any downtime of the service can be devastating.
In the worst case scenario, customers lose the trust in your platform, and turn their backs on your service. That would be a total disaster for everyone who is involved in the incident, especially for the guy(s), who are responsible for the security and availability of the platform.
When your platform is down again!
Complex web services and platforms have many dependencies and different modules that communicate with each other. This makes it very difficult to secure these applications. Not only the individual modules need to be tested, but also the various interfaces (APIs) between the modules.
However, testing each module individually is incredibly time-consuming. Also, a great number of bugs probably remain undiscovered, because they only get triggered if all modules interact with each other in the running application. These unpredictable inter-dependencies represent a major security risk for many web services.
To ensure the reliability and availability of your services, you will have no other chance than to test your web applications with a holistic approach. This means testing entire monoliths or microservice systems as a whole. But with so many test scenarios and edge cases to be covered, you definitely need some kind of automated security testing.
And if you think about it, it really makes sense to automate your testing process as much as possible for many reasons. By automating your security tests, you would finally have more time for all your other tasks AND your application would become more reliable and secure at the same time.
The best way I can answer this question is, by giving you an example. In this scenario, there are three web services that are running inside a Kubernetes environment.
In the past, developers and pentesters had to test each service and API manually, and each component had to be tested individually. There was no way to test interdependent services that interact with each other with only one automated testing approach. Instead, developers and pentesters relied on a combination of different tools and testing approaches, which made it very complicated to secure your web services properly.
How they secured web services in the old days
But today, many testing solutions can help you to fuzz your whole microservice environment at once. CI Fuzz, for example, offers simple plug-and-play integration that makes it very easy to set up fuzz testing for web services. The process is as simple as running a black box scanner, and will help improve the reliability and availability of your web service significantly.
The fuzzer starts by simply sending HTTP requests to the application, and behaves like a client that knows nothing about the application. However, by injecting a couple of fuzzing agents into the JVM, the fuzzer will get detailed feedback about the structure of the applications. With this knowledge, the fuzzer can then mutate and adjust its inputs to achieve even higher code coverage with each run. If you want to dig deeper that technology I can also recomend you this article about the magic behind feedback-based fuzzing.
Although, this approach cannot fully replace a final pentest, fuzzing can help you to already fix most of the low-hanging fruits in a very early stage of your development process. You will find most OWASP vulnerabilities with this approach, because the fuzzer automatically monitors the program for any for exceptions such as crashes, denial of service errors (DoS), and injections. This will help you to improve the reliability and security of your platform.
If you're curious to see, how this approach works in action, I prepared a tutorial on how to fuzz web services in a complex Kubernetes environment. And if you would like to try out the CI Fuzz testing platform yourself, reach out to me via email or Twitter.