While the default apps on a SBS 2003 (and upcoming SBS 2008) go through a SDL process so that I’m not concerned about SQL injection possibilities on my SBS box (nor do I have SharePoint exposed anyway) when you have third party and home grown apps, you really don’t know of what the coder did.
Review these and forward them on to your local dev guy to make sure they are aware of the problem.
Microsoft has recently published a series of best practices to help developers build SQL code that is not susceptible to SQL injection attacks.
SQL injection attacks occur in applications that are poorly programmed. They are not a result of failures in the data base or supporting products. When applications do not properly filter and control input data, there is a chance inputs can be manipulated, so that dangerous redirecting scripts may end up on the website
Once a web site is infected, the newly embedded script will then direct users to another dangerous website, that can automatically download malware on the user’s PC. While these attacks have been around for years, malware authors are now using newly automated approaches to find susceptible servers automatically and infect thousands of websites in a single day.
IT developers have an inherent responsibility to protect the privacy and integrity of customer information. These articles are “must reads” for any IT developer, for greater assurances in building secure applications.
Microsoft Best Practices for preventing SQL Injection Attacks
Microsoft Security Vulnerability Research & Defense Blog – SQL Injection Attack
Nazim’s IIS Security Blog – Filtering SQL injection from Classic ASP
Neil Carpenter’s Blog – SQL Injection Mitigation: Using Parameterized Queries
Michael Howard’s Blog -Giving SQL Injection the Respect it Deserves
MSDN Article – Preventing SQL Injections in ASP
Anti-Malware Engineering Team – When SQL Injections Go Awry, Incident Case Study
A more general overview of SQL Injection attacks can also be here:
What are SQL Injection Attacks?