Posts Tagged ‘Database’

With every new version of SQL server, Microsoft is adding new and exciting features for database encryption. In SQL Server 2008, Microsoft has introduced a new encryption technique called Transparent Data Encryption (TDE). With TDE, Encryption is performed on the database with real time I/O operations. The performance of encryption and decryption is better when compared to SQL Server 2005.

Transparent Data Encryption (TDE) uses database encryption symmetric key (DEK) for the purpose of encryption and decryption. DEK is stored in master databased secured by certificate or asymmetric key. TDE provides the ability to encrypt the data at root levels meaning data and log files. This way users can encrypt the data without modifying the design of existing applications. TDE does not affect the size of the database. Size of the database remains same with or without TDE encryption. for TDE enabled database, backup files are also encrypted using DEK. So, during the restore process, certificate protecting database must be available. Care must be taken to backup server certificates on regular basis.

Following are the important steps in configuring the Transparent Data Encryption (TDE).

  1. Create a Master Key
  2. Generate a certificateprotected by master key.
  3. Create a database encryption key (DEK) protected by certificate.
  4. Enable the TDE encryption for selected database.

Here is an example for enabling the encryption on database Northwind using a certificate named MySQLCertificate.

USE Master;
GO
 
--Create Master Key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password1';
GO
 
--Create Certificate
CREATE CERTIFICATE MySQLServerCertificate WITH SUBJECT = 'My SQL Server Certificate'
GO
 
USE Northwind
GO
 
--Create Database Encryption Key (DEK)
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY SERVER CERTIFICATE MySQLServerCertificate
GO
 
-- Enable the TDE Encryption for the database
ALTER DATABASE Northwind
SET ENCRYPTION ON
GO
Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • email
  • Reddit
  • HackerNews
  • Slashdot
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz
  • Tumblr
  • Share/Bookmark

Tags: , , ,

10
May

Secure Database against SQL Injection attacks

   Posted by: Rasik Jain    in Database

Following are some of the recommendations to protect the application against SQL injection attacks. These recommendations are very generic in nature and independent of database platform so they can be applied to any database such as SQL Server 2000/2005, Oracle, MySQL or DB2

Sanitization Input:Protecting SQL queries by implementing sanitization techniques for all input received from any ASP.NET request object. Check all the input sources such as Request.Cookies, Form Variables, Query String parameters, Request.ServerVariables etc. Sanitization routines will vary based on your DBMS.

Avoid disclosing database error information. In the event of database errors, make sure you do not disclose detailed error messages to the user. Never display debug or detailed information to the user containing SQL queries.

Check SQL meta-characters (single-quote(‘), semi-colon(;) or double-dash(–), or multi-line comments (/* */) etc) and command keywords (Select, Union, Delete, Drop, etc) from the input. Always check and filter these keywords in the input fields. Always perform these checks on server-side. Do not rely on client-side validation alone.

Escape/Quotesafe the input, such as by replacing all single quotes with two single quotes.

Constrain and sanitize input data. Check for known good data by validating for type, length, format, and range. Validation should be done on both server side and client side.

Remove unused extended stored procedures, like xp_cmdshell and xp_grantlogin, and other user-defined functions.

Limit the permissions granted to the database user account used by the Web application. Most of the cases, only “EXEC” permission is required for stored procs. Remove DBO privileges to the application account.

Avoid Dynamic Queries: Always use stored procedures to communicate with database. Avoid using dynamic queries or SQL statements embedded in the program code.

Use type-safe SQL parameters for data access. You can use these parameters with stored procedures or dynamically constructed SQL command strings. Parameter collections such as SqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code. An additional benefit of using a parameters collection is that you can enforce type and length checks. Values outside of the range trigger an exception.

Following is a sample VB.NET routine which will check for invalid characters in the data input.

 
Public Function TestForSQLInjection(ByVal psSQL As String) As String
 
	Dim rexSql As Regex = New Regex("/exec(\s|\+)+(s|x)p\w+/ix")
 
	Dim rexSql2 As Regex = New Regex("(\-\-)")
 
	If Not rexSql.Match(psSQL).Success And Not rexSql2.Match(psSQL).Success Then
 
		Return psSQL
 
	End If
 
Throw New Exception("SQL Injection attack possible with:" & psSQL)
 
End Function
Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • email
  • Reddit
  • HackerNews
  • Slashdot
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz
  • Tumblr
  • Share/Bookmark

Tags: ,