Direct Connection to the Internet

Exposing any operating system or application directly to the Internet without the use of a firewall is a bad thingno matter whether you are using Linux, UNIX, Windows, or any other operating system. It's rather like the carnival game where someone sits on a platform above a pool of water waiting for someone else to throw a ball and hit the bull's eye. When it happens, the person sitting on the platform is plunged into the water. Why expose your system, allowing anyone to take shots until they finally get you soaked? Microsoft has done a lot of work around protecting its operating systems and applications out of the box. When an exploit happens, they quickly address these problems and provide fixes.

This is only half of the battle, though. With all the switches and states of security for various products, it is not that difficult for an administrator or user to accidentally misconfigure something and expose the systems to exploits. To mitigate these issues, it is very important that users isolate their systems from the Internet via firewalls and use other isolation techniques.

Weak SA Passwords

One of the easiest ways to give someone the keys to SQL Server is by providing a weak password for the system administrator account. In previous versions of SQL Server, it was possible to give a blank password for the SA account without much complaint from SQL Server itself. SQL Server 2005 has a lot more functionality around password policies and enforcement. Previously in this chapter, we discussed this topic in regard to SQL Server authentication accounts obeying the group policies of the Windows domain. Configuring a strong password length and account lockout in your domain will ensure that all users of SQL Server are supplying passwords that are more difficult to crack.

SQL Server Browser Service

SQL Server uses UDP port 1434 to return SQL Server instance names and port numbers to the requesting client. A few years back, this enumeration was the key to the "SQL Slammer" DoS virus. By consistently hitting the server with requests for enumeration, the virus left the server too busy to process other requests. In SQL Server 2005, this enumeration functionality is in a separate service called the SQL Server Browser service. The functionality no longer runs in SQL Server's process space, and it can be turned on and off without affecting SQL Server. If you do not want to use the SQL Server Browser service, you can still connect to other instances on your server, but the connection string must contain additional information (such as a specific port number in the case of TCP connections). If you want to use the Browser service in your organization, you can mitigate additional attacks by blocking UDP port 1434 on your firewall.

SQL Injection

SQL injection is the process by which a malicious user enters SQL statements instead of valid input. For example, suppose a Web site is asking for a user name. Instead of actually typing in a user name, a malicious user might type 'blah'; DROP TABLE sales;. The Web server will happily take the user input and pass it to its middle layer, where it is executed in code as follows:

SqlCommand cmd = new SqlCommand("SELECT * FROM sales WHERE name='" + s_Customername + "'
",myConnection)

To SQL Server, it looks like the following:

SELECT * FROM sales WHERE name='blah'; DROP TABLE sales;

When it is executed, the sales table will be erased. You can see how easy it can be for malicious users to cause problems and return potentially sensitive information via simple inputs to Web pages or applications that directly use user input. To mitigate this particular issue, you can add the user input as a parameter to the SqlCommand, as shown below:

Using (SqlCommand cmd = new SqlCommand("SELECT * FROM sales WHERE name= @s_CustomerName"
, myConnection));
{
cmd.Parameters.Add("@s_CustomerName",s_CustomerName);
...

To SQL Server, whatever the user types will be considered just the value of the name part of the where clause.

Intelligent Observation

With the advent of powerful search engines such as Google and MSN Search, finding things on the Web is relatively easy. Web crawlers from these search engines go off and fetch key words and place them into their own internal database. These key words are used within their own search algorithms so that when you type something to search on, the search engine can easily return a list of possible choices. These crawlers not only search for and store such things as Web sites for pizza places, but they also obtain various kinds of error information returned from Web servers. This information is very valuable to a hacker. For example, if a hacker types invalid password access denied into the search string in MSN, he'll get a list of various topics that are, in general, not that interesting. However, one item will show this string: Warning: mysql_pconnect(): Access denied for user 'root'@'localhost' (using password: YES) in /home/vhosts/<<removed for legal reasons>>/docs/citeheader.inc.php on line 2. A hacker knows that this site is using MySQL and PHP and now knows some of the directory structure of the Web site /home/vhosts/<<removed for legal reasons>>/docs. Now the hacker can try to query that individual directory path using his Internet browser to see if he can uncover any additional goodiesa script file, perhaps. If he finds a script file in this directory and the developer has hardcoded login credentials to the database, he is one connection away from compromising the database.

The moral of the story is that search engines are very good hacker tools. Never hardcode passwords in script files, and always provide Web page redirects for errors within your Web application. In addition, always pay extra attention to any Web application that receives input. Make sure these kinds of data are protected against SQL injection attacks.