Presentation is loading. Please wait.

Presentation is loading. Please wait.

Security in SQL Jon Holmes CIS 407 Fall 2007. Outline Surface Area Connection Strings Authenticating Permissions Data Storage Injections.

Similar presentations


Presentation on theme: "Security in SQL Jon Holmes CIS 407 Fall 2007. Outline Surface Area Connection Strings Authenticating Permissions Data Storage Injections."— Presentation transcript:

1 Security in SQL Jon Holmes CIS 407 Fall 2007

2 Outline Surface Area Connection Strings Authenticating Permissions Data Storage Injections

3 Reduce Surface Area Database Engine Analysis Service Engine Reporting Services Integration Services Notification Services Documentation and Samples

4 Reduce Surface Area SQL Server Active Directory Helper SQL Server Agent SQL Server FullText Search SQL Server Browser SQL Server VSS Writer

5 Blocking ports MSSQL Ports 1433 / 1434 MySQL Ports 3306 Oracle 1521 / 1526

6 Connection Strings Contains –Database Name –Server Address/Name May Reveal Network Schema –UserName –Password

7 Connection Strings (Where?) Options? –In Code –Place in Text file –In Application Configuration file Web.Config Application Settings

8 Authentication Windows accounts –Machine Specific –High Security SQL accounts –Portable –Less Secure

9 Permissions Microsoft says use Groups not User Specific rights. What happens when user leaves? Who is responsible?

10 Permissions One Database = One Owner Lowest possible Permissions Segregation of Duties –Read –Write

11 Storing Data Minimum Size Data Type –Sproc Data Types match

12 SQL Injections Source: http://xkcd.com/327/

13 PrincipleImplementation Never trust user input Validate all textbox entries using validation controls, regular expressions, code, and so on Never use dynamic SQLUse parameterized SQL or stored procedures Never connect to a database using an admin-level account Use a limited access account to connect to the database Don't store secrets in plain text Encrypt or hash passwords and other sensitive data; you should also encrypt connection strings Exceptions should divulge minimal information Don't reveal too much information in error messages; use customErrors to display minimal information in the event of unhandled error; set debug to false Basic Rules

14 Injections Inputs Example Critical Information Outputs Sanitization

15 Handling Inputs Never trust the user. –DropDown Lists –ListBoxes –Tables –Query Strings –Hidden Fields

16 Login Forms Login UserName Password LoginCancel X

17 Dynamic SQL //This code is susceptible to SQL injection attacks. Dim strQry As String strQry = "SELECT Count(*) FROM Users WHERE UserName='" & txtUser.Text & "' AND Password='" & txtPassword.Text & "'"

18 What will happen? Login ’ or 1=1 -- ********* UserName Password LoginCancel X

19 Critical Information Passwords –Strong –Hashing –Salts Other Information –Hashing –Salts

20 Handling Outputs Know what you are showing off –What data is shown? –Always validate authority –Do not display schema –Custom Tables –Careful object reuse –Errors –Exceptions

21 Validation - Can use ASP.Net validation tools –Pros Fast Easy –Cons Javascript False security –Know what is running where –Always best to handle in code Sanitization

22 References Stop SQL Injection Attacks Before They Stop You SQL Server 2005 Security Best Practices


Download ppt "Security in SQL Jon Holmes CIS 407 Fall 2007. Outline Surface Area Connection Strings Authenticating Permissions Data Storage Injections."

Similar presentations


Ads by Google