Testing Microservice Architectures
Microservice architectures are growing increasingly complex. This leaves us with the question:
How can we secure them?
Why Is It So Complicated to Test Microservices
Complex microservices have many dependencies, which makes it even harder to secure these applications. Except for individual modules, also the various interfaces (APIs) between the modules need to be tested. This is extremely time-consuming. Moreover, a large number of vulnerabilities could remain undiscovered. Such unpredictable interdependencies are the main security risk for many microservices. In this webinar, I will present a simple plug-and-play integration that enables you to simplify this process and to test a whole microservice environment at once.
In this excerpt from the recording, I discuss why microservices are so difficult to secure.
How to Automate Security Testing for Microservices?
There are different methods to automate your security testing. For instance, with black box scanners like OWASP ZAP or Burp Suite. In this recording, I will explain this, using OWASP/WebGoat as an example. The traditional way would be to combine different tools and testing approaches, but you would usually have to test each service and API separately, which also makes it really complex to secure this web services properly.
How they secured web services in the old days
How to Simplify Security Testing for Microservices?
However, there is another, simpler approach to automate the security testing for microservices. I'm talking about feedback-based fuzz testing. Compared with the other testing approaches, this method works directly on the source code (white-box), and it's currently considered the most effective approach to detect unknown vulnerabilities, why it's also widely adopted by tech companies like Google. The company claims to have found more than 25.000 bugs with this approach, in Google Chrome alone. Nowadays, many testing solutions will even help you to run advanced fuzz test, with little to no effort.
With fuzzing it becomes very easy to test individual modules in your web application, and the entire communication between the different services. The fuzzer just sends HTTP 503 requests to the application and acts like a customer who knows nothing about the application. Later, by injecting some fuzzing agents into the JVM, the fuzzer gets detailed feedback about the structure of the applications. Knowing this, the fuzzer can then mutate and adjusts its inputs to get even higher code coverage with each run. If you tend to dig deeper than technology I recommend the article about the magic behind feedback-based fuzzing.
Fuzzing Detects the Most Common Web Vulnerabilities
Even though fuzz testing does not fully replace a final pentest, this approach helps you to fix most of the low-hanging fruits in an early stage of your development process. Most OWASP vulnerabilities can be detected with this approach because the fuzzer automatically monitors the program for crashes, denial of service errors (DoS), and injections. This greatly helps to improve the reliability and security of your platform.
See the Process in Action!
I provided you with a webinar on plug-and-play integration. Feel free to reach out, and share some feedback!
Related Articles and Use Cases
Read more on automated security testing in our Code Intelligence Blog.
The Magic behind
Feedback-based Fuzzing
Are you curious why fuzzing is so popular right now and are looking for more information? Read this blog article.
HTTP 503
(Service Unavailable)
How to Prevent Downtime of Web Services, by Automating Your Security Testing.
Using Modern Fuzzing to Detect SQL Injections
Feedback-based fuzzing maximizes code-coverage and allows us to detect SQL injections through effective bug detection mechanisms.