Comment prévenir les attaques par injection de code en PHP?

Je suis un peu confus, il ya tellement de nombreuses fonctions en PHP, et certains à l'aide de cela, certains en les utilisant. Certaines personnes utilisent: htmlspecialchars(), htmlentities(), strip_tags() etc

Qui est la bonne et que faites-vous le plus souvent?

Est-ce correct (me conseiller un meilleur, le cas échéant):

$var = mysql_real_escape_string(htmlentities($_POST['username']));

Cette ligne peut empêcher l'injection MySQL et attaque XSS??

Btw, est-il d'autres choses, je dois faire attention en plus d'attaques XSS et MySQL injection?

MODIFIER

De conclure:

Si je veux insérer une chaîne de caractères de la base de données, je n'ai pas besoin d'utiliser htmlentities, il suffit d'utiliser la mysql_real_escape_string. Lors de l'affichage des données, de l'utilisation htmlentities(), c'est ce que tu veux??

Résumer:

  • mysql_real_escape_string utilisé lors de l'insertion dans la base de données
  • htmlentities() utilisé lors de la transmission de données dans la page web
  • htmlspecialchars() utilisé quand?
  • strip_tags() utilisé quand?
  • addslashes() utilisé quand?

Quelqu'un peut-il remplir dans le point d'interrogation?

  • strip_tags() peut être dangereux securiteam.com/unixfocus/5UP0C15DFI.html
  • Vous pourriez être concerné par CSRF et directory transversal, le moyen le plus facile de fixer directory transversal est basename(realpath($path)).
InformationsquelleAutor bbtang | 2009-07-30
  1. 64
    • mysql_real_escape_string utilisé lors de l'insertion dans la base de données
    • htmlentities() utilisé lors de la transmission de données dans la page web
    • htmlspecialchars() utilisé quand?
    • strip_tags() utilisé quand?
    • addslashes() utilisé quand?

    htmlspecialchars() utilisé lors de l'?

    htmlspecialchars est à peu près le même que htmlentities. La différence: les encodages de caractères.

    La fois d'encoder les caractères de contrôle comme <, >, & et ainsi de suite utilisé pour les balises d'ouverture etc. htmlentities aussi encoder les caractères d'autres langues comme des trémas, euro-symboles et ces. Si vos sites web sont en UTF, utilisez htmlspecialchars(), sinon utilisez htmlentities().

    strip_tags() utilisé lors de l'?

    htmlspecialchars /entities encoder les caractères spéciaux, ils sont donc affiché, mais pas interprété. strip_tags SUPPRIME.

    Dans la pratique, cela dépend de ce que vous devez faire.

    Un exemple: vous avez codé un forum, et de donner aux utilisateurs un champ de texte de sorte qu'ils peuvent poster des trucs. Les logiciels malveillants juste essayer:

    pictures of <a href="javascript:void(window.setInterval(function () {window.open('http://evil.com');}, 1000));">kittens</a> here

    Si vous ne faites rien, le lien sera affiché et une victime qui clique sur le lien obtient beaucoup de pop-ups.

    Si vous htmlentity/htmlspecialchar votre sortie, le texte sera là comme-est. Si vous strip_tag, il supprime simplement les balises et l'affiche:

    pictures of kittens here

    Parfois, vous voudrez peut-être un mélange, laisser certaines balises, comme le <b> (strip_tags peut laisser certaines balises là). C'est trop dangereux, afin de mieux utiliser certaines complète de la bibliothèque contre le XSS.

    addslashes

    Pour citer un ancienne version du manuel PHP:

    Retourne une chaîne de caractères avec des barres obliques inverses avant de caractères qui doivent être indiqués dans les requêtes de base de données etc. Ces caractères sont le guillemet simple ('), guillemet double ( " ), (barre oblique inverse) et NUL (le NULL octet).

    Un exemple de l'utilisation de addslashes() est lorsque vous entrez des données dans une base de données. Par exemple, pour insérer le nom O'reilly dans une base de données, vous aurez besoin d'y échapper. C'est très recommeneded à l'utilisation de SGBD spécifique de la fonction d'échappement (par exemple mysqli_real_escape_string() de MySQL ou pg_escape_string() pour PostgreSQL), mais si le SGBD que vous utilisez n'ont pas une fonction d'échappement et le SGBD utilise \ pour échapper les caractères spéciaux, vous pouvez utiliser cette fonction.

    La version actuelle est libellée différemment.

    • Grâce stefs - pour moi, j'avais besoin d'une solution simple, comme l'ensemble de la sécurité de la complexité laisse-moi non production de code. Je suis en train d'avoir un script simple qui lit une boucle et en sort une image spécifique et de balise d'url avec un wordpress flux rss des nouvelles entrées sont créées prêt pour le site local à consommer. C'est en travaillant dans la page web, mais je voulais le faire à partir d'un script et tout d'un coup, sans mon cms cadre, je suis reparti avec la peur que j'ai fais un gros trou dans notre serveur pour les exploits. Savez-vous si c'est possible de le faire à partir de mon serveur sans exposer une api d'extrémité /obtenir/news ty
    InformationsquelleAutor stefs
  2. 10

    J'ai pensé à cette petite liste de vérification:

    • Toujours utiliser le protocole HTTPS, sans HTTPS votre site est totalement cryptée. Et non, côté client, le chiffrement des choses et de les envoyer ne fonctionne pas, pensez à ce sujet. Non valide les certificats HTTPS également vous rendre vulnérable à un MITM attaque. Utilisez simplement nous allons Chiffrer si vous ne pouvez pas se permettre un certificat.
    • Toujours utiliser htmlspecialchars() sur toute sortie à partir de votre code PHP, qui est, ou contient une entrée de l'utilisateur. La plupart des moteurs de template vous aider à le faire facilement.
    • Utiliser HTTP seule indicateur dans votre php.ini de bloquer les scripts d'accéder à vos cookies
    • Empêcher session de problèmes liés à l'
      • Ne jamais exposer l'utilisateur PHPSESSID de session (session ID) à l'extérieur du cookie, si quelqu'un arrive à savoir un IDENTIFIANT de Session de quelqu'un d'autre, ils peuvent l'utiliser pour se connecter à son compte
      • Être très prudent avec les Remember me fonction, montrer un petit avertissement, peut-être.
      • Actualisation des ID de session lorsque l'utilisateur se connecte (ou quel que soit le cas)
      • Délai de sessions inactives
    • Jamais confiance à un cookie, il peut être modifié, supprimé, modifié, et créé par un script ou un utilisateur, à tout moment
    • Empêcher SQL problèmes liés à l'
      • Toujours utiliser les requêtes préparées. Les instructions préparées provoque l'entrée de l'utilisateur pour être transmis séparément et empêche L'Injection SQL
      • De rendre votre code génère une exception lorsqu'il échoue. Parfois, votre serveur SQL peut-être en panne pour une raison quelconque, les bibliothèques comme PDO ignorer cette erreur par défaut, et journal d'un avertissement dans les journaux. Cela provoque les variables que vous obtenez à partir de la DB nulle, en fonction de votre code, cela peut provoquer un problème de sécurité.
      • Certaines bibliothèques, comme PDO émuler déclarations préparées à l'avance. Désactiver cette fonction.
      • Utilisation UTF-8 encodage dans vos bases de données, il vous permet de stocker pratiquement n'importe quel caractère et d'éviter de codage-attaques liées à l'
      • Jamais concaténer rien à votre requête. Des choses comme $myquery = "INSERT INTO mydb.mytable (title) VALUES(" . $user_input . ")" joli beaucoup signifie que vous avez un énorme risque de sécurité d'une injection SQL.
    • Stocker les fichiers téléchargés au hasard, à l'extension de moins de noms de fichiers. Si un utilisateur télécharge un fichier avec .php l'extension de fichier alors à chaque fois que votre code charge ce fichier il l'exécute, et permet à l'utilisateur d'exécuter certaines backend code
    • Assurez-vous que vous n'êtes pas vulnérable à une Attaque CSRF.
    • Toujours mettre à jour votre copie en PHP afin de s'assurer que les derniers correctifs de sécurité et des améliorations de performances
    InformationsquelleAutor OverCoder
  3. 6

    Seulement coder les données au point où elle passe dans le système, il doit être codé pour — sinon, vous serez confronté à des situations où vous souhaitez manipuler les données réelles.

    Pour l'injection SQL - utiliser des variables liées, comme décrit dans Comment puis-je prévenir l'injection SQL en PHP? (il parle de déclarations préparées à l'avance, mais c'est la liaison qui vous donne une protection, n'est pas la préparation).

    Pour XSS - si vous écrivez en HTML au point où le format HTML ou texte est spécifié. Utiliser htmlentities à l'endroit où vous générez votre document. Je voudrais éviter de stocker les données de ce formulaire dans la base de données (à l'exception possible dans une écriture-rare-lire-souvent système où les performances du CPU/disque temps d'accès étaient en train de devenir un problème alors que j'aurais un raw_ et un html_ version de la colonne ... ou tout simplement utiliser memcached ou similaire).

    Si vous êtes de permettre aux utilisateurs d'entrer des Url, alors vous devez être plus prudent, car javascript:do_evil() est une URI valide à exécuter (par exemple, comme un href pour un cliqué sur le lien ou (dans certains navigateurs) le src d'une image qui est juste chargé).

    InformationsquelleAutor Quentin
  4. 4

    htmlspecialchars()
    tourne &, ', ", <, et > dans une entité HTML (format de&amp;, &quot;, etc.)

    htmlentities()
    transforme toutes les lois personnages dans leur entité HTML format.

    strip_tags()
    supprime tout le code HTML et des balises PHP.

    Les deux htmlspecialchars() et htmlentities() prendre un paramètre optionnel indiquant comment les guillemets doivent être manipulés. Voir la
    Manuel PHP pour plus de détails.

    La strip_tags() fonction prend un
    paramètre optionnel indiquant quelles balises
    ne doit pas être dépouillé.

     $var = strip_tags ($var, '<p><br />');

    La strip_tags() fonction supprime
    même invalide balises HTML, ce qui peut
    causer des problèmes. Par exemple,
    strip_tags() va tirer tous les
    le code qu'il pense est une balise HTML, même
    si c'est mal formé, comme

    <b I forgot to close the tag.
    InformationsquelleAutor Faraz Kelhini
  5. 3

    Vous avez seulement besoin d'utiliser mysql_escape_string() lors de l'insertion dans une base de données et htmlentites lors de l'affichage du HTML. C'est suffisant si vous voulez éviter qu'une simple injection de l'attaque, mais il n'y a aucun doute de nombreux autres problèmes de sécurité que vous devez être conscient lors de l'élaboration d'une application web, un autre principale étant cross site request forgeries.

    • Il est bon de vous dire cela est suffisant pour éviter qu'une simple code des injections. Pour les sensibles financiers et de l'information médicale, je voudrais aller plus loin et suggèrent d'utiliser PDO ou Mysqli extensions. Idéalement, vous voulez utiliser des requêtes préparées et des requêtes paramétrées. Voir cette réponse: stackoverflow.com/questions/60174/...
    InformationsquelleAutor Sam152
  6. 2

    Je ne voudrais pas utiliser htmlentities() lors de l'insertion de données dans la base de données ou d'interrogation de la base de données. Si les données dans votre base de données est stockée en tant qu'entités, que les données sont ensuite seulement utile à quelque chose qui comprend les entités html.

    Vous devez utiliser différents mécanismes d'échappement pour les différents types de sortie, par exemple, SQL - mysql_real_escape_string(), HTML - htmlentities() ou htmlspecialchars(), shell - escapeshellarg(). C'est parce que les caractères qui sont "dangereuses", sont différents pour chacun, il n'y a pas une manière magique vous pouvez faire toutes les données en toute sécurité pour tout support de sortie.

    InformationsquelleAutor Tom Haigh
  7. 1

    Prendre un coup d'oeil à ce site PHP Security Consortium. Je l'ai trouvé un bon site pour un aperçu global sur PHP de Sécurité (Injection SQL et XSS inclus).

    • Ce site est sérieusement obsolètes de nos jours
    InformationsquelleAutor Henrik P. Hessel
  8. 1

    Je sais que c'est une vieille question, mais de nos jours le plus voté réponse peut être trompeuse pour les débutants.

    À compter de 2017

    1. Vous devriez ne jamais les utiliser mysql_real_escape_string. Même mysqli_real_escape_string est trop faible pour protéger votre base de données contre les injections SQL. Au lieu de cela, vous devez utiliser PDO, et de techniques similaires. (voir que guide)

    2. XSS (je veux dire ici: strip_tags(), addslashes(), htmlspecialchars(), htmlentities()) - ici le plus voté réponse est toujours correct, mais je suggère la lecture de cet article

    InformationsquelleAutor Thomas