Où utiliser mysql_real_escape_string pour empêcher l'Injection SQL?

Je suis en difficulté, avec un groupe de hackers. ils ont piraté mon site client à quelques reprises, et mon client devient de plus en plus en colère 🙁 mon client a perdu sa base de données (qui a des centaines de dossiers), et a dû entrer tous 🙁

maintenant, je suis à la suite de certaines plus introductions;

  • fixe les autorisations de fichier
  • changé ftp hôte et les informations de connexion au
  • effacé tous mysql distant accède

en train de travailler sur le problème d'Injection SQL. J'ai ajouté mysql_real_escape_string à l'admin de connexion au panneau paramètres. Alors, où dois-je utiliser ce mysql_real_escape_string ? J'ai quelques formes e-mail sur le site, je ne pense pas que j'ai besoin d'y ajouter...

J'ai un index.php en tant que page d'accueil. Dois-je faire quelque chose pour cette page afin de prévenir toute attaque par injection sql via l'url comme index.php?somesql= ?

Merci de me conseiller! J'apprécie tellement!!! 🙁

par exemple:

J'ai ce code;

public function showDetails($id) {

    //SQL Jobs Details
    $this->sql_job = "SELECT * FROM jobs WHERE id=".mysql_real_escape_string($id);
    $this->rst_job = mysql_query($this->sql_job);           
    $this->row_all = mysql_fetch_assoc($this->rst_job);     

    //SQL State
    $this->sql_state = "SELECT title FROM state WHERE id=" . $this->row_all[$this->tbl_jobs['f4']];
    $this->rst_state = mysql_query($this->sql_state);   
    $this->row_state = mysql_fetch_assoc($this->rst_state);
........

est-il suffisant pour utiliser mysql_real_escape_string pour $id . pas pour $this->row_all[$this->tbl_jobs['f4']]

Je suis un MSSQL mec, donc j'espère que cela s'applique -- pourquoi un site web de connexion même avoir l'autorisation de supprimer quelque chose? Comme pour la perte d'une base de données, où sont les sauvegardes??
"SELECT * from emplois where id=".mysql_real_escape_string($id) est vulnérable à l'injection sql. $id="1 ou sleep(50)"
+1 vers la tour. mysql_real_escape_string n'est pas une solution magique, c'est juste une chaîne de s'échapper de la fonction et ne fonctionne que lorsqu'il est utilisé à l'intérieur des guillemets.

OriginalL'auteur designer-trying-coding | 2010-02-22

  1. 13

    Fondamentalement, chaque fois que vous utilisez certains dangereux de données (saisie de l'utilisateur, la valeur à partir d'une base de données, un fichier ou un site web externe, c'est à dire toutes les données que vous n'êtes pas 100% assurer qu'il est sécuritaire) dans une requête SQL, vous devez échapper à l'aide de mysql_real_escape_string. Notez que selon l'OWASP, cette fonction n'est pas sécurisé pour échapper dynamique des noms de table (mais c'est beaucoup moins courante que la "base" saisie de l'utilisateur insertion).

    Je vous suggère de jeter un oeil à l'ensemble de la OWASP article sur l'injection SQL, et aussi à parcourir le reste du site. C'est une excellente source d'information sur la sécurité dans les applications web.

    De l'OMI, la meilleure façon de prévenir l'injection SQL consiste à utiliser les requêtes préparées.

    N'oubliez pas que si vous ne choisissez d'utiliser mysql_real_escape_string() il ne fonctionne que lorsque
    utilisé à l'intérieur d'une chaîne de caractères est délimitée par des guillemets. Ne l'utilisez jamais sur
    toutes les valeurs non cotées. Cela inclut des valeurs numériques; au lieu de cela, valider le fait que l'entrée utilisateur est en réalité numérique.

    Non seulement la saisie de l'utilisateur en soi. Toutes les données que vous utilisez en tant que paramètre, vous ne pouvez pas être absolument sûr (pour l'éternité) qu'il ne contient pas de caractères que vous avez à s'échapper. E. g. si pour une raison quelconque), vous tirez sur des données provenant de la base de données et l'utilisation de ces données dans une autre requête, aucune interaction de l'utilisateur, mais vous avez toujours à échapper aux données. Ou d'utiliser les requêtes préparées.
    Vous avez raison, je vais mettre à jour ma réponse avec vos précisions. Merci!

    OriginalL'auteur Wookai

  2. 4

    Les deux plus grandes choses à faire avec la saisie de l'utilisateur sont

    1. Le Filtrage D'Entrée
    2. D'Échappement De Sortie

    Le Filtrage d'entrée est le processus de transformation de données /[avant]/il est stocké dans la base de données. L'exécution de mysql_real_escape_string() s'inscrit dans cette démarche (bien qu'il existe de meilleures façons pour désinfecter les données de l'utilisateur pour la db de l'insertion), mais cette étape peut également inclure le parage des blancs de l'espace, la grossièreté de filtrage, de balisage de conversion, et plus encore.

    D'Échappement de sortie est de prendre soin lors de l'envoyer le contenu d'utilisateur pour le navigateur que vous ne laissez pas les comportements malveillants. Cela signifie que l'exécution de htmlentities() ou certains autres sélective processus de dépistage.

    Il y a d'autres choses que vous pouvez faire, comme la limitation de ressource (DOS de la prévention), la forme de jetons (protection CSRF), etc. Aller à OWASP et commencer la lecture.

    OriginalL'auteur Peter Bailey

  3. 3

    L'une des règles d'or du développement web n'est JAMAIS (JAMAIS!) la confiance la saisie de l'utilisateur. Par conséquent, partout où vous avez des données dans la base de données, vous devez appeler mysql_real_escape_string().

    Aussi, pour éviter la colère des clients dans l'avenir, vous devriez régulièrement une sauvegarde de votre base de données. Si j'étais à votre client, je serais furieux droit maintenant.

    Bonne chance pour la sécurisation de votre site.

    merci pour la réponse. ce sujet de l'appel de données à partir de db? doit-on utiliser mysql_real_escape_string() dans ce cas? ou juste pour les variables sql aller à la base de données?

    OriginalL'auteur Steven Mercatante

  4. 3

    La meilleure façon de prévenir l'injection SQL est avec l'utilisation de déclarations préparées à l'avance et de lier les variables. Quelle est la version de MySQL que vous utilisez? Les requêtes préparées sont disponibles en 4.1 et supérieur.

    OriginalL'auteur shoover