CODEWITHSUNDEEP
sqlsql-injection
SpacePyro
SpacePyro

Reputation: 3150

SQL injection against quote()?

Note: This is a project with a made-up site inside a virtual machine. It is a senior college project that I am working on. I am not trying to exploit an actual, real-world website. This is for educational purposes to understand how powerful such exploits can be, even with given functions.

I'm currently working on a project (under a safe and controlled environment, inside a VM) that involves exploiting vulnerabilities of a website. One part involves exploiting a SQL statement. The goal is to be able to just type in a username and an incorrect password and still be able to log in. I've been working on this for a few hours with no such luck, and I've done quite a bit of research on seeing what vulnerabilities are available.

When a person submits their username and a password (in this case, it can be anything), a function is run with the following prepared SQL statement:

$query = "SELECT Salt FROM Accounts WHERE Username = '$quoted'";

Where $quoted is:

$quoted = $this->db->quote($user);

This essentially adds an additional single/double quote for every single/double quote provided. Despite trying other possibilities (such as ' OR 1=1', etc), the closest thing I've come up with is this:

SELECT Salt FROM Accounts WHERE Username = '\'' OR 1=1 -- '

With the $user variable originally being \' OR 1=1 --. The first and last quotes are added automatically through the quote() function, along with the additional quote after the escaped single quote. This however doesn't seem to be proper SQL syntax, probably because it is interpreting the entire $user input as a Username.

There is another prepared statement after this one, but it relies on an md5 hash of a password concatenated with a salt, and I don't think there is really any way of making anything inject-able in the statement once md5 returns the hash. For curiosity, the statement is this:

$query = "SELECT * FROM Accounts WHERE Username = '$user' AND Password = '$hash';

With $hash = md5($pass.$salt).

Does anyone want to shed some light on any possibilities? Maybe I'm just really overlooking it, but I feel like I've tried everything.

EDIT: I solved this. It had to do with working around another function to exploit the injection. It ultimately added a username with the injection code (second-order injection), and then it would do a login. The login procedure quoted the username for the first query, but the second query did not; thus, the user would automatically log in.

Upvotes: 0

Views: 3781

Answers (2)

Abhishek Gautam
Abhishek Gautam

Reputation: 48

' or 1=1 LIMIT 1-- SELECT * from tsdf where sdf='

to counter the last quote just add a SELECT query to make the statement valid. It will have no effect as -- is used before that.

Upvotes: -1

Jonathan Leffler
Jonathan Leffler

Reputation: 755054

Backslashes in SQL are a vexed subject, rather dependent on the DBMS in use.

Standard SQL ascribes no meaning to them. To escape a quote in a string, you double up the quote. The quote method you're using seems to follow that principle:

  • Input: \' OR 1=1 --
  • Output: '\'' OR 1=1 --'

Some DBMS may actually define a meaning for backslashes. However, to complicate things further, you typically have an indeterminate number of intermediary languages (PHP, ODBC, etc) and these may modify strings too, and may apply meanings to backslashes that pure SQL does not.

If you typed X' OR 1=1 --, (with X in place of the backslash), you would get the same mapped string with the backslash replaced by the X. So, if the attack is going to work, you need the quote() method to be confused about what the DBMS is going to do with the backslash, but that would amount to a bug in the quote() method.

You might get more traction if you managed to embed a Unicode escape sequence. For example, U+0027 (decimal 39) is the single quote. This sort of trickery might get you past quote(), but it probably won't. The idea behind the quote()-like methods is that you should not be able to wriggle text past them that means something other than what was expected. Non-minimal UTF-8 encodings for characters might manage to trigger problems because of a bug in the server, but it isn't all that probable. The Unicode standard is clear that invalid UTF-8 encodings should not be accepted — that's doubly true anywhere near security information.

You're right that the output of a hash, enclosed in quotes, is not going to be usefully injectable, especially if the attacker never sees the salt.

Upvotes: 2

Related Questions