In this article, I delve into the AI Nutrition-Pro experiment, a research project exploring the potential of LLMs in enhancing security practices during the design phase of DevSecOps: threat modeling and security review.
Server-Side Request Forgery (SSRF) vulnerabilities have been around for a long time, and they still pose a significant threat to web applications, so much so this kind of vulnerability has been included in OWASP TOP 10. This time I will explain how to mitigate SSRF vulnerability in Go applications.
What is Threat Modeling? First of all, it’s just thinking about threats. We all do it, every day 😃 How someone could break into my house? But wait a second. How do you know that you need to protect your house in the first place? Maybe you don’t have a house, or maybe you don’t have money right now to buy deterrents. Or maybe your family thinks you are a bit paranoid? 😕
In October 2021 I was researched ingress-nginx for possibility to bypass external authentication using path traversal. It was origin story for other investigations regarding insecure usage of $request_uri which leaded to Apache APISIX CVE-2021-43557.
To successful bypass access control using path traversal in $request_uri, you need to have buggy authentication/authorization service. Buggy in a way it’s not normalizing url/uri that is part of access control decision. Let me find more of those on github that are relying on X-Original-Url.
In this article, I will extend topic by bug bounty tips for weaknesses in authentication/authorization implementation in relation to nginx’s $request_uri variable. APIs This vulnerability is for APIs. Best scenario are microservice deployed to Kubernetes and exposed by ingress controller.
In this part I will research another ingress controller based on nginx: 🦍 kong. At the end of article I will mention in short F5 NGINX Ingress Controller. In kong there is no explicit feature called external authentication, but developers gave possibility to create it using plugins.