The primary defenses that are used to fight include,
• Prepared Statements (Parameterized Queries) - Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied.
• Stored Procedures - a stored procedure is defined and stored in the database itself, and then called from the application rather than something that a user is allowed to enter.
• Escaping all User Supplied Input - Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.
Additional Defenses include
• Least Privilege – or minimizing the privileges assigned to every database account, so that users have enough permission to do their job, but no more.
• White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack
Encrypting data
For items such as passwords, the user's password can be stored as a "salted hash". What happens is that when a user creates a password, a randomly generated "salt" value is created by the application and appended to the password, and the password-and-salt are then passed through a one way encryption routine, such as found in the .NET Framework's helper class FormsAuthentication (HashPasswordForStoringInConfigFile method). The result is a salted hash which is stored in the database along with the clear text salt string.
Install the database using an account with the least privileges necessary.
Ensure that data is valid.
Do a code review to check for the possibility of second-order attacks.
Use parameterised queries.
Use stored procedures.
Re-validate data in stored procedures.
Ensure that error messages give nothing away about the internal architecture of the application or the database.
• Prepared Statements (Parameterized Queries) - Parameterized queries force developers to define all the SQL code, then pass in each parameter to the query, which allows the database to distinguish between code and data, regardless of what input is supplied.
• Stored Procedures - a stored procedure is defined and stored in the database itself, and then called from the application rather than something that a user is allowed to enter.
• Escaping all User Supplied Input - Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.
Additional Defenses include
• Least Privilege – or minimizing the privileges assigned to every database account, so that users have enough permission to do their job, but no more.
• White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack
Encrypting data
For items such as passwords, the user's password can be stored as a "salted hash". What happens is that when a user creates a password, a randomly generated "salt" value is created by the application and appended to the password, and the password-and-salt are then passed through a one way encryption routine, such as found in the .NET Framework's helper class FormsAuthentication (HashPasswordForStoringInConfigFile method). The result is a salted hash which is stored in the database along with the clear text salt string.
Install the database using an account with the least privileges necessary.
Ensure that data is valid.
Do a code review to check for the possibility of second-order attacks.
Use parameterised queries.
Use stored procedures.
Re-validate data in stored procedures.
Ensure that error messages give nothing away about the internal architecture of the application or the database.
No comments:
Post a Comment