Need help with DbDat?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

207 Stars 50 Forks GNU General Public License v2.0 273 Commits 2 Opened issues


Db Database Assessment Tool

Services available


Need anything else?

Contributors list

# 6,619
254 commits
# 105,119
2 commits
# 758,350
1 commit
# 1,620
1 commit


Db Database Assessment Tool

DbDat performs numerous checks on a database to evaluate security. The categories of checks performed are configuration, privileges, users, and information. Checks are performed by running queries or reading database configuration files. The goal of this tool is to highlight issues that need immediate attention and identify configuration settings that should be reviewed for appropriateness. This tool is not for identifying SQL Injection vulnerabilities in an application, there are good tools available for that already (e.g. Also, this tool does not attempt to determine what CVEs may impact the version of the target database (but may do so in the future - maybe). Rather, this tool can help you better understand the potential impact of a successful SQL Injection attack due to weak configuration or access controls. A majority of the checks are from the CIS ( Security Benchmarks for databases, so thanks to the CIS! The benchmark documents can be found here:

I highly recommend downloading the benchmark document for your target database as it contains additional information about the checks performed.

Finally, DbDat is intended to be a framework to enable easy creation of new plugins and checks. Contributions from the security, or even database administrator, community is what will make this a great tool. The current set of checks are in no way complete, certainly more needs to be done. Please contribute!

Developing New Database Checks

Pull requests are very welcome! Checks are organized by database type (e.g. MySQL, Oracle, MS SQL, etc.) in the plugins folder. Each check is a single python file that must have

at the begining of the file name. Each file contains a class with a
method. This method is the primary logic for checks. The quick way to get started is to copy an existing check file and modify it. However, see the Developing Plugins section below for more details.

Running DbDat

  1. Be sure you have the necessary dependencies installed for Python scripts to connect to your target database. See dependencies section below.
  2. Add a connection profile entry in the
    file for each database you want to assess.
  3. Run:
    python -p 
  4. View the report. To view the report
    to reports directory and run
    python -m SimpleHTTPServer 9000
    (or choose a port number you prefer). Then open your browser and navigate to

To see a list of additional command line arguments run

python -h

Report Output

The report organizes results by levels, which are RED, YELLOW, ORANGE, GRAY, and GREEN.

  • RED - items needing immediate attention.
  • YELLOW - items needing review.
  • ORANGE - checks that failed to execute properly.
  • GRAY - items that may not be applicable to the version of the database being assessed.
  • GREEN - items that passed


So far DbDat has been tested on Debian Linux, CentOS Linux, and Windows 7 with Python 2.7

MySQL support


pip install MySQL-python

Or on Debian, run:

apt-get install python-mysqldb
PostgreSQL support


pip install psycopg2
Oracle support


pip install cx_Oracle

Note: you will need to install Oracle client libraries for this to work.

MS SQL support


pip install pymssql
Sybase support
  • todo
DB2 support


pip install ibm_db
easy_install ibm_db

Note: you will need to ensure the user running DbDat has access to execute DB2 CLP commands (e.g. db2 and db2level).

MongoDB support


pip install pymongo

To support MongoDB YAML config files run:

pip install pyyaml
CouchDB support


pip install couchdb

Developing Plugins

Plugin Folders

Within the plugins folder there is a folder for each type of database, and each folder contains check files. This is a very simple structure, but you can also browse the plugins folder to get familiar

The database folders will contain: -
- The init file has an import statement for each check file. -
files - These are the actual files performing the database checks. The file and the class defined within the file should have the same name. -
- A file containing common functions. Check files can import
to leverage common functions.

Check Files

When adding a new check file an import statement needs to be added to the corresponding plugin directory's
file. The code pattern for the checks are fairly consistent. Review the existing files to get a sense of how they are structured. Note the difference between checks of type sql and configuration_file.

Check File

There are different "types" of checks that can be defined. The check type is determined by the

variable and can be sql, configurtion_file, nosql, or clp. Below are example implementations for the different check type scnearios.

sql check type

For sql checks the docheck method signature must be: `docheck(self, *results)`

Typical sql check

sql check where SQL variable is set on init

In this example we need the

variable from the calling parent class. The appuser needs to be dynamically added to the sql statement, so the
varaible is being set in the
method. Also, since this docheck method needs to execute the sql we need the DB cursur (connection) as well, this is set in the `init_
method with
self.dbcurs = parent.dbcurs`.

configuration_file check type

For configurationfile checks the docheck method signature must be:

do_check(self, configuration_file)
Parsing configuration files that are compliant with Python's ConfigParser module

Parsing configuration files that are not compliant with Python's ConfigParser module

In this example, the PostgreSQL configuration file does not have sections (e.g.

), so the helper module in the PostgreSQL folder contains a function that handles this. See the
function defined in

For other configuration file formats you will need to define your own parsing logic.

nosql check type

For nosql checks the docheck method signature must be: `docheck(self)`

NoSQL queries need to be executed within the docheck method, so the class `init

method must implement
self.db = parent.db
. The
self.db` variable can then used to execute NoSQL queries within the do
check method.

clp check type

For clp checks the docheck method signature must be: `docheck(self, *results)

. clp checks are needed for IBM DB2 databases so the db2 command line processor can be executed to get information about the database. However, this type of check could be used to execute any arbitrary command line command. All command line output can be parsed from the
variable passed to the do_check method. In addition, you will need to define the
CMD` class method. This variable is list of the command and related arguments.

The Category Variable

Every check must have a category specified using the

variable. The category is a way to organize checks. Possible categories are: Information, Configuration, Privilege, and User. Specify the category that is most relevant to the context of the check.

Outline of Check File

This is a rough example demontrate the pattern a check file should follow:

# (OPTIONAL): Add import statements, include any necessary modules to support this check
import helper

(REQUIRED): Define class, the class must have the same name as its file name.

class check_configuration_evaluate_something():

(REQUIRED): Add documentation, provide information on this check as this will be displayed in the report.

Some description goes here!

(OPTIONAL): Add references, this is only comments in code, adding references is helpful to others.


(REQUIRED): Add the standard set of variables

TITLE    = 'Client Password'
CATEGORY = 'Configuration'
TYPE     = 'configuration_file'
SQL      = None

verbose = False
skip    = False
result  = {}

# (OPTIONAL): Add any custom variables specific to this check 
custom_var = 'custom_val'

# (REQUIRED): Define the do_check method, this is the actual check logic and is called by the main program.
def do_check(self, *results):

    # (REQUIRED): check logic goes here, besure to set values for self.result['level'] and self.result['output']

    # Results from the SQL variable can be processed using:
    for rows in results:
        for row in rows:

        # (REQUIRED):
        # Always set the self.result['level'] and self.result['output'] variables before returning.
        if row[0] == 'bad':
            self.result['level']  = 'RED'
            self.result['output'] = 'Result is %s' % (row[0])
        elif row[0] == 'needs review':
            self.result['level']  = 'YELLOW'
            self.result['output'] = 'Result is %s' % (row[0])
            self.result['level']  = 'GREEN'
            self.result['output'] = 'Result is %s' % (row[0])

    # Always return self.result
    return self.result

# (REQUIRED): at minimum the __init__ method should print the check being performed.
def __init__(self, parent):
    print('Performing check: ' + self.TITLE)

    # get values from the parent calling class
    self.verbose = parent.verbose

Other Database Security Tools

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.