Does using web services to expose a .NET DAL add security?

Question

Currently my employer deploys a web application over 3 servers.

1. DB - No public route
2. Web Service DAL - No public route
3. Web Server - Public route

The reason for this is the theory that if the web server is compromised, they don't arrive at the DB directly, but instead arrive at the DAL box.

To my mind, as the DAL box and Web Sever box - both run windows/IIS - if the public box has been compromised, the same exploit would likely work on the DAL box - therefore I do not see this as a real security benefit.

I would like to propose we remove the middle machine and allow the web server to connect directly to the database.

Is this middle box really a benefit?

Answer 1

This is almost security by obfuscation, but the middle box does provide an additional level of security if it is also backed up by a corresponding firewall. If the DB is kept in a secured private firewalled area, a web service machine could be placed on a middle tier DMZ box that would be accessible to the public side web site. While the exploit would conceivably work on all 3 boxes, the attacker would still have to compromise 2 levels of firewall in order to deploy the exploit.

If there is no firewall separation of this nature (though by your description it sounds as if there is), then you're correct, the exploit could be deployed repeatedly. It sounds like your company has a firewall between website and web service DAL though, so as long as connections are restricted and monitored, the exploit becomes an almost non-event.

Answer 2

Having the web app contact the DAL layer via a web service can add a lot to the security of the data. It may still be possible to compromise the web app, but you have just made it next to impossible for the exploiter to get to the database.

If you have it set up this way:

web app --> |  DAL layer   |  database

external    |  network     |  internal
                 DMZ  

you can set your network routing so that it is impossible to get directly from the outside to the DAL layer which sits in the DMZ, or possibly even in the internal part of the network. if you do WCF with a binary encoding through a specific port, you can set up firewall rules to only allow the web server through that specific port to that machine containing the DAL layer. This means if your web app gets compromised, the most the attacker will get is the details of the WCF endpoint, which they will be unable to reach unless their attack is launched from the web server.

If you further obfuscate things by only using stored procedures etc. from the DAL layer, then the most the attacker can do if he gets to your DAL is call the same database functionality that the web app was using anyway. Getting control of the DAL layer means he can bypass any validation that you had on the web server, but ideally that validation should also exist in the DAL layer or in the database stored procs (it's the safe way to build your WCF services, you don't always know that your web services are going to be hidden away from public view, maybe one day requirements will change and the web services will be exposed in a way that means anyone can call them).

Answer 3

The security benefits of a web service layer between you web UI and database are, at best, minimal. Even with the network infrastructure suggested by slugster, your attacker is only unable to access the web services from his/her machine. Considering such a compromise would most likely also give the attacker some form of remote access to the web server itself, your network level access restrictions are totally useless. You might manage to prevent some forms of attach, but if someone is interested in getting access to the box, once they get it there is nothing on your network that will be able to distinguish an attacker from a legitimate user.

What makes it worse is that you are stuck with an extra layer of code that you have to maintain to support this extra layer, which means you are going to have more bugs, and it is going to take longer to create new features.

One approach to this would be to utilize some of the techniques described by the folks talking about CQRS in an architectural context. Specifically in this presentation by Udi Dahan he flat out suggests putting your database on the web server, and only storing the data in it you need to support the web site. The other data, the business data, is stored elsewhere, in a separate database. You could also use NoSQL databases, like MongoDB or RavenDB for the presentation data and forgo the relational database altogether.

There are a lot of options out there, and some of them will even give you the level of security you think your getting with your current architecture. It is always a good idea to provide some critical thinking to these sorts of decisions, and I find it encouraging that your asking these sorts of questions.

Good luck.