ASP.NET 2.0 Security Inspection Questions - Data Access

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo

Data Access Vulnerabilities and Implications



Failing to protect database connection strings

The database can be compromised.

Using over-privileged accounts to access SQL Server

An attacker can use the extended privileges to execute commands at the database.

The following questions can help you to identify vulnerable areas:

  • Does the application use SQL authentication?
  • How does the application store database connection strings?

Does the application use SQL authentication?

The application should avoid using SQL authentication and should use Windows authentication where possible.

The code should use connection strings with Trusted_Connection="Yes" or Integrated Security="SSPI", as shown in the following example.

// Uses thread's security context to connect using Windows authentication
// Same as above
"Server=YourServer;Database=YourDatabase;Integrated Security=SSPI;"

The application should not use connection strings that contain user names and passwords, and in particular, it should avoid using highly privileged accounts, such as the sa account, and blank passwords. The code should avoid using the following connection strings.

// Contains user names and passwords
// Uses the sa account
// Uses blank passwords

How does the application store database connection strings?

Verify that connection strings are stored in encrypted format. This is particularly important if the connection strings contain credentials. If the application uses Windows authentication, encrypting the strings protects the database server name. However, you should weigh this benefit against the increased deployment complexity.

If the application uses the <connectionStrings> section of the Web.config file to store connection strings, make sure that this section is encrypted with the Aspnet_regiis tool.

Personal tools