September 6, 2010 at 2:40 pm
Perry Whittle (9/6/2010)
incidentally Wayne, although i do sort of agree with Jeff and Lynn,"all pirates should find their own treasure"
i do think that you presented well to the OP.
(i hope i dont get the pork chop treatment here, sorry Jeff 😉 )
At the end of the day he could find that info anywhere without too much trouble. I would have preferred you too touch on permissions a little more though as i think these are the root of all evil!
I have to do better at remembering about permissions on this topic. Most systems that I've been involved with the web users can only execute stored procedures - greatly minimizes sql injection possibilities.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
September 6, 2010 at 3:41 pm
WayneS (9/6/2010)
Most systems that I've been involved with the web users can only execute stored procedures
count yourself lucky here!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 6, 2010 at 8:34 pm
Perry Whittle (9/6/2010)
WayneS (9/6/2010)
Most systems that I've been involved with the web users can only execute stored procedurescount yourself lucky here!
When you tend to only draw hard, fast lines in the sand on the really big issues, it's amazing how much you can get done in the name of protecting the data.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
September 7, 2010 at 1:42 am
Perry Whittle (9/6/2010)
sku370870 (9/6/2010)
How would a hacker get to see a web.config file?possibly many avenues to achieve this on an unsecured server
sku370870 (9/6/2010)
How can you not show passwords in a web.config file for the account which is accessing a database?by encrypting your connection strings in the web.config file!
When you publish a .net site - doesn't the web.config file get compiled into the dll?
September 7, 2010 at 1:58 am
I rarely rate a subject, but this one deserves it in my opinion, in order to draw people's attention to it. I think everyone should know how SQL Injection works and thereby understand and prevent it. The phrase gets thrown around a lot, but I imagine a lot of people don't really understand what it means.
BrainDonor.
September 7, 2010 at 2:33 am
BrainDonor (9/7/2010)
I rarely rate a subject, but this one deserves it in my opinion, in order to draw people's attention to it. I think everyone should know how SQL Injection works and thereby understand and prevent it. The phrase gets thrown around a lot, but I imagine a lot of people don't really understand what it means.BrainDonor.
I'm sure lots of people would like to know exactly what needs to be done to prevent SQL injection.
I generally build web apps. For my part I:
Prevent anyone from using '<' in form fields
Only access the database via stored procedures
Use a specific account in SQL Server - i.e. not 'SA' in my connection string
If I have to use Dynamic SQL in a stored procedure, only ever set Read permissions on tables
Server wise - it's just the usual security - you have to have an account and know the username and password to get on.
What would be great to see is a comprehensive list of things to do to prevent SQL injection - if anyone had the time.
September 7, 2010 at 2:52 am
Perry Whittle (9/6/2010)
Guys,the remaining point is permissions. SQL injection is possible because of main 2 issues.
Bad code
misuse of permissions
The following
Myname' or 1=1;drop table dbo.customers;--
would not work if the account connecting to the database had only read access to the tables. OK, the website is allowing this back door in the first place but if permissions were properly granted the drop would fail. So many times i see systems where developers have 'ticked' every single box on the permissions list to get something working!!!!
Makes me think of Little Bobby Tables. Old but good http://xkcd.com/327/[/url]
September 7, 2010 at 12:33 pm
sku370870 (9/7/2010)
I'm sure lots of people would like to know exactly what needs to be done to prevent SQL injection.
I generally build web apps. For my part I:
Prevent anyone from using '<' in form fields
Only access the database via stored procedures
Use a specific account in SQL Server - i.e. not 'SA' in my connection string
If I have to use Dynamic SQL in a stored procedure, only ever set Read permissions on tables
Server wise - it's just the usual security - you have to have an account and know the username and password to get on.
What would be great to see is a comprehensive list of things to do to prevent SQL injection - if anyone had the time.
Thank you, Nils, for bringing up Little Bobby Tables.
Some quibbles with the above, though:
"Only access the DB using SPs" should be "Grant only permission to execute SPs to that user".
"Always use full parametrization, never use concatenated SQL" should be explicit.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply