”Select” Issues

Many web applications are written to build database commands (in the SQL language used by most databases) from certain keywords like “SELECT” and input that is provided by a user via a web form. Often the provided input is simply copied into the database command as it is being built, without checking to see that the web form data would actually be valid, and then submitted to the database to be run. As with stored procedures, it is possible to creatively construct web form data so that it actually embeds additional attacker-specified database commands into the original command. The database sees the additional database commands and not knowing they’re not legitimate requests, executes them – and gives the hacker a map of the database, deletes your customer records, changes item prices, etc. This particular attack is known as SQL injection. Even in late 2002, SQL injection is still possible on many commercial sites. While it’s beyond the scope of this book (we’re not writing a programming book, after all) to describe exactly how these flaws are taken advantage of, or how to write code that guards against them, other sources for this information exist, such as Writing Secure Code³⁸³ by Howard and LeBlanc.

Databases and Ports

Research the TCP/IP port(s) used by your database server software, and set up appropriate ACLs to restrict access to those ports on the database server, to only those systems that require access.

For example, if SQL Server is your database, only allow inbound access to the database server machine TCP ports 1433 and 1434 from your web server and a minimal number of trusted internal hosts.