Database Security Scanner

Overview

Audit database security configurations, user privileges, network exposure, and data protection controls for PostgreSQL, MySQL, and MongoDB. This skill scans for common vulnerabilities including excessive privileges, missing encryption, default passwords, exposed network ports, unpatched versions, and SQL injection vectors in application code.

Prerequisites

• Database admin credentials for querying system catalogs and security settings
• psql, mysql, or mongosh CLI tools installed
• Access to database configuration files (postgresql.conf, pg_hba.conf, my.cnf, mongod.conf)
• Application source code access for SQL injection scanning (using Grep/Glob tools)
• Knowledge of applicable compliance frameworks (SOC 2, HIPAA, PCI-DSS, GDPR)

Instructions

1. Check authentication configuration by reviewing pg_hba.conf (PostgreSQL) or mysql.user table. Flag any entries using trust authentication, allowing connections without passwords. Verify password_encryption = scram-sha-256 (not md5) in PostgreSQL.

2. Audit user privileges by querying role memberships and grants:

   • PostgreSQL: SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcreatedb FROM pg_roles r WHERE r.rolcanlogin = true
   • MySQL: SELECT user, host, Super_priv, Grant_priv, File_priv FROM mysql.user
   • Flag users with superuser/SUPER privilege, excessive grants, or GRANT OPTION

3. Scan for default or weak credentials. Check for accounts with no password: PostgreSQL SELECT rolname FROM pg_roles WHERE rolpassword IS NULL AND rolcanlogin = true. Check for well-known default accounts (postgres with default password, root without password, admin/admin).

4. Verify network security:

   • Check listen_addresses in postgresql.conf (should not be * in production without firewall)
   • Verify SSL/TLS is enforced: SHOW ssl should return on; pg_hba.conf should use hostssl instead of host
   • Confirm database port is not exposed to the public internet

5. Check encryption at rest:

   • Verify tablespace encryption or volume-level encryption is enabled
   • Scan for sensitive data stored in plaintext: SELECT column_name, data_type FROM information_schema.columns WHERE column_name ILIKE '%password%' OR column_name ILIKE '%ssn%' OR column_name ILIKE '%credit_card%'
   • Flag columns storing PII without encryption or hashing

6. Scan application source code for SQL injection vulnerabilities using Grep:

   • Search for string concatenation in SQL queries: patterns like "SELECT * FROM " + variable or Python f-strings with interpolated table names
   • Search for missing parameterized queries: raw SQL construction without bind parameters
   • Flag ORM raw() or execute() calls with string interpolation

7. Review database object permissions:

   • Check for PUBLIC grants on sensitive tables: SELECT grantee, table_name, privilege_type FROM information_schema.table_privileges WHERE grantee = 'PUBLIC'
   • Verify functions are created with SECURITY DEFINER only when necessary
   • Check for world-readable backup files on the filesystem

8. Audit logging configuration:

   • Verify log_connections = on, log_disconnections = on in PostgreSQL
   • Check log_statement = 'ddl' or 'all' for sensitive databases
   • Confirm audit logs are shipped to a tamper-proof location

9. Check for known CVEs by comparing the database version against the latest security advisories. Flag databases running versions with known critical vulnerabilities.

10. Generate a security findings report with severity levels (Critical, High, Medium, Low), affected components, evidence (query output showing the vulnerability), and specific remediation commands.

Output

• Security findings report with severity-ranked vulnerabilities and evidence
• Remediation scripts (SQL) for revoking excessive privileges, fixing authentication, enabling SSL
• Hardened configuration templates for postgresql.conf, pg_hba.conf, or my.cnf
• SQL injection findings listing vulnerable code locations with fix suggestions
• Compliance checklist mapping findings to SOC 2, HIPAA, or PCI-DSS controls

Error Handling

Examples

PostgreSQL security audit revealing over-privileged roles: Scan discovers 5 application users with SUPERUSER privilege, pg_hba.conf using trust for local connections, and SSL disabled. Remediation: revoke SUPERUSER, create application-specific roles with minimum privileges, switch to scram-sha-256 authentication, and enable SSL with Let's Encrypt certificates.

SQL injection scan of a Node.js application: Grep finds 12 instances of db.query("SELECT * FROM users WHERE id = " + req.params.id) across 4 files. Remediation: replace with parameterized queries db.query("SELECT * FROM users WHERE id = $1", [req.params.id]). Each finding includes file path, line number, and corrected code.

PCI-DSS compliance check for payment database: Scan verifies: credit card numbers stored as hashed values (pass), audit logging enabled for cardholder data tables (pass), database admin accounts shared among team members (fail - individual accounts required), backups unencrypted on S3 (fail - enable SSE-S3). Produces compliance gap report with remediation timeline.

Resources

• CIS PostgreSQL Benchmark: https://www.cisecurity.org/benchmark/postgresql
• CIS MySQL Benchmark: https://www.cisecurity.org/benchmark/oracle_mysql
• PostgreSQL security documentation: https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
• OWASP SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
• Database security checklist: https://www.postgresql.org/docs/current/auth-methods.html