question

xypher avatar image
xypher asked

Web Site Security for SQL

I have been giving thought to security lately. Mostly because one of my web applications authenticates to a SQL database. I'm wondering what the best practices are for making sure our database is secure from injection or poisoning in a web application? We have a good deal of site protection and hardening in place, but I believe IIS and .NET have been known for weaknesses. If a service account is compromised, is it common for secure SQL data to be obtained? Any advice here is appreciated.
securityweb-service
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Tim avatar image
Tim answered
For starters you should change the default port from 1433 to something else. Everyone and their 4 year old child knows that SQL uses port 1433. If someone compromises your web server you can bet they will be checking for that. As for SQL injection, use stored procedures with parametrized SQL since SQL parameters are type safe. Type-safe SQL parameters can also be used with dynamic SQL. If you can't use parametrized SQL in some cases use character escaping techniques to limit your vulnerability. You should also use a SQL account with the most restricted access as possible. If you don't have to be DDL Admin or DBO, don't use an account with those privileges.
3 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Whilst not a complete waste of time, changing the port is of limited benefit as it is very easy to locate the port that IS being used. A little extra security by obfuscation but not something that would stop a serious attack. The other points you make are far more effective and should be considered a requirement in the scenario of this question. +1
1 Like 1 ·
Glad someone else feels the same way about the port. I have beat my head against the wall with info sec folks on that point. If someone compromises a server a simple port scan will reveal all your dirty little secrets.
0 Likes 0 ·
+1 to all, these are really good answers! I have been already looking at some of this, but to hear it from others really helps. So far I have been working on the IIS portion by giving very generic error pages that will not give any information that may aid the attacker. Working on doing the same for the .NET code as well. It is a challenge sometimes with different browsers, so we have to code for each. Lately the site started working with the latest Firefox, which was pretty interesting. On another note, I am glad the site itself is not running under the service account that has permissions on the database. Thanks again for all the information, and feel free to give more!
0 Likes 0 ·
Matt Whitfield avatar image
Matt Whitfield answered
+1 to TRAD - I will add a couple of things. If you are coding under IIS/.NET then you will be protected, to some extend, by the form validation. That takes any dodgy looking requests and rejects them - so there is an added layer of protection against SQL injection, which is nice, but really, you need to follow @TRAD's advice, and make sure that all your data access is parameterised... .NET makes this very easy, and there is a lot of information to check on that. Basic rule - if you're not using the Parameters property of SqlCommand or DbCommand, then you're probably doing it wrong.
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

AdaTheDev avatar image
AdaTheDev answered
+1 to both TRAD and Matt Also, ensure that database exceptions never get dumped out to screen for all to see. If someone is able to cause an exception, then that information could aid them to further hone their attack. So always ensure you catch exceptions, log them out somewhere so you can review, and display a user-friendly, less technically-specific error message. Validate, validate, validate - even if you validate user input clientside in javascript, always assume that nobbled/dodgy data can get through to the backend code as the clientside validation can be circumvented. So validate serverside too. If you use stored procedures, then you can grant EXECUTE permissions to those stored procedures only, without needing to grant direct access to the underlying tables which can give you another level of security.
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

TimothyAWiseman avatar image
TimothyAWiseman answered
Every other answer here is great, but perhaps I can add a couple of constructive things. I recently wrote an article about SQL Injection that is available at [ http://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/][1] but the biggest point there is paramaterization as TRAD mentioned. It is also worth pointing out the value of (after proper testing) the latest patches available. At least part of Sony's recent problems is that they were running an unpatched version of their software stack. (See [ http://www.net-security.org/secworld.php?id=10984][2]) And finally, log everything. That obviously won't stop an attack, but it can help you determine that one happened, what the extent of the damage was, and how to stop the next one if you ever do get attacked. [1]: http://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/ [2]: http://www.net-security.org/secworld.php?id=10984
1 comment
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks for the link on this! I'll make a point to take a look at it.
0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.