Web servers and databases provide a unique opportunity for vulnerability scanning. Although they often work together, they are actually separate services, each with its own vulnerabilities and listening ports. They are often installed on separate computers and have their own IP addresses. Web servers are often public-facing, whereas database servers are almost always on the private network. The web server will then have a backend connection to the database server. Most database servers use the SQL language and listen on TCP or UDP port 1433. If you have access to the internal network, you can try scanning the SQL server directly. Or, if your access is through the web server, you can try scanning the web application to see if it will pass illegal commands to the SQL server (SQL injection). In smaller applications, the web server and database can be part of the same application, installed on the same computer. Here are possibilities for scanning a web server and its database:

  • Scan the web server on TCP 80 or 443 for web-server-specific vulnerabilities.
  • Scan for web servers that run on non-standard ports.
  • Scan any web apps running on the web server for vulnerabilities not related to SQL.
  • Scan the web app for SQL-injection-related vulnerabilities.
  • Scan the SQL server directly on its port (usually TCP 1433).

Some common web application vulnerability scanners include:

  • Arachni
  • Metasploit WMAP
  • Nikto
  • Grabber
  • Vega
  • Wapiti
  • W3af
  • Skipfish
  • Wfuzz
  • Grendel-Scan
  • Metasploit Pro
  • SQLMap
  • Zeus-Scanner (formerly Whitewidow)
  • nmap http-*.nse scripts

Some common SQL-specific vulnerability scanners and testers include:

  • Microsoft SQL Vulnerability Assessment
  • ms-sql-info.nse
  • ms-sql-empty-password.nse
  • Metasploit auxiliary/scanner/mssql modules: mssql_ping, mssql_sql, mssql-enum, mssql_idf