If you're familiar with web application penetration testing and SQL injection then the classic SQL injection exploit string should ring a bell:
' OR 1=1--
This exploit string is utilized by attackers to modify the structure of a dynamic SQL query executed by the target web application. For example, consider the following Java code snippet that executes a SQL query against a backend MySQL database in order to search for albums by a specified artist. The code constructs a dynamic SQL query including unvalidated user input:
String artist = request.getParameter("artist");
query = "SELECT * FROM musicCatalog WHERE artist = '" + artist + "'";This query will match all database table rows where the artist name matches the unvalidated "artist" parameter supplied by the user. A typical search would result in a SQL query that looks something like this:
SELECT * FROM musicCatalog WHERE artist = 'Arctic Monkeys'
However, attackers can utilize the classic SQL injection exploit string in order to maliciously modify the structure of the SQL query:
SELECT * FROM musicCatalog WHERE artist = '' OR 1=1--'
This SQL query will match all table rows where either the artist name matches the empty string or one equals one. Because one always equal one, all rows are matched and returned to the attacker. The double-dash sequence specifies a SQL comment, causing the database to ignore the remainder of the query. Attackers can utilize the "UNION" operator in order to further modify the structure of the query to compromise information from other database tables. For example, another database table might store customer billing information including credit card numbers. Piece of cake, eh? Maybe. Maybe not.
Both attackers and penetration testers alike often forget that MySQL comments deviate from the standard ANSI SQL specification. The double-dash comment syntax was first supported in MySQL 3.23.3. However, in MySQL a double-dash comment "requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on)." This double-dash comment syntax deviation is intended to prevent complications that might arise from the subtraction of negative numbers within SQL queries. Therefore, the classic SQL injection exploit string will not work against backend MySQL databases because the double-dash will be immediately followed by a terminating single quote appended by the web application. However, note that there are exceptions to this rule. For example, user input included within an "ORDER BY" clause is not encapsulated within single quotes. Instead the web application code typically appends a space and either the "ASC" or "DESC" keyword. Therefore the classic SQL injection exploit sting would indeed work in this case. However, in most cases a trailing space needs to be appended to the classic SQL exploit string. For the sake of clarity we'll append a trailing space and dash:
' OR 1=1-- -
This updated classic SQL injection exploit string would result in a SQL query that looks something like this:
SELECT * FROM musicCatalog WHERE artist = '' OR 1=1-- -'
The double-dash comment now properly terminates the remainder of the SQL query and Heather The Hacker can happily get her SQL injection on while scarfing down Cheetos and chugging Mountain Dew. Mmm, Cheetos and Mountain Dew. Note that for simple SQL queries the terminating single quote appended by the web application can simply be matched instead of commented out. For example, consider the following SQL injection exploit string:
' OR 'a'='a
This exploit string would result in a SQL query that looks something like this:
SELECT * FROM musicCatalog WHERE artist = '' OR 'a'='a'
In this case the exploit string properly balances the terminating single quote appended by the web application. Therefore the syntax of the SQL query is still valid and the SQL injection attack is successful. The same technique can be used within exploit strings that utilize the "UNION" operator in order to compromise information from other database tables. However, this approach will not work against more complex SQL queries. For example, consider the following SQL query:
query = "SELECT * FROM musicCatalog WHERE artist = '" + artist + "' AND price = '6.99'";
This query will match all database table rows where the artist name matches the unvalidated "artist" parameter supplied by the user and the price is $6.99. In this case the additional "AND" condition prevents single quote matching from resulting in useful SQL injection. The previous exploit string would result in a SQL query that looks something like this:
SELECT * FROM musicCatalog WHERE artist = '' OR 'a'='a' AND price = '6.99'
As you can see even though the exploit string properly balances the terminating single quote the additional "AND" condition prevents the query from matching all table rows. However, a properly spaced double-dash comment will still result in useful SQL injection:
SELECT * FROM musicCatalog WHERE artist = '' OR 1=1-- -' AND price = '6.99'
Of course web application developers should implement parameterized prepared statements (or securely coded stored procedures) in order to prevent SQL injection in the first place. Are your developers perfect? Didn't think so. In that case, remember this double-dash comment syntax quirk when penetration testing a web application that interfaces with a backend MySQL database. In addition, some automated web vulnerability scanning tools do properly account for MySQL double-dash comment syntax, so be sure to pick up their slack. Otherwise your doomed SQL injection attempts might flop like busted politicians across the nation: "No comment!"