ASP.NET 2.0 Security Inspection Questions - Data Access

From Guidance Share

(Difference between revisions)
Jump to: navigation, search
Revision as of 19:36, 25 November 2006 (edit)
Admin (Talk | contribs)

← Previous diff
Revision as of 19:36, 25 November 2006 (edit)
Admin (Talk | contribs)

Next diff →
Line 31: Line 31:
== Does the application use SQL authentication? == == 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
 + "Server=YourServer;Database=YourDatabase;Trusted_Connection='Yes';"
 + // 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
 + "Server=YourServer;Database=YourDatabase;uid=username;pwd=pwd;"
 + // Uses the sa account
 + "Server=YourServer;Database=YourDatabase;uid=sa;pwd=pwd;"
 + // Uses blank passwords
 + "Server=YourServer;Database=YourDatabase;uid=username;pwd=;"
== How does the application store database connection strings? == == How does the application store database connection strings? ==

Revision as of 19:36, 25 November 2006

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


Data Access Vulnerabilities and Implications

Vulnerability

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
"Server=YourServer;Database=YourDatabase;Trusted_Connection='Yes';"
// 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
"Server=YourServer;Database=YourDatabase;uid=username;pwd=pwd;"
// Uses the sa account
"Server=YourServer;Database=YourDatabase;uid=sa;pwd=pwd;"
// Uses blank passwords
"Server=YourServer;Database=YourDatabase;uid=username;pwd=;"


How does the application store database connection strings?

Personal tools