2

At my organisation we have a website survey that one of the managers here uses for equality purposes. They designed and implemented the survey in Adobe FormsCentral which is now being retired, so I was asked to create something similar.

I'm going to be creating the survey using ASP.Net MVC, and have been thinking about adding the data to a database on an SQL server, so the data can be downloaded at leisure by the manager. The only issue I have is that my manager (not the same one that wants the survey) is worried about the security of the application.

Specifically he's worried about the fact we'll be creating a link from our web server (in a DMZ) to our SQL server that is currently only used internally. Although I want to say 'it will be fine', he does have a point. If the web server is compromised, it could then expose our database server, along with credentials to access it.

I will limit the credentials so that the survey only has write permissions to the specific table used, but I'm not sure if there are any ways to protect the credentials used to access the database server. I'll only be using read credentials on an intranet page that the manager can then use to download the results.

Is it possible to hide credentials from someone who gains access to the web server? Or is the answer 'Don't let your web server get hacked'? I'm interested in this for future reference too, as we might end up storing more sensitive data, for example customer addresses in future, and give access to them via the internet, rather than internally.

And are there any other things that I should be looking out for? I will already be guarding against SQL injection and scripting attacks.

For extra information, the web server has HTTPS and the SQL server has customer details stored in other databases, but these won't be touched by the application. Any help or advice on this would be appreciated.

5
  • This is more a development question than a security one. From a security point of view, however, any answer will have to take into account the value of the data you're storing on that database server so it is hard to give a "general purpose" answer.
    – Stephane
    Jun 11, 2015 at 8:45
  • A "web site" compromise is different from a "web server" compromise. The latter includes all web sites on that server including system accounts. A much larger scope. Are you referring to just your "web site" being hacked? Jun 11, 2015 at 23:14
  • I'm talking about the web server itself, so someone can see the .Net application, decompile it, see where our database server is and use the login information that the application is using to compromise the database server.
    – James R
    Jun 12, 2015 at 12:35
  • @JamesR Probably just semantics here, but an attacker with access to the web server wouldn't be decompiling the .NET application. The login would not be revealed either. (The password would remain safe if the site uses a Trusted Connection.) Instead, they would swap out the website(s) with their own and do whatever they want with the same permissions as the user running the original website(s).
    – TTT
    Jun 16, 2015 at 22:59
  • Hi, I know that an attacker probably wouldn't be bothered trying to mess around with our database server, and would instead mess with the site itself, but my manager still worries, so I wanted to put his mind at ease.
    – James R
    Jun 24, 2015 at 12:32

2 Answers 2

0

Even if the web server is compromised, the credentials used to connect to SQL Server would not be compromised, if you use what's called a Trusted Connection, and this is recommended. Basically that means you set up your Application Pool in IIS to run as a particular user, let's call it "IISUser". Then you give IISUser the minimum set of permissions to SQL Server required for the application. For example, write only access to the survey data table, and read-only access to the manager data tables. You can remove all other access for that user. So now if the web server is compromised, the user/pass of IISUser are still safe, and even though the attacker can modify the web application to do different things which will run as the IISUser, they are still limited to the minimum access permissions to SQL Server that you have given to the that user.

That being said, you should also take steps to make sure your web server is not compromised, because if it is they can present whatever web pages they want to your users. (Collecting user/pass from users, etc.)

4
  • Thanks, that's the kind of answer I was looking for, although I can't actually do that, because the server is on a different domain (I forgot that part). This answer has at least given me a bit to work with though, and in the future we might be able to get it onto the same domain and make it a lot more secure.
    – James R
    Jun 12, 2015 at 12:32
  • Also, we're definitely keeping the web server as locked down as possible. We don't think it will necessarily be hacked, or even a target, just my manager is wary of it.
    – James R
    Jun 12, 2015 at 12:33
  • @JamesR There is a way to connect from a different domain, if you set up a domain trust (The domain SQL Server resides in can be instructed to trust logins from another domain). You'll have to decide which is better for your situation: moving the Web server into the same domain, or allowing the SQL Server domain to trust the Web Server domain.
    – TTT
    Jun 14, 2015 at 17:48
  • Hi,thanks for that. I thought the trust would have to come from the web server domain (which would be a battle from what I could tell). Doing it from the SQL server domain however is something we have more control over, and I think a trust already exists, so I'll check it out.
    – James R
    Jun 24, 2015 at 12:31
0

You could, if you want to do extra amounts of work, have an intermediate middleware layer that brokers requests from the dmz web server. It could be as simple as a rest based api ( it might not be simple :) ). Once again the amount of work is dependent on the monetary loss associated with the data.

Also if you approach this from a programming perspective, that will be the methodology. But if you approach it from the inevitability of data loss, then you would go with a backup policy.

You must log in to answer this question.

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