Web Application/SQL Security Suggestions

We recently came across the following suggestions for anyone running a database application on a public interface. These are great recommendations and should be considered. The three topics cover SQL Injection, Password vulnerability and Malware issues.

SQL Injection. Since SQL Injection is not an actual vulnerability, per se, it is an attack technique that takes advantage of poorly coded or configured applications. It’s not easy enough to just patch it, because you can’t. Validate all the input entering the application. Check for type, length, format, and try to restrict input to expected values. Almost all web applications use a shared account to access the database. Ensure that account has restricted privileges on the database, and can only read and write to the necessary objects. When possible, segment the services that make up the applications to use separate restricted accounts, so that each only has access to perform their specific functions. An example would be the segmentation of payment, catalog access, and customer data. Application developers must avoid the usage of dynamic SQL statements, and instead use parameterized SQL statements to prevent injections. Database activity monitoring solutions with intrusion detection will detect and react to SQL injections, allowing an organization to decide how they want to react—block it immediately or collect evidence and contact authorities, as an example.

Passwords. Should an attacker get access to the database, there should be no reason that a properly restricted account they’ve connected with should have access to the list of other users and their passwords. Accessing other database accounts can allow an attacker access to other parts of the database, and most times to other systems on the network, where other sensitive data will reside. All major databases have decent password policy features—use them. They will force users to change their passwords on a regular basis and create strong ones. Of course some users will naturally try to weaken them for the purpose of convenience. Use available tools to continuously monitor for weak passwords and to locate the presence of accounts that should be removed, such as orphaned accounts and default accounts.

Malware. Many times, the web application is just the front door that will lead to the creation of a beachhead somewhere else within the network. Malware can be installed to provide a backdoor, or used for reconnaissance, or be used for siphoning data out. In order to get malware installed, the hacker requires an account that has the administrative privileges to successfully get it installed on the underlying operating system. We discussed restricted access previously, and the account connected to the database should be restricted from any operating system privileges. Note that many databases allow access to the operating system. Un-patched vulnerabilities in the database are a hacker’s best friend, because most allow an attacker to elevate their privileges to garner the administrative privileges that they need. This is why it is important to apply security patches as quickly as possible—it literally covers up the holes. In some cases, vulnerable components can either be removed or reconfigured so they no longer pose a threat. In other cases, databases can be easily misconfigured, introducing other security risks that allow an attacker to gain the privileges they need. Organizations should compare their configurations to third-party verified security checklists to develop a baseline. Two very good resources include the U.S. Department of Defense’s Defense Information Systems Agency (DISA) and the Center for Internet Security (CIS). Both DISA and CIS provide security checklists for databases, called Security Technical Implementation Guides (STIG) and Security Configuration Benchmarks, respectively.

Advertisements

About SCB Enterprises
System Solutions and Integration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: