La sécurité est un concept intéressant et attire beaucoup de monde. Malheureusement, c'est un sujet complexe et même les professionnels s'y trompent. J'ai trouvé des failles de sécurité dans Google (CSRF), Facebook (plus CSRF), plusieurs grands détaillants en ligne (principalement l'injection SQL/XSS), ainsi que des milliers de petits sites à la fois professionnels et personnels.
Voici mes recommandations :
1) Utiliser des requêtes paramétrées
Les requêtes paramétrées forcent les valeurs transmises à la requête à être traitées comme des données distinctes, de sorte que les valeurs d'entrée ne peuvent pas être analysées en tant que code SQL par le SGBD. Beaucoup de gens vous recommanderont d'échapper vos chaînes en utilisant mysql_real_escape_string() , mais contrairement à la croyance populaire, ce n'est pas une solution fourre-tout à l'injection SQL. Prenez cette requête par exemple :
SELECT * FROM users WHERE userID = $_GET['userid']
Si $_GET['userid'] est défini sur 1 OR 1=1 , il n'y a pas de caractères spéciaux et il ne sera pas filtré. Il en résulte que toutes les lignes sont renvoyées. Ou, pire encore, que se passe-t-il s'il est défini sur 1 OR is_admin = 1 ?
Les requêtes paramétrées empêchent ce type d'injection de se produire.
2) Validez vos entrées
Les requêtes paramétrées sont excellentes, mais parfois des valeurs inattendues peuvent causer des problèmes avec votre code. Assurez-vous que vous validez qu'ils sont à portée et qu'ils ne permettront pas à l'utilisateur actuel de modifier quelque chose qu'il ne devrait pas pouvoir faire.
Par exemple, vous pouvez avoir un formulaire de changement de mot de passe qui envoie une requête POST à un script qui change son mot de passe. Si vous placez leur ID utilisateur en tant que variable masquée dans le formulaire, ils pourraient le modifier. Envoi de id=123 au lieu de id=321 peut signifier qu'ils changent le mot de passe de quelqu'un d'autre. Assurez-vous que TOUT est validé correctement, en termes de type, de portée et d'accès.
3) Utilisez htmlspecialchars pour échapper l'entrée utilisateur affichée
Supposons que votre utilisateur saisit son "à propos de moi" comme suit :</div><script>document.alert('hello!');</script><div>
Le problème avec ceci est que votre sortie contiendra le balisage que l'utilisateur a saisi. Essayer de filtrer cela vous-même avec des listes noires n'est qu'une mauvaise idée. Utilisez htmlspecialchars pour filtrer les chaînes afin que les balises HTML soient converties en entités HTML.
4) N'utilisez pas $_REQUEST
Les attaques de falsification de requête intersite (CSRF) fonctionnent en incitant l'utilisateur à cliquer sur un lien ou à visiter une URL qui représente un script qui effectue une action sur un site pour lequel il est connecté. Le $_REQUEST la variable est une combinaison de $_GET , $_POST et $_COOKIE , ce qui signifie que vous ne pouvez pas faire la différence entre une variable qui a été envoyée dans une requête POST (c'est-à-dire via une input balise dans votre formulaire) ou une variable définie dans votre URL dans le cadre d'un GET (par exemple, page.php?id=1 ).
Supposons que l'utilisateur souhaite envoyer un message privé à quelqu'un. Ils peuvent envoyer une requête POST à sendmessage.php , avec to , subject et message comme paramètres. Imaginons maintenant que quelqu'un envoie une requête GET à la place :
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Si vous utilisez $_POST , vous ne verrez aucun de ces paramètres, car ils sont définis dans $_GET Au lieu. Votre code ne verra pas le $_POST['to'] ou l'une des autres variables, il n'enverra donc pas le message. Cependant, si vous utilisez $_REQUEST , le $_GET et $_POST restent coincés ensemble, afin qu'un attaquant puisse définir ces paramètres dans le cadre de l'URL. Lorsque l'utilisateur visite cette URL, il envoie le message par inadvertance. La partie vraiment inquiétante est que l'utilisateur n'a rien à faire. Si l'attaquant crée une page malveillante, celle-ci peut contenir un iframe qui pointe vers l'URL. Exemple :
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Il en résulte que l'utilisateur envoie des messages à des personnes sans jamais se rendre compte qu'ils ont fait quoi que ce soit. Pour cette raison, vous devez éviter $_REQUEST et utilisez $_POST et $_GET à la place.
5) Traitez tout ce que vous recevez comme suspect (ou même malveillant)
Vous n'avez aucune idée de ce que l'utilisateur vous envoie. Cela pourrait être légitime. Il pourrait s'agir d'une attaque. Ne faites jamais confiance à ce qu'un utilisateur vous a envoyé. Convertissez pour corriger les types, validez les entrées, utilisez des listes blanches pour filtrer si nécessaire (évitez les listes noires). Cela inclut tout ce qui est envoyé via $_GET , $_POST , $_COOKIE et $_FILES .
Si vous suivez ces directives, vous êtes à un niveau raisonnable en termes de sécurité.
