{"id":1877,"date":"2008-05-15T14:45:00","date_gmt":"2008-05-15T21:45:00","guid":{"rendered":"http:\/\/marcbook.local\/wds\/playground\/cybertrust\/2008\/05\/15\/giving-sql-injection-the-respect-it-deserves\/"},"modified":"2023-05-16T09:54:16","modified_gmt":"2023-05-16T16:54:16","slug":"giving-sql-injection-the-respect-it-deserves","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2008\/05\/15\/giving-sql-injection-the-respect-it-deserves\/","title":{"rendered":"Giving SQL Injection the Respect it Deserves"},"content":{"rendered":"
You may have read<\/a> recently about a large number of Web servers<\/a> that were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic \u00a0so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user’s perspective the real attack was compromised Web pages that serve up malware to attack user’s through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.<\/p>\n The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.<\/p>\n I think the first lesson from this attack is this:<\/p>\n If you have a Web server (doesn’t matter what type), and it’s hooked up to a database (doesn’t matter what type) you need to go in and review your code that performs the database work.<\/p>\n So now that you’ve determined the database access code, now what? The SDL is very specific about what do here, there are three requirements – they are requirements not recommendations, which means you must do the following coding requirements and defenses<\/p>\n From the SDL documentation:<\/p>\n “Applications accessing a database must do so only using parameterized queries.<\/p>\n Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.<\/p>\n Combining the use of parameterized queries and stored procedures helps to mitigate the risk of successful exploitation of user input which is not correctly verified.”<\/p>\n\n
Use SQL Parameterized Queries<\/h2>\n