Comment prévenir MySQL sommeil injections?

Récemment, un hacker essayé de ralentir mon site en utilisant le sommeil de l'injection. Bien que nous soyons à l'aide de précautions comme mysql_real_escape_string() pour couvrir la plupart de ces entrées. Nous sommes en train de id du produit à travers la chaîne de requête et il rend la commande comme:

$id = mysql_real_escape_string($_REQUEST['id']);
$qry = "Select * from products where id = ".$id;

mais hacker essayé de fournir des commentaires comme

?id=3 and sleep(4)

et de la requête devient

Select * from products where id = 3 and sleep(4);

Bien qu'il existe quelques solutions comme

  1. Vérifier si l'id de produit est numérique ou pas
  2. Supprimer mot de sommeil de l'entrée à l'aide de quelques personnalisé en fonction

Est-il une autre méthode pour arrêter cela? Quelle est la meilleure méthode pour empêcher le sommeil des injections?

  • Savez-vous que mysql_ fonctions sont obsolètes et vous ne devriez pas les utiliser?
  • Paramètre de liaison permet d'éviter ce
  • utilisation mysqli_ au lieu mysql_
  • Aye, regardez les instructions préparées non seulement à empêcher le sommeil de l'injection " (que je n'ai pas entendu parler), bur tous les types d'injection SQL.
  • +1 Meilleure question, j'ai lu aujourd'hui.
  • C'est un vieux site web et l'utilisation 5.3. Je pense que les fonctions mysql_ a été abandonné dans les dernières versions seulement
  • La Grande Évasion (Ou: Ce que Vous Devez Savoir Pour Travailler Avec du Texte Dans le Texte)
  • Certains des gens de répondre à cette question sont tellement polarisé, c'est incroyable. Je suggère fortement à quiconque se soucier de param filtrage et AOP de lire ce thread sur le sujet qui semble plus raisonnable et rationnelle—point de vue sur cette question.
  • double possible de Comment prévenir l'injection SQL en PHP?
  • En fait, l'attaquant ne peuvent pas voulu ralentir votre site web, mais lire tout le contenu de votre base de données à l'aide d'une fonction du temps à l'aveugle de la requête d'attaque. Le truc, c'est qu'il peut essayer de deviner octet par octet, en utilisant quelque chose comme ET <à titre de comparaison> == "UN" ET le SOMMEIL(5) - si la page met +5 secondes, puis la première hypothèse était VRAIE. Il est incroyable de voir comment l'ensemble de la base de données peut être lu comme ça (même si lent).

InformationsquelleAutor dirtyhandsphp | 2013-01-27
  1. 20

    Vous n'échappent pas correctement. mysql_real_escape_string est pour échapper à SQL chaîne syntaxe correctement, mais vous êtes tout simplement l'intégration de la valeur nue de la valeur, non pas comme une chaîne SQL. Vous avez besoin de:

    $qry = "SELECT * FROM products WHERE id = '$id'";

    Notez les guillemets autour de l'id dans la requête.

    Si l'id est numérique mais, casting pour un certain nombre serait plus judicieux:

    $id = (int)$_GET['id'];
    • +1 Pour souligner la bonne utilisation de mysql_real_escape_string.
    • Merci pour la réponse. J'avais accepté parce que c'est la première partie une bonne utilisation de mysql_real_escape_string() est plus relatif et plus rapidement une réponse de ma question.
    • Il est utile d'ajouter que mysql_* fonctions sont obsolètes et ne doivent pas être utilisés plus.
    • aussi il est très important de noter, que la requête nécessite des guillemets simples pour fonctionner correctement. dans le cas où vous utilisez des guillemets à l'intérieur de la chaîne de requête pour sorround la valeur rendra {mysql_real_escape_string()} inutile!
    InformationsquelleAutor deceze
  2. 10

    La meilleure méthode pour empêcher les injections SQL est d'utiliser la technologie actuelle. MySQL mysql_ famille de fonctions est obsolète et sera supprimée à partir de PHP dans une future révision.

    Vous devez utiliser des requêtes préparées avec MySQLi ou PDO à la place.

    Ces technologies utilisent des déclarations préparées à l'avance et les requêtes paramétrées. Les instructions SQL sont analysés par le serveur de base de données séparément de tous les paramètres. Il est impossible pour un attaquant d'injecter du SQL malveillant.

    En gros, vous avez deux options pour y parvenir:

    1. MySQLi:

      $stmt = $dbConnection->prepare('SELECT * FROM table WHERE name = ?');
$stmt->bind_param('s', $name);
$stmt->execute();
$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
    //do something with $row
}

    2. AOP:

      $stmt = $pdo->prepare('SELECT * FROM table WHERE name = :name');
$stmt->execute(array(':name' => $name));
foreach ($stmt as $row) {
    //do something with $row
}

    Ce qui se passe, c'est que l'instruction SQL que vous passez à prepare est analysé et compilé par le serveur de base de données. En spécifiant des paramètres (soit un ? ou un paramètre nommé comme :name) vous dites que le moteur de base de données que vous souhaitez filtrer. Ensuite, lorsque vous appelez execute l'instruction préparée est combiné avec les valeurs des paramètres que vous spécifiez.

    La chose importante ici est que les valeurs des paramètres sont combinés avec l'compilé déclaration, pas une chaîne SQL. SQL injection fonctionne en incitant le script dans malveillants, y compris les chaînes lorsqu'il crée SQL afin de les envoyer à la base de données. Envoyer le réel SQL séparément à partir des paramètres vous limitez le risque de se retrouver avec quelque chose que vous n'avez pas l'intention. Tous les paramètres que vous envoyez lorsque vous utilisez une instruction préparée va juste être traitées comme des chaînes (bien que le moteur de base de données peut faire quelques optimisation des paramètres peut finir comme les numéros de trop, bien sûr).

    • Je comprends le concept de “préparées”, mais pouvez-vous expliquer pourquoi il n'est pas valide pour filtrer les $_REQUEST['id'] comme une première couche de protection contre les params d'être passé?
    • La vraie question est "Pourquoi?" Le filtrage est la façon dont nous l'avons fait dans le passé, mais les temps changent, et nous avons déménagé.
    • Pour une valeur numérique, vous me dites il a tout de tomber dans la ligne de “préparées” & nous devons tout simplement faire confiance que les méthodes d'interface—qui ont des défauts qui ne sont pas apparents jusqu'a révélé—est le meilleur? Pensez-vous réellement suggèrent pur URL params devrait juste être passé le long décochée? Ça semble être un problème en attente de se produire.
    • J'ai révisé ma réponse pour expliquer pourquoi le filtrage est inutile avec une déclaration préparée.
    • Je n'ai toujours pas d'accord. Et la lecture de ce thread sur le sujet, il semble que d'autres ont une meilleure santé de point de vue sur ce.
    • C'est génial, surtout la partie qui dit, "...et il est beaucoup plus difficile à enlever. Autant que je sache, vous avez failli ne jamais voir le réel d'ordre 2 attaques, comme c'est généralement plus facile de social-ingénieur à votre façon." Et puis le commentaire, "Si TOUTES vos requêtes paramétrées, vous êtes également protégé contre la 2ème commande d'injection. 1ère commande d'injection, c'est d'oublier que les données de l'utilisateur sont pas dignes de confiance. 2ème commande d'injection, c'est d'oublier que la base de données est indigne de confiance (parce que c'était de l'utilisateur à l'origine)." Qui met une cerise sur elle, vous ne pensez pas?
    • Aujourd'hui, le “cas limite” est demain commune de l'exploiter.” Fait le travail sur l'Internet, depuis 1992, ou alors & web depuis 1995. Qui a toujours été le cas. Simple et param filtrage n'est pas exagéré quand il est à peine 2 lignes de code en plus.
    • Hey les gens, Gordon est absolument droit. Si vous pensez échapper de données pour SQL est simplement une mesure de sécurité, alors vous êtes dedans pour une surprise. Ne pas s'échapper de données pour quelque chose jusqu'à ce que vous l'utilisez dans le contexte, il doit être échappés. Sinon, vous êtes juste faire un gâchis de vos données! Aussi, du second ordre attaques ne doivent jamais être possible si vous construisez votre système de droit et d'utiliser les requêtes préparées. Vous pouvez penser que ce n'est pas un problème... mais il est. Même si vous ne le voyez pas comme un problème de sécurité, n'oubliez pas qu'un simple guillemet dans un champ vis de vous plus tard. Peut-être pas méchant, mais cassé au moins.
    • Freeman : Votre réponse est plus pertinent pour une utilisation future, parce que je ne peux pas convertir l'ensemble de votre site à utiliser PDO états où il n'est pas en cours d'exécution sur la dernière version. Mais merci beaucoup pour ce une bonne réponse. Malheureusement, je ne peux pas accepter plusieurs réponses.

    InformationsquelleAutor Gordon Freeman
  3. 2

    C'est la mauvaise question à poser.

    "Comment prévenir les injections mysql?" il doit être. Dormir ou ne pas dormir - il n'a pas d'importance.

    Et il y a beaucoup de réponses sur cette question déjà

    • La question est valide. Cette thread sur le sujet semble plus raisonnable point de vue sur cette question.
    InformationsquelleAutor Your Common Sense
  4. 0

    vous devez convertir vos requêtes dans "préparées" à l'aide de PDO ou mysqli.

    InformationsquelleAutor Emery King