Tip

How simple steps ensure database security

    Requires Free Membership to View

  There's more than one way to receive Threat Monitor

Listen to this database security tip on your computer or MP3 player.
Databases and the data they contain remain tempting targets for hackers, who look to exploit the many widespread weaknesses found in database-driven applications. Many of these weaknesses are created by poor configuration or implementation.

The following five database-related vulnerabilities are among the most common:

Incredibly, default or weak passwords are still often used by enterprises to protect an online asset as important as a database, but it's a problem that's easy to fix. The remedy is enforcing a strong password policy; that is, passwords must be changed regularly and be at least 10 digits long and contain both alphanumeric characters and symbols. With this policy, you will close down an attacker's easy route to your data.

More information

Read more about SQL injection and cross-site scripting in our Web Application Attacks Learning Guide.

Learn the best policies for data retention.
SQL injection also relies on poor database implementation, specifically in regard to how SQL queries are sent to the database. If the database accepts SQL queries generated from user-supplied data that has not been cleaned and validated, it is open to SQL injection attacks. For example, by modifying the expected input received from a Web-based form, an attacker can submit malicious SQL queries and pass commands directly to a database.

To prevent this type of attack, it is essential to ensure that all user-supplied data is validated before letting it anywhere near your scripts, data access routines and SQL queries, and preferably use parameterized queries. Another reason to validate and clean data received from users is to prevent cross-site scripting (XSS) attacks, which can be used to compromise a database connected to a Web server. They work by injecting a client-side script such as JavaScript into a Web application's output via a Web form. These scripts are used to gather cookie data, which is often incorrectly used to store information such as a user's account login information.

One problem that is often overlooked when building a database application is data leakage. This is where sensitive data is transferred or made available unintentionally. The classic mistake is failing to secure and control access to database backup tapes. A less obvious leak is via data inference. Often more sensitive data can be inferred from answers to valid queries on the data, such as an illness from prescribed medication. A common solution is to monitor query patterns to detect such activity.

Closely related to data leakage is the improper handling of errors when an error occurs at the database. Many applications display a detailed message. These error messages can reveal information about the structure of the database, which can in turn be used to stage attacks. By all means, log the error for your own records, but make sure your application doesn't return any specific details about the error to users – or to attackers.

To fully secure your database, split the task into the following four areas in order to ensure a comprehensive check:

A database server needs to be hardened in the same way as any other server to ensure that malicious hackers cannot attack the database via vulnerabilities in the operating system. Preferably, the database should sit behind its own application-layer firewall.

To help with the process of securing database connections and defining access controls, create a data flow diagram that tracks how data flows through the application. Next, identify the places where data enters or exits another application and review the trust levels assigned to these entry and exit points. Also define the minimum privileges any external user or process requires to access the system. Configuring and building your database application with security as a key driver will ensure your data stays secure.

About the author:
Michael Cobb, CISSP-ISSAP, is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity.com's Messaging Security School and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.

This was first published in November 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.