0

I'm trying to test SQL injection on a site (PHP, uses MySQL Database). When I put an apostrophe in the username field and leave the password box blank, after submitting, the form reloads and the fields become empty again. But when I used an apostrophe in the password field, the message says "Invalid Username/password".

What does that indicate? And if I put admin' as username (don't add comments) and in the password field, write ;Drop Table users; (don't add comment) are my comments gonna work?

1 Answer 1

3

Not enough information to tell - given this, it could simply be rejecting empty passwords, and taking any input in the password field, hashing it, then checking it against the DB safely.

Consider the following pseudocode (this is not intended to be good practice, just clear to read - do not use in production!):

if (isempty($password)) {
  reloadPage();
} else {
  $query = "SELECT * FROM users where username = :username";
  if ($user = dbquery($query, $username)){
    if (checkpassword($password, $user.password)){
      login();
    } else {
      reloadPage("Invalid Username/Password");
    }
  } else {
    reloadPage("Invalid Username/Password");
  }
}

This would give the described behaviour, without (assuming that the dbquery function makes a clear distinction between query data and user supplied parameters) allowing SQLi.

In a slight aside, using DROP TABLE in a penetration test is unlikely to go down well with the client. You should use safer methods to verify the potential flaw: get the current DB user, for example.

7
  • Okay but i used that in password field,where putting only password shows invalid message means it is properly sanitized?
    – Rifat
    Commented Jul 5, 2018 at 10:07
  • and point to be noted is i didnt used -- after drop table users; rather i used ';drop table users; so if the password field was unsanitized,this should have been a sql syntax error right? @ Matthew
    – Rifat
    Commented Jul 5, 2018 at 10:11
  • Why would you expect an SQL error in that case? You would only get an SQL error of any sort if that string is passed to the SQL engine - in many cases, the contents of the password field are never sent to the DB, with comparison happening at the application layer. In other cases, the password is hashed at the application layer, and only the hash is seen by the DB. In either case, your input is never seen by the DB, even if it would be possible to trigger SQLi in the statement which includes the hash. In the sample code, the password never touches the DB.
    – Matthew
    Commented Jul 5, 2018 at 10:24
  • Then how people perform sql injection through password field?
    – Rifat
    Commented Jul 5, 2018 at 10:30
  • In some cases, usually for legacy systems, the password is passed directly to the DB - if the pseudocode was SELECT * FROM users WHERE username="$username" AND password="$password", essentially. This would imply that passwords were not hashed, although password=hash("$password") could still be vulnerable, if it was possible to escape the hash function (e.g. a")-- ) without sanitising. This pattern is fairly rare in modern code though - it has a lot of drawbacks.
    – Matthew
    Commented Jul 5, 2018 at 10:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .