2

When building an n-tier/layered web application where each tier is physically separated from the others, is it important for a different communication stack to be used by the backend tier(s)—which are not exposed to the Internet—than the web tier that is?

Being security conscious in building a web application, I am building a middle-tier (backend-tier, application server) that handles all data access for the web application so that the web server never has direct access to the database.

I have been thinking I need to make the application server use a different communication protocol than that exposed on the web server. If my middle-tier exposes HTTP/REST web services using the same technology stack as the web server, would not the middle-tier be just as easily compromised?

As such, I have been making the middle-tier communicate by a binary TCP protocol while the web server exposes HTTP/REST webservices. The down side to this is all the additional overhead. I need to both define interfaces twice (once for the application server and once for the web server) and need to deal with two libraries/communication protocols and their quirks.

Is this the complexity that secure web application development demands? Am I right in needing to use different protocols/libraries the Application Server and the Web Server?

Edited to add: This concerns mitigation in the event the web server is compromised. The web server can do far less than the middle-tier (most notably, not access the database). An attacker compromising the of the web server would be bad; but, achieving unfettered access to the database would be far worse.

Improve this question
8
  • 1
    I don't understand why you believe that using one protocol to communicate with the end user, and another to communicate with your database makes you more secure.
    – Steve Sether
    Jan 29, 2015 at 16:29
  • @SteveSether The only concern with the web server having direct database access is if the web server becomes compromised. If the only public face of the web server is that communication protocol, then it would likely be a vulnerability in that stack allowing the compromise. If that attack vector worked against the web server, and I use the same stack on the middle-tier then the same attack would compromise-middle tier it would seem I gained nothing from the separation.
    – vossad01
    Jan 29, 2015 at 17:33
  • 1
    You're confusing a protocol with separating layers. If you can cleanly separate your web server from whatever layer is sitting between the two, you might get some amount of added security, but any attacker would at least be able to do everything the webserver is capable of doing. The key though is cleanly separating the two so a vulnerability doesn't give access to the other layer.
    – Steve Sether
    Jan 29, 2015 at 18:26
  • @SteveSether Perhaps "integration mechanism/implementation" would be a better way to present it than "communication protocol"? (It is after all more likely a vulnerability implementation than the protocol itself after all). Assuming separation into layers/tiers, somehow those layers need need to integrate/communicate.
    – vossad01
    Jan 29, 2015 at 18:57
  • Yes exactly, and that's why you need to cleanly separate the layers. Ultimately your database listens on a port that receives data. Packet filters are a common way to only allow one host to talk to the database. But for instance if you put the webserver and your DB communication layer on the same host/IP, you haven't really done much to secure anything since vulnerabilities in a webserver often give OS level access, which allows you to use the IP address of the host just like your middle tier does. IMO these sorts of layer separations are more trouble than they're worth.
    – Steve Sether
    Jan 29, 2015 at 19:07

3 Answers 3

Reset to default
2

Using a different stack / transport protocol doesn't significantly reduce much risk.

client --([1]http)--> frontend --([2]binary)--> backend --([3]mssql/odbc/?)--> database

Three protocols labeled [1], [2], and [3]. If an attacker compromises the frontend server, it doesn't matter what protocol is used for [2]. The attacker will have the same permissions as any process running on the front end, regardless of the protocol used for [2].

I'd put less energy in swapping protocols and more energy in monitoring the traffic from the frontend to the backend. That traffic is more likely to show anomalies because frontend to backend traffic is usually clearly defined. Client to frontend traffic is not as easy to detect anomalies because every browser, every scanner, every hacker is trying to break in all the time. But if you are able to detect that a compromise has already taken place, you're going to be able to mitigate damage.

Back to your protocol question. Because HTTP is clear text, it is easier to monitor. You can detect unusual requests, and alert your incident response.

Just my 2 cents.

Improve this answer
1

No, it's not important. You're suggesting either security through obscurity, or raising the bar to defect discovery.

What's important is that you properly model all assets in the realm for security exposures and vulnerabilities.

You should take a step back, and re-start by implementing a well designed security development lifecycle. That process will include Training, Requirements, Design, Implementation, Verification, Release and Response.

There are any number of good reference materials to help you in the process. But a few good places to start:

  • "The Security Development Lifecycle" (Michael Howard)
  • "Threat Modeling: Designing for Security" (Adam Shostack)
  • "Building Secure Software" (John Viega)
Improve this answer
1
  • Layered security is a counter point. His premise is that if there is a flaw in the rest/http communication stack, and the same stack is used everywhere, then all stacks are compromised by a single bug. It's a stretch, but there is some risk mitigation to use different stacks.
    – Jonathan
    Jan 29, 2015 at 18:57
0

If your design assessment / requirements have determined that a middle tier is necessary then your logic is sound.

Assuming the same product suite has to be used for the outer and middle tiers then provided the middle tier protocol does use different software components / technology stack to the outer tier protocol, then in theory an exploitable vulnerability in the outer tier service will not lead to a direct onward compromise of the middle tier based on the same vulnerability/exploit.

Depending what you are trying to achieve it may be worth having a look around to see if there is more robust application proxying option available for use in the middle tier.

Obviously there will be other risks in the solution, which will need controls to prevent unauthorised access resulting in apparently authorised traffic being sent from the outer tier to the middle tier.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .