Hacking the Code ASP.NET Web Application Security [Electronic resources] نسخه متنی

Securing Databases

Your data access code’s security depends greatly on your entire database infrastructure. Security vulnerabilities may occur due to bugs in the database or its drivers, unsafe database location, or poor database configuration. Before writing any data access code in your Web application, you should first consider the security of the database itself.

Securing the Database Location

An important first step in securing your database is to properly control access to the database itself. You should be careful to configure your firewall to restrict access so that only the Web application itself can directly access database ports. Where you physically place the database server on your network can also have an impact on database security.

For an example, let’s say that we have a .NET Web application named myApplication that uses a database called myApplication Database. Figure 6.1 shows a common firewall layout for this scenario.

Figure 6.1: Firewall Layout #1

Notice that a firewall separates the myApplication Web server from the Internet, and another firewall separates the myApplication Web server from the myApplication database. The area in which the Web server resides is called a demilitarized zone (DMZ). Behind the second firewall reside the database and often the internal company network.

This scenario is common because many administrators believe it provides a second layer of protection for the database in case an attacker compromises the Web server or another server in the DMZ. However, this may not be the most secure configuration. If an attacker obtains access to the database itself, perhaps through SQL injection or a buffer overflow, the attacker gains a direct line to the internal network, completely sidestepping the protections of the firewall. Consider an alternative network layout, presented in Figure 6.2.

Figure 6.2: Firewall Layout #2

In this scenario, we have placed the database in the DMZ, along with the Web server. This scenario treats the database server as a high-risk server and isolates it from other databases and the rest of the internal network. Placing the database server in the DMZ contains and limits the scope of a database attack.

Your specific firewall configuration will depend on the needs of the applications you are running as well as the type of data you store in the database. Wherever you place your database, you must consider the risks involved.

Security Policy

Review your network topology and security needs to design a firewall layout best suited for your environment.

Assume worst-case scenarios when designing your firewall layout.

A database driver is the software interface that communicates with a database. Because drivers are essential for database communication, they are a popular point of attack. The single most important thing you can do to protect your database drivers is to keep them up to date. As with most popular enterprise software, drivers are frequently updated because vulnerabilities in them can have such dire effects on a system. Many recent viruses, worms, and Internet exploits could have been prevented if the compromised systems had updated drivers and software.

In addition to keeping your drivers up to date, other good security practices you can follow include limiting the areas of your system an attacker can compromise and understanding and preventing buffer overflow attacks. We will also examine logging and tracing methods to determine when and how attackers may have invaded, or attempted to invade, your system.

Limiting the Attack Surface

Software companies build databases to accommodate a huge variety of Web site needs. Chances are, your application doesn’t use every feature available with a default database installation. Every database feature is a potential attack vector; therefore, unused features do nothing more than increase the attack surface for a hacker. Decrease this attack surface by removing any unused database drivers.

By default, a Windows 2000 installation comes with various Open Database Connectivity (ODBC) drivers. You can safely remove the ODBC drivers if you are not using them. You need to manually remove the ODBC drivers from the registry. Using regedit, remove any unused drivers from the following keys:

HKLM\SOFTWARE\ODBC\ODBCINST.INI

HKLM\SOFTWARE\ODBC\ODBC.INI

Figure 6.3 shows how to use regedit to remove these keys.

Figure 6.3: Removing an ODBC Driver from the Registry

If you are not using the Jet drivers, you can safely remove them as well. Delete the unused Jet engines and Index Sequential Access Method (ISAM) formats that you find below the HKEY_LOCAL_MACHINE\SOFTWARE\_Microsoft\Jet registry key.

Finally, some Windows applications install User, System, or File data source names (DSNs). Generally, the applications do not even notify you that they installed these DSNs. If you don’t use these DSNs, you should delete them. Use the User Data Sources (ODBC) Administrative Tool and click Remove for each unused driver, as shown in Figure 6.4. Alternatively, you can remove the DSNs by deleting the entries under the HKEY_LOCAL_MACHINE\SOFTWARE\_ODBC\ODBCI.INI registry key.

Figure 6.4: Removing DSNs

Securing Specific Drivers

After removing unused database drivers, you should further reduce the attack surface by securing the remaining drivers. Most database drivers provide settings to limit functionality or restrict driver usage. Here we discuss some example settings for various common drivers.

SQL Server

Keeping a record of who is trying to log in to your database is a valuable practice from many standpoints. If you see multiple attempts and failures with different usernames and/or passwords, you can surmise that an attacker is trying to use brute force to access your database. Likewise, if you notice successful logins at strange times, you may need to contact the user who logged in to make sure there was a valid reason for his or her use of the database.

By default, SQL Server does not audit logins and login attempts. You can record login attempts by setting a value in the registry key located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\AuditLevel. The possible values are:

0 No logins are recorded (this is the default).

1 Only successful logins are recorded.

2 Only failed logins are recorded.

3 Both successful and failed logins are recorded.

Alternatively, you can set the recording level using SQL Server’s Enterprise Management tool. Right-click the database group and select Properties. A new window will pop up. Select the Security tab from the top. You should see a window similar to Figure 6.5.

Figure 6.5: Setting the Maximum Logging Level

The Audit level area lets you set the logging level. Whether you use the registry setting or the GUI, set the audit level to record all login attempts. SQL Server’s default location to write the logs in C:\Program Files\Microsoft SQL Server\MSSQL\LOG.

IIS with ODBC

You can configure IIS to automatically log details to an ODBC source. You can log data such as the client’s IP address, the request the client performed, parameters passed, page requested, and many other properties of the connected user’s communication. With this data stored in a database, you can search for and respond to attacks and abnormal activity.

To set up IIS for ODBC logging, right-click your Web site, shown in the IIS Administration window. Select Properties, and you will see a window similar to Figure 6.6.

Figure 6.6: Setting IIS for ODBC Logging

From this window, you can select ODBC Logging from the bottom area labeled “Active log format.” After selecting ODBC Logging, you need to click the Properties button to the right to configure the ODBC DSN, the table to log to, and your user credentials to connect to the data source. You can find a list of the table structure appropriate for logging, as well as a script to create the table for you, in Microsoft’s Knowledge Base Article 245243, at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q245243.

Jet and ISAM

If you are using Jet or ISAM, you should use certain settings to improve your security. Jet drivers can and should run in Sandbox mode. You may have heard the term sandbox applied to Java applets. The idea with Jet drivers is the same. A sandbox is a protected portion of memory in which an application or drivers can run without the risk of causing damage to other applications running. The Jet Sandbox mode prevents users from embedding sensitive commands such as Shell in SQL queries.

You should change the registry entries at HKEY_LOCAL_MACHINE\_Software\Microsoft\Jet\3.5\engines\SandboxMode and HKEY_LOCAL__MACHINE\Software\Microsoft\Jet\4.0\engines\SandboxMode to run at the value of 3, which is the most secure Sandbox mode. The possible modes are:

0 Sandbox mode is disabled.

1 Sandbox mode is used only with Access applications.

2 Sandbox mode is used only with non-Access applications.

3 Sandbox mode is used on all applications.

Another setting you can tighten to increase security deals with the text ISAM. By default, the text ISAM allows you to read and write any text file. The registry key that controls this feature is located at HKEY_LOCAL_MACHINE\_Software\Microsoft\Jet\4.0\Engines\Text\DisabledExtensions and contains the default values of !txt,csv,tab,asc,tmp,htm,html. Increase the restrictions on which files can be read and written by replacing the txt entry with whatever text extensions you are using.

Security Policy

Remove or disable unused drivers from your database.

Periodically check for and remove any new unused drivers, especially after updates or patches.

Configure your database drivers to maximum security.

Configure your database drivers to log access activity.

Ensuring Least Privilege

Software engineers by nature are concerned with meeting their deadlines and producing their deliverables. When a programmer needs to connect to a database, he or she often writes code that uses the quickest and easiest way to connect and get the data needed. This generally involves using SQL Server’s sa, or System Administrator, account, which has superuser access and won’t give the developer any hassles about permissions or authorization. “I’ll go back and lock the system down once I get time,” the programmer often thinks.

Experience shows that with the approaching deadlines and last-minute bugs, the programmer forgets or does not have time to go back and tighten the database’s security. This is how software can end up in a production environment with elevated permissions. It’s also why an attacker can leverage one system running with unnecessarily high permissions to gain access to every other machine in the company.

The rule of least privilege states that any user, application, or process should have the bare minimum of access to do what it needs to complete its function. Do not give or allow access based on the idea that the user might need the access later or that it’s easier than figuring out what the minimum allowed access should be. Grant only the minimum required privileges to a user. If, in the future, the user needs more access, grant it then and not before.

SQL Server has various mechanisms to help you apply the rule of least privilege, including roles, groups, and access control lists (ACLs). We’ve already mentioned the first and most obvious (but often neglected) thing you should do: Never use the sa account for data access. The sa account has rights to do all kind of things your application likely doesn’t need to do, such as deleting an entire database. Instead, create a user account on the SQL Server that only has rights to do specifically what your code requires, whether reading a table, executing a stored procedure, or the like. You can set permission rights as specific as an individual column of a table or an individual stored procedure. As you find you need more access, add the explicit right you need. Locking down your access on a database this way obviously limits the actions a user can perform. This is fantastic from a security point of view. If an attacker is able breach your database, the attacker will find himself restricted by the same rights the application had. This could potentially minimize both the data the attacker can steal and the damage he can cause.

A firewall is another method of applying least privilege. By giving permission only to the ports your database uses to go through the firewall, you are further restricting unexpected or unauthorized communication. SQL Server, by default, communicates through port 1433 for TCP/IP access. You can change this setting, but be aware that a port change will cause complexity for traffic profiling and other monitoring that relies on SQL Server using port 1433.

Internet Protocol Security (IPSec) and Secure Sockets Layer (SSL) are two additional methods you can use to restrict who can connect to your database. IPSec uses policies that consist of filters, filter actions, and rules. With IPSec, you explicitly specify, by IP address, which computers may connect to your database. SSL uses certificates to restrict who can connect. A client computer must have a known and trusted certificate to successfully connect to the database. An advantage of SSL over IPSec is that configuration changes are not required if the client’s IP address changes.

Use the rule of least privilege throughout the design and implementation of your application in many different ways. It is part of a solid foundation of good security. We will continue to mention this policy and recommend more ways to use it in other areas of your application.

Security Policy

Always grant the minimum of required access and permission.

Use firewalls to restrict inappropriate access.

Use IPSec or SSL to restrict who can connect to your database.

Securing the Database

As we’ve mentioned before, databases include many features to appeal to the widest market and range of uses as possible. You will probably not need the majority of these features and can safely reduce your attack surface by disabling or removing these unused features. Furthermore, databases often have weak default settings. The following is a list of features you can remove, as well as default settings you should strengthen:

Keep your service packs, drivers, updates, hotfixes, and patches current. Review your database vendor’s Web site often to find what service patches are available.

Use strong passwords for all accounts. This is especially important for the sa account, which is present by default in SQL Server. Strong passwords decrease an attacker’s ability to successfully guess, brute-force, dictionary attack, or otherwise discover an account’s password. Always use long and complex passwords for database accounts.

Remove sample code, sample databases, and sample stored procedures. By default, SQL Server comes with the Northwind and Pubs databases and associated stored procedures. There is no reason for these databases to be present in a production environment.

Remove unused network libraries. SQL Server can communicate with applications in a variety of ways. Network libraries, or netlibs, are the modules that determine the method of communication SQL Server can use. TCP/IP is the most popular method of communication, but you can also use Shared Memory, Named Pipes, Banyan Vines, AppleTalk, or VIA GigaNet SAN, as well as others. While you are deciding which communication method to use, disable all the netlibs to prevent access to your database. When you have decided which netlib(s) to use, disable the unused netlibs to limit your attack surface.

Remove extended stored procedures. By default, SQL Server comes with over 60 stored procedures that you might not need. These stored procedures are primarily for convenience and provide the functionality of certain graphical user interface (GUI) tools, such as the SQL Server Enterprise Manager. By removing these stored procedures, you will limit tools and methods an attacker can use to gain access and compromise your database.

The process for securing a database is complex and unique for each platform and database application; the tips mentioned here are only an introduction. Take time to learn the specific security measures for your particular environment.

Security Policy

Keep your database software up to date.

Disable or remove unused features of your database.

Strengthen weak default passwords and permissions.