Securing web applications with only a reverse proxy

Question

In order to secure its public HTTP API (so called REST), my client is asking me to implement a simple HTTP reverse proxy that will verify (OAuth 2.0) access tokens and forward HTTP requests to internal web services for processing.

The idea is that my client has "strong" network level security: the various web applications sitting behind the proxy would carry no security constraint as they cannot be accessed from the outside. They want to keep debugging easy when multiple internal services call each other. Plain http for internal calls, no TLS.

I'm thinking it's a terrible idea to leave internal applications "wide open" because any attacker that manages to get inside the network has basically free access to sensitive (cleartext) customer data... and history seems to prove that it happens a lot. From an operational standpoint, it will be a pain to enforce fine grain constraints like ACL from a proxy (OAuth scopes/URL matching), and maintain configuration up-to-date when new services are deployed.

Do you guys see anything I'm missing? Any additional argument for implementing application level security?

---

EDIT : Some important detail I did not clearly mention/explain :

• The web applications I'm talking about here (hiding behind only a security proxy) are all web services.
• Web applications with user interfaces (public/internal "sites") are in another network zone, and carry some decent application-level security compared to the web services in question.

The "strong" network security I mentioned is all about zones, end-users (and unauthorized insiders) theorically cannot access the web-services directly (only through the proxy). I guess ops could still offer some kind of route when they access the machines, as stated in the answers.

Answer 1

Based on my understanding, I think you don't even need to get inside the internal network to prove that's it's a terrible idea. An attacker (who can be an ex-employee, third party contractor or an existing disgruntled employee) having some context about this insecure internal application, including details such as internal host address where the application is hosted, important functionalities of the application, some knowledge of overall look and feel of the application (this will obviously help in creating a phising website), and of course, the fact that application is vulnerable to common web application issues (especially Cross-Site Request Forgery).

Alright. Based on the above assumptions, I can think of the following possible attacks:

• Tricking an internal user in making a state-changing request to the application by exploiting a CSRF vulnerability. This itself can be used to exploit other common vulnerabilities in the application by tricking an authenticated user to visit your website, where your JavaScript will be waiting to make requests to the application with your payloads, but with the victim's session cookies. You can send injection payloads for command injection, SQL injection, XSS, etc. Since you know your attack surface, you can craft the requests accordingly.

• Exploiting a misconfigured JSONP or CORS implementation on the application. Again, for this, you'll be utilizing the CSRF vulnerability to make a request to the internal application with their session cookies. But this time, instead of performing a state-changing request, your malicious JavaScript will be reading back the sensitive response from the application (because of JSONP and CORS). You can read more about it here, here and here.

• Phishing internal users (via DNS cache poisoning, maybe). Now since you know how the intenal application looks like, you can create a phishing website or just the login page for the application and host it on a public address. You can then either poison the DNS cache of the enterprise DNS server within the network, or by simply modifying the hosts file of internal systems (maybe by tricking them into downloading a malware). This last step is a bit tricky to exploit from outside the network, but I hope you get the idea. More details on DNS cache poisoning in case you are interested in further readings: DNS and DNS cache poisoning. Once you have that set up, there is nothing preventing you to phish the internal users because the application is not over TLS (no authentication)!

Answer 2

This is how a approach your situation in general.

Speak to the business

There are three things that I think clients can really relate to when discussing the security of their applications. (90% of the time the users are a footnote).

1. IP (Intellectual Property). No customer want their secrets available to their competition.
2. Image. Companies can be kindly motivated into better security measures if reputation and image are on the line. This can be especially true if your client is in a highly competitive environment where a breach could send users flocking to competition.
3. Money. Nothing motivates a company to act more than that threat of losing money. In security, it's the time and expense of hiring additional outside help, and in compliance situations, it's additionally the fines, that add up.

Speak to the team

In the security world, risk is the game we play and it's our job to convince business to adapt. From a technical standpoint we in the security team look at this type of scenario as "THIS IS SUCH A BASIC THING". From a businesses perspective their thought is "What's the REAL chance I am going to be compromised?"

I don't know your client or their network obviously, but here's the basics with how I would start (an try not to sound judgmental when asking questions):

• What is their "Secure network like"? Do they do best practices? Do things stay up to date?
• Why don't they want to apply the security? Knowledge base? Money? In your case debugging.
• Can their reason for not doing something be solved in a more secure manner? Debugging in a test environment comes to mind.

Lastly, Speak at there level

Small Business is not a Medium Corporation which is not a Large Corporation which is not a Fortune 500 catch me? There are wants, needs, and capabilities at all levels and if you were to tell a client they need another 50K in security appliances, you'd have a very reluctant business to work with.

The three things I would focus on:

• Speak to their industry. Knowing how the medical industry does something is nice, but if they work in industrical controls, they don't care.
• Speck at their profit margin. This goes back to my earlier statements about the size of a company. A burger King doesn't have the resources of Apple.
• Speak to their experiences. If their industry or competition has had a breach, speak to it. They will usually know (word gets around), if they haven't heard, it re-enforces the concepts that they may and likely are being targeted.

I know this doesn't exactly speak to the proxy issue at hand but I can't be specific on a detailed client situation without knowing about the client.

Answer 3

An internal user with a browser that also connects to the outside provides routes between the intranet and the public internet. I'm constantly pointing this out to people who tell me, "don't worry this is an internal web app".

HTTPS is necessary in your case. This not only protects against the threat you mention, someone who has broken into the network, but also against malicious insiders who don't need to break in. Besides exposing the sensitive data itself, without https you would be exposing credentials in cleartext, credentials that might provide even more access to internal resources. Problem is made worse if wireless is in use internally.

It sounds like internal users of these web apps would have no access control at all. I feel that access control should be built into the applications themselves.

If they want to make debugging easier, have a Test environment with the security controls turned off.

Our reverse proxy (Pound) does provide one security feature really well: It acts as an intermediary between external clients and our web resources. This allows us to use it to set access policy. This is one of your layers of protection for the sensitive, internal web applications you want to protect, but I don't think it should be the only layer.

Answer 4

I would personally do 3 things in this situation:

1. Show the client the data on the percentage of major breaches that are a result of phishing (Something like 95-97%)

2. Further show that phishing can directly lead to an attacker to sniffing traffic on the network and he/she can view every bit of data passing to and from those services.

3. Identify the quantity and quality of data that is being passed by these web services and present them to the client along with a risk model that attempts to quantify the potential cost in relation to the attacker's time sniffing traffic.

This relates mostly to a lack of SSL, but given your situation, that appears to be the most pressing issue.

Good luck with your endeavors. I understand how hard it is to emphasize security to a reluctant client. However you must always keep in mind your job is to increase business value, show them how you can do that and they will start to see your perspective.

Answer 5

The most common cyberattacks are summarized very well in the annual Verizon Breach Report: http://www.verizonenterprise.com/DBIR/

As can be read therein, phishing and credential theft attacks are two of the most common threats. Thus, if an internal system is compromised by someone accidentally clicking on a malicious link, an attacker is now inside the network, possibly able to watch all non-TLS traffic on that system's subnet. Then, that attacker may capture credentials and access the webserver internally without ever needing to use the reverse proxy.

Also, if people re-use credentials (common), they could be unaware that their passwords are being sent in the clear. An attacker could then use those credentials on OTHER systems, perhaps successfully in some cases. This not only opens the business up to possible breaches, but liability if this is discovered (I am not a lawyer - please discuss with the corporate attorney and/or insurance companies).

I hope this helps make your case.

Answer 6

There will eventually be a case where an action that is perfectly authorized at the proxy level will be able to cause unexpected behavior in a backend component. It's a matter of when, not if. This is a terrible idea. Your instincts on this are correct. Do anything you can to convince your client that they should not proceed down this path.