Piratage de code PHP avec injection SQL

J'ai un code comme celui-ci qui est ouvert à l'injection SQL. Nous avons piraté et maintenant nous l'avons fixé. Je veux juste savoir ce que les entrées (nom d'utilisateur et mot de passe) doit être en ordre de pirater ce code. Je veux dire, même si vous avez entrée

username = something' OR 'x'='x

Ensuite, vous pouvez récupérer le mot de passe du premier utilisateur dans la table quel que soit le nom de l'utilisateur. Cependant, à l'intérieur de la if nous vérifions si ce mot de passe est correct. Je suis en supposant que le mot de passe a été très facile (aussi facile que 123456), et le pirate a fait une force brute à partir d'un dictionnaire. Cependant, je me demande si il existe une autre façon de pirater ce code à l'aide de certains d'injection autre que brute-forcer le mot de passe.

<?php
$username=$_POST['username'];
$password=$_POST['password'];

$result=runQuery("SELECT password FROM tbl_users WHERE username='".$username."''");
$row=mysql_fetch_array($result);

if($row['password']==$password){
    -- do sth... create a cookie etc..
}
else{
    --go to another page...
}
?>
  • Je ne crois pas que vous lisez sur l'injection sql.
  • Cette question semble être hors-sujet parce que c'est un code d'examen de la demande. C'est mieux adaptée à codereview.stackexchange.com
  • Pour protéger contre les injections sql, vous devez utiliser PDO, ou mysqli. Vous n'êtes même pas échapper à votre entrée dans votre exemple. Comme l'a dit Mike, je ne crois pas vraiment que vous avez lu quelque chose au sujet de l'injection sql dans la première place.
  • Nom d'utilisateur: Bobby'; DROP TABLE tbl_users; --
  • Je pense que vous êtes absent de votre espace à la fin de l'injection 😉
  • Quel fut l'effet du piratage?
  • Quelle est l'url, on ne peut pas le tester sinon.... 😉
  • Je n'avais jamais entendu parler de cela, je vous remercie. OP, vous devriez lire à propos de paramaterized requêtes. Si vous travaillez sur un site web qui implique un système de connexion, vous devez être familier avec et de savoir comment corriger/éviter l'OWASP top ten des risques de sécurité. Ici Numéro 1 est d'injection SQL.
  • Le hacker n'est pas une table ou quoi que ce soit. La table était là, le mot de passe n'a pas été mis à jour. Ce compte d'utilisateur est utilisé pour ajouter un petit commentaire à un mur. Il y avait des commentaires d'un hacker sur le mur.. et la tbl_users a été épargnée.

InformationsquelleAutor albatross | 2013-09-16