Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search

Table Of Contents  CertiGuide to Security+
 9  Chapter 3:  Infrastructure Security (Domain 3.0; 20%)
      9  3.5  Security Baselines
           9  3.5.3  Application Hardening
                9  Data Repositories

Previous Topic/Section  Directory Services
Previous Page
Pages in Current Topic/Section
Next Page
3.6  Summary
Next Topic/Section  Databases
(Page 1 of 3)

A database is a collection of information – about a company’s products, its customers, its financial records, etc. Databases are quite useful tools from a hacker’s perspective. For one thing, they contain data that the company considers valuable enough to retain for some reason or another.

Database Security Issues

As with hardening a web server, hardening a database server tends to be a multi-step process, in which you harden the database server software itself, and then any custom applications/databases your organization’s staff has set up. Don’t overlook the step of checking for security updates for your database server software. While database servers are not as visible on the Internet as web servers are, they’re often not completely invisible either (particularly if a cracker has broken into your web server), and the potential value of their contents makes them an interesting target.

The most straightforward issue with databases is simply configuration of the database for appropriate levels of data privacy and integrity. Your database administrator should be responsible for maintaining the necessary security on the sets of data stored in the database. Each data table can often be assigned its own permissions, which may for example allow web users to just read, or just add to a table. If you need to apply different rules to different users, many databases can be configured to accept individual user logins as well as general connections without authentication, and then match the user login with access rules for the data in the database, to determine what kind of access (delete records, add new records, change records, read only) the user has to each type of data in the database.

Not only can databases contain valuable data, but also they’re often a handy portal into command line access to the OS – sometimes with system administrator privileges – due to programming errors in the database software itself, or in applications written by others, attached to the database server. Some databases feature the concept of a “stored procedure” – small programs stored within the database server to do a series of things (like, often, run certain command line commands) when they are invoked by database users.

The stored procedures often take user-provided data as parameters, to determine exactly what the stored procedure will do. As with CGI script exploits and buffer overflows, it’s sometimes possible to creatively manipulate this data to do something other than what you might expect.

Previous Topic/Section  Directory Services
Previous Page
Pages in Current Topic/Section
Next Page
3.6  Summary
Next Topic/Section

If you find useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

CertiGuide for Security+ ( on
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al. Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.