1. Remove Potential Back Doors

While SQL injection comes in through the front door, you must still practice safe computing and treat database servers as yet another operating system that requires hardening—the same way you treat your other servers.

Heed these precautions:

• Delete all sample files and applications on your production servers
• Shun ‘local-host only’ security, especially on proxies
• Check what gets changed when you upgrade
• Eliminate stored procedures that aren’t used to support applications
• Isolate database servers from the Internet
• Prevent direct connection to the database server on vulnerable ports (such as TCP port 1433 and UDP port 1434)
• Ensure that the database server cannot connect to the Internet on vulnerable ports, such as TCP ports 21, 80, 139, 443, 445 or 1433 and UDP port 53.

2. Validate Input Scripts and Strings Sent to the Database

Developers can’t test everything. But you can look at your Web scripts and programs and test them for exploits.

• Do you have range limits for all queries?
• Do you have appropriate access rights for all users, including default rights for Web users?
• Do you apply input-validation checks for all places that accept input from the Web?

One common mistake is neglecting to check stored procedures, erroneously thinking they are outside the bounds of SQL injection. Wherever possible, restrict access of Web-based applications to stored procedures and filter the data passed to them to eliminate potential exploits.