Web Database Vulnerabilities

What specific vulnerabilities affect Web enabled databases? What can be done to prevent them from happening?

Meier, from Microsoft, claims that the main threats to a database server are SQL injection, Network eavesdropping, Unauthorized server access, and Password cracking. (Meier, 2003) Since we are focusing on web databases, the relevant two threats are SQL injection and network eavesdropping. The other two are primarily local threats, assuming that the password cracking is hash cracking.

Network eavesdropping is a concern if the database is being accessed over an unencrypted protocol, such as HTTP, since the communicated data is visible in the traffic. This causes threats to the confidentiality of the data being read from or written to the database as well as threats to the integrity of the data. If the network connection is being manipulated by a man-in-the-middle attacker, they could modify requested database writes or the returned database reads. (Kabay, Holden, & Walsh, 2002) The ultimate threat of network eavesdropping is if credentials are being passed in the clear because that risks turning over complete database control to the attacker. (Meier, 2003)

Eavesdropping is most easily addressed by forcing all traffic to be encrypted, like using HTTPS instead of HTTP for the web connections.

SQL injection, or attacking “Applications that construct queries on the fly can be fooled into constructing improper queries” (Gertz & RosenThal, 2006), is where “the attacker exploits vulnerabilities in your application's input validation and data access code to run arbitrary commands in the database using the security context of the Web application.” (Meier, 2003) This vulnerability occurs regularly, despite its severity, because the quickest, easiest way to generate a SQL query is through normal string building operations can concatenating in the search specific values. Often these values have been received directly from the outside and may have been maliciously crafted, but not validated or escaped. Thus, special characters and keywords have special meaning to the database and get executed instead of just searched for.

All input data should be limited, checked for validity, and sanitized of anything that may be viewed as code. This can mean escaping special characters or stripping them out of the string entirely. Limiting data to expected formats helps too, such as a search for numerical data should be checked that it only contains numerical characters. SQL queries should use type safe parameters, as this prevents string building and mismatched data types as well as guaranteeing that data passed in is treated as data and not executable statements. Lastly, the web facing account should have the least privileges possible. If the web interface is only for reading then the account should not even have write privileges. Tables that will not be queried through the web should not be readable by that account either. (Meier, 2003)

---

Gertz, M., Rosenthal, A. (2006) Database Security. In H. Bidgoli (Ed.), Handbook of information security, volume 3. "Database Security Mechanisms and Models" p. 164. New York, NY: John Wiley & Sons, Inc.

Kabay, M., Holden, D., Walsh, M. (2002). Operations Security and Production Controls. In Bosworth et al (Eds.), Computer security handbook. New York, NY: John Wiley & Sons, Inc.

Meier, J. D. (2003). Improving web application security: threats and countermeasures. O'Reilly Media, Inc..