API Gateway

[em mazzon]

Hi

Does anyone have any recommendations of the main API GW's that can manage the majority of the OWASP API security risks

Thanks

Matt

[prjam...@gmail.com]

You will need a security solution try apisec.io 

-Peter 

On Sep 28, 2021, at 9:17 AM, em mazzon <mazz...@gmail.com> wrote:

Hi

Does anyone have any recommendations of the main API GW's that can manage the majority of the OWASP API security risks

Thanks

Matt

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/a8a92029-26d4-46d2-a03c-9af3ac634a7an%40owasp.org.

[Michael Isbitski]

APIsec.io resolves to apisecurity.io (operated by 42Crunch), which is a security awareness resource. APIsec.ai is a security testing vendor.  

The original poster was asking about API gateways though. The short answer is that no API gateway can fully address the API Security Top 10 since they are mediation mechanisms. Mitigating all the risks described in the API Security Top 10 requires many techniques and tooling that encompasses discovery, mediation, security testing, access control, observability, runtime protection, etc. In this context, any API gateway, irrespective of vendor, functions as an enforcement point for some security controls like authentication, authorization, and message filtering, but more is required to fully address the OWASP API Security Top 10.

I'm staying vendor neutral here in the spirit of OWASP, but that last answer needed clarification. 

[Owen Rubel]

No gateway can due to a 'forward' (see forward vs redirect). Every web server can route like this (including node.js) as it is part of W3C standard but a FORWARD will reuse the request to send to another endpoint internally allowing the token to be checked for security internally.

This means you have to redundantly check security in the application to be 100% secure and that the api gateway ultimately is redundant/insecure when it comes to security as it cannot check for forwards.

Owen Rubel
oru...@gmail.com

--

[Owen Rubel]

allow me to clarify on my answer... the Gateway is only insecure in the fact that if you place ALL SECURITY IN THE GATEWAY, FORWARDS WILL BYPASS THIS!

And Forwards aree far more efficient, are used in chaining, can reuse tokens, reduce network overhead, etc.

Thus while many think they are reducing network overhead by placing security in the gateway, they are actually increasing it in alot of ways by having to do redirects and creating a security hole as a result of not addressing forwards.

[alton crossley]

My two-bits since I am dealing with this right now too. And I must mention your question was to the point, so I am not sure you are looking for a "Click here to do all the security" solution. But I do think this is an enjoyable conversation to have.

Depending on the API Gateway implementation there is much that can be done to enforce security on the incoming request before it is forwarded. But to Owin's point, perhaps from a different perspective, the application should be considered to have a trust boundry at HTTP. The gateway may enforce things, but the application should still treat input as untrusted and still escape output. 

Long ago we came to grips with the fact that a firewall was not enough. An API Gateway is simply a Layer 6 or 7 firewall and is defense in-depth. Once through the gateway/firewall it is still an HTTP request going over a network to other servers. If you are using containerization, you have a level of abstraction, but at the end of the day it is still HTTP, packets, DNS and routing. There is no guarantee that packets are not going over a wire. If you are using containers in the cloud, that wire is not yours, that hardware is not yours. 

Relying entirely on the firewall for security leaves you open for other attacks. Your applications should still be performing all security practices. Depending on the threat model, the constraints may have relaxed values, but the checks should still be done. You may decide to log and alert instead of reject. But never stop doing the checks.

I would also like to echo that the OWASP API guidelines purposely indicate that security is an intricate latus of protections, involving all organizational groups, which cannot be purchased as a solitary product anywhere on the planet.

-- 

Alton Crossley

[Owen Rubel]

Indeed. All input should be untrusted. And we are saying the same thing in this regard.

I am adding to the conversation in saying the gateway is a redundancy and has a huge hole in the fact that if anyone uses a forward in the application, it bypasses the gateway... thus the gateway misses 50% of routing. It only handles the routing with the HIGHEST OVERHEAD.

As such, the application will ALWAYS need to implement security within an 'interceptor' to check security before routing to the endpoint/controller that way the postHandler can do a handoff to the preHandler in the Interceptor

Owen Rubel
oru...@gmail.com

[Owen Rubel]

And for the record, no one mentioned anything about a firewall.

Owen Rubel
oru...@gmail.com

On Thu, Sep 30, 2021 at 8:53 AM alton crossley <alton.c...@owasp.org> wrote:

[alton.c...@owasp.org]

Understood. I put a couple sentences out of order that introduced ‘firewall’ before I made the connection to an API Gateway. Thank you for the opportunity to correct that.

 

In the environment I am working in the API Gateway is a full-fledged reverse proxy that has access to see and alter all data in the request. That is to say FORWARD is an internal application implemented function (to my understanding per the specifications). Therefor there is plenty of security that can be done there, however the purpose is much broader than the API service itself as well as the fact that the gateway then passes the request back onto the network that should have limited trust (some may say it is tantamount to a DMZ, thus another nod to a firewall). So in my circumstances, FORWARD does not bypass the gateway, but the web services still treat the request nearly the same as if they were directly facing the public web.

 

Not saying that anyone here does this, but I feel like there are development teams that fall into the rut of using microservice style as an excuse to just trust user input all too freely. As well as business types that still look for security-in-a-box. I definitely run into vendors trying to sell such solutions. I am glad that there are critical minds like the ones here that see past the marketing.

 

--

Alton Crossley