To build secure data access code, know what the threats are, how common vulnerabilities arise in data access code, and how to use appropriate countermeasures to mitigate risk.
The top threats to data access code are:
SQL injection
Disclosure of configuration data
Disclosure of sensitive application data
Disclosure of database schema and connection details
Unauthorized access
Network eavesdropping
Figure 14.1 illustrates these top threats.
SQL injection attacks exploit vulnerable data access code and allow an attacker to execute arbitrary commands in the database. The threat is greater if the application uses an unconstrained account in the database because this gives the attacker greater freedom to execute queries and commands.
Common vulnerabilities that make your data access code susceptible to SQL injection attacks include:
Weak input validation
Dynamic construction of SQL statements without the use of type-safe parameters
Use of over-privileged database logins
To counter SQL injection attacks, be sure to:
Constrain and sanitize input data.
Use type safe SQL parameters for data access. These parameters can be used with stored procedures or dynamically constructed SQL command strings. Parameters perform type and length checks and also ensure that injected code is treated as literal data, not executable statements in the database.
Use an account that has restricted permissions in the database. Ideally, you should only grant execute permissions to selected stored procedures in the database and provide no direct table access.
The most sensitive configuration data used by data access code is the database connection string. If a compromised connection string includes a user name and password, the consequences can be greater still.
The following vulnerabilities increase the security risk associated with compromised configuration data:
Use of SQL authentication, which requires credentials to be specified in the connection string
Embedded connection strings in code
Clear text connection strings in configuration files
Failure to encrypt a connection string
To prevent disclosure of configuration data:
Use Windows authentication so that connection strings do not contain credentials.
Encrypt the connection strings and restrict access to the encrypted data.
Many applications store sensitive data, such as customer credit card numbers . It is essential to protect the privacy and integrity of this type of data.
Coding practices that can lead to the disclosure of sensitive application data include:
Storing data with no encryption
Weak authorization
Weak encryption
To prevent disclosure of sensitive application data:
Use strong encryption to secure the data.
Authorize each caller prior to performing data access so that users are only able to see their own data.
If your code returns exception details to the client, a malicious user can use the information to attack the server. Exceptions in data access code can reveal sensitive information, such as database schema details, the nature of the data store, and SQL code fragments .
The following vulnerabilities can result in information disclosure:
Inadequate exception handling
Weak ASP.NET configuration that allows unhandled exception details to be returned to the client
To prevent such disclosure:
Catch, log, and handle data access exceptions in your data access code.
Return generic error messages to the caller. This requires appropriate configuration of the <customErrors> element in the Web.config or Machine.config configuration file.
With inadequate authorization, users may be able to see another user's data and may be able to access other restricted data.
Practices that can allow unauthorized access include:
Lack of authorization in data access code providing unrestricted access
Over-privileged database accounts
To prevent unauthorized access:
Use principal permission demands to authorize the calling user.
Use code access security permission demands to authorize the calling code.
Use limited permissions to restrict the application's login to the database and to prevent direct table access.
The deployment architecture of most applications includes a physical separation of the data access code from the database server. As a result, sensitive data such as application-specific data or database login credentials must be protected from network eavesdroppers.
The following practices increase vulnerability to network eavesdropping:
Clear text credentials passed over the network during SQL authentication
Unencrypted sensitive application data sent to and from the database server
To limit vulnerability to network eavesdropping:
Use Windows authentication to avoid sending credentials over the network.
Install a server certificate on the database server. This results in the automatic encryption of SQL credentials over the network.
Use an SSL connection between the Web server and database server to protect sensitive application data. This requires a database server certificate.
Use an IPSec encrypted channel between Web and database server.