SQLSnoop: Secondary DBMS Attack by Expanding SQL Injection Techniques

SQL Injection is a well-known vulnerability that has persisted in web applications for decades. A widely held assumption among developers is that even when SQL Injection is present, hashing or encrypting sensitive data using SQL-provided cryptographic functions, such as sha256() or md5(), renders stolen data unrecoverable. This paper challenges that assumption directly. We demonstrate that invoking cryptographic functions within SQL statements does not protect plaintext credentials against an attacker who already has SQL Injection access, not because the hash functions are weak but because their plaintext arguments are transiently exposed in DBMS in-memory monitoring views before the hash function executes. We exploit this window using a technique that we call SQLSnoop, which repurposes built-in SQL looping constructs to poll the monitoring view at high frequency within a single injected statement. We demonstrate SQLSnoop against four major RDBMS platforms: MySQL, MSSQL, Oracle, and PostgreSQL. Systematic quantitative evaluation is conducted on MySQL, while feasibility on MSSQL, Oracle, and PostgreSQL is confirmed through working Proof-of-Concept implementations against each platform’s respective in-memory monitoring view. Our evaluation on MySQL shows attack success rates consistently above 90%, reaching 100% at 1.2 or more virtual CPU cores, and holding across all four Data Manipulation Language operations. The key practical implication is that SQL-layer hashing is fundamentally insufficient as a defense against SQL Injection, and sensitive data must be hashed at the application layer before the SQL statement is constructed.