Is it reasonable to use a security proxy when integrating two web applications?

Question

Background: We're in the process of integrating two web applications. The other one, application A, is a publicly accessible Internet service, which is provided by a third party and which offers Web Service APIs we'll integrate with. The other one, application B, is an old(ish) legacy application hosted in a company intranet. At the moment, application B can't be accessed from the Internet. It is quite a large system, and it exposes many open APIs that are meant for system integrations strictly inside the intranet. We can't afford to expose these APIs to be accessible from the Internet (intentionally or by accident). We control application B, and can implement the new features and APIs related to the new integration however we please.

I've done some digging, trying to find out the most appropriate solution for these security challenges. Some sources suggest that a Web Service security proxy (or a security gateway as some call it) would provide additional security in a case like this. This proxy is apparently often hosted in a DMZ. The proxy would basically perform the security functions that are required, such as message encryption/decryption, performing authentication and message integrity checks, auditing etc. I gather that an approach like this is most reasonable when integrating existing applications where the communications of the applications are not secured at the moment, but the integration should be implemented without having to modify the applications themselves. However, I would guess that the main advantage of a proxy in our situation (when there are only 2 applications) would be to only expose the limited API in application B which is needed for the integration to the outside and hide everything else. Some side benefits might be that it offloads some work that would otherwise fall on application B (such as cryptography, message validation, detecting possible attacks etc.) and might provide some additional protection for DoS attacks. Are my interpretations here correct?

The real question is, what would be the most secure way to make the API created for the integration accessible from the outside and prevent access to everything else in application B? Would a security proxy be a reasonable addition to improve the security of application B (in the ways I described or in some other ways), or is a direct point-to-point integration enough? What other approaches could be reasonable? The security aspects here are paramount, but I would naturally want to avoid over-engineering.

Answer 1

Let us assume that updating or replacing application B is not an option, that you're trying to retrofit security onto a legacy application.

In that case, my recommendation would be to use a WAF as "the most secure way to make the API created for the integration accessible from the outside and prevent access to everything else in application B?"

A Web Application Firewall is a mix of a proxy, as you've suggested, and a web app focused IDS/IPS. Examples would be F5's Application Security Manager (ASM) and Imperva's SecureSphere.

At a minimum, a WAF will allow you control over the APIs that are accessed. For example, if application B is RESTful, then the WAF can be used to prohibit access to this part of the API while also permitting access to that part of the API. Depending on how the application is written, and the flexibility of the WAF, this can be true for multiple types of API (F5 iRules allow custom filters to be written in great power and detail).

In addition, a WAF will look for various attacks, things like parser attacks, overflows, command invocations, all the things you don't want someone sending to your legacy application server.