These mitigation strategies all tie together to help protect against injection attacks. The programming environments that most web programmers are using today also implement many of the ideas presented in this section.
1. Use parameterized queries: This is the oldest advice to battle SQL injection where placeholders (think: variables) are used to store user input before it is acted on by the SQL interpreter. This prevents the hanging quote prob- lem because the SQL syntax isn’t being dynamically generated in the same fashion. An attacker’s attempt to close off the SQL statement would be use- less without having the ability to dictate what portions of the prewritten SQL actually executes. This idea of using a placeholder also allows further processing to be done to the user’s input before being passed onto the SQL interpreter. The further processing is usually the two mitigation strategies discussed below. Please realize that parameterizing a query is NOT the same as using parameters in SQL-stored procedures. Stored procedures that make use of variables can most definitely have SQL injection vulnerabilities in them just as a query can!
2. Escape malicious syntax: This is done in server-side code before user input reaches the SQL interpreter, so all malicious characters have been identi- fied and suppressed to be benign. OWASP’s ESAPI includes many power- ful and popular encoding and decoding functions to perform this escaping in its Encoder interface which contains several methods for decoding input and encoding output so it’s safe to pass onto an interpreter. ESAPI also makes use of canocalization, which reduces user input to its simplest for- mat before being acted on; this ensures no malicious characters slip past the safety checks.
3. Make use of stored procedures: These are similar to prepared statements and parameterized queries but differ by existing on the database server rather than in code. Stored procedures allow for central code management and help reduce the attack surface. All stored procedure code is declared and processed on the database and the application only passes parameters to the stored procedure to process the SQL statements.
4. Remove unnecessary functionality on your database server: For example, Microsoft’s SQL Server includes the xp_cmdshell stored procedure that allows system commands to be invoked from the database. Unless you have a definitive reason enable this feature, it should most certainly be disabled to help protect your system and data.
5. Encrypt sensitive data: Too many times we hear of data breaches, which are bad enough in itself, but the problem is exacerbated when the data
harvested are clear text. Sensitive data such as passwords, credit card information, social security numbers, and related data items need to be encrypted during storage as well as when it’s in transit.
6. Use whitelist validation for input including canonicalization: These are two main ideas related to sanitizing user input before it reaches the data- base interpreter. Whitelisting is simply the use of only known-good val- ues. A perfect example of whitelisting is selecting what state you live in. If you provide the user a textbox, he can type whatever he wants in that textbox—including malicious input. A whitelist would be implemented by using a dropdown box that only includes the two-letter abbreviation for each of the 50 states. There is no other way to select a value for the state. Of course, a responsible web application programmer will also make sure that the value received for this parameter is one of the 50 expected values to ensure it hasn’t been edited in a proxy before reaching the web applica- tion on the web server. Canonicalization is the processing of taking user input and “boiling it down” (normalizing it) to its simplest form. This is especially useful in injection and path traversal attacks to fully understand what the attacker is attempting. The Validator interface in ESAPI defines the methods for canonicalizing and validating untrusted input, but is only appropriate to use when the application implements a whitelist approach to processing input.
7. Use regular expressions: A regular expression is an object that performs pat- tern matching on user input and can be assigned to individual controls (i.e., textbox) on a web form. A majority of programming languages have prebuilt instances of regular expressions such as RegularExpressionValidator
in .NET. Regular expressions can help save time and reduce human errors when trying to create sanitization routines. A really great resource for help on implementing regular expressions is available at: http://regexlib.com/ CheatSheet.aspx.
8. Implement a lease privilege model on your database: This simply means the credential level of the accounts used to access the database need to be tightly restricted and monitored. It is not wise to never allow an adminis- trator level account access the database. You can always use different accounts for different types of database interactions. For example, you can use different accounts for reading data versus creating new records in the database.
9. Use your development environment’s API for system-level calls: Although there is a strong argument to never allow user input to be processed by an operating system directly, if you must do it the best mechanism is to use preconfigured application programming interfaces (API). An API is the safest way to interact with the operating system command interpreter as they do not allow metacharacters and other malicious input from users. The APIs will only start a process based on name and command-line parameters instead of allowing an entire string and supporting chained commands. This limits the possibilities of attack breaking out of the expected input values.