Forum d'entraide PHPFrance

Je fais des tests sur mes sites depuis pas mal de temps concernant les problèmes d'injection Mysql, par formulaire, url, etc etc ....

J'ai lu pas mal de posts sur pas mal de sites sur les problèmes de sécurité et les différentes techniques d'intrusions sur un site sont tellement nombreuses qu'on fini pas se poser pas mal de questions.

Pour éviter pas mal de problèmes, j'ai pour habitude, pour chaque site :

- De créer un utilisateur spécifique avec les droits "USAGE" pour chaque base de donnée Mysql.
- De filtrer systématique les variables des formulaires par un mysql_real_escape_string()
- De ne jamais utiliser de variables $_GET (URL) sans passer par un mysql_real_escape_string() avant d'utiliser sa valeur pour une requete mysql
- De ne jamais afficher le contenu d'un formulaire sans passer par un HTMLENTITIES.
- De ne jamais appeler une page php en redirection ou autre via l'url (évidemment ...)

Ma question est la suivante, y a t-il un risque majeur que j'oublie qui permettrait une intrusion sur un de mes sites ?

Si quelqu'un a une idée, je suis preneur ..

PS:Oups, j'ai posté dans Debutant, je ne suis peut être pas au bon endroit, n'hésitez pas à déplacer si besoin, désolé.

Pour revenir là dessus, est-ce qu'il y en a parmi vous qui font autre chose qui pourrait encore plus sécuriser cette histoire ?

Un petit UP quoi ...

La sécurité c'est compliqué, il y a vraiment plein de failles possibles, et pas forcément que dans ton script PHP.

Mais pour répondre à ta question, disons que normalement oui ton script est sécurisé contre les failles communes (XSS, injections SQL).

Par contre il y a des failles de sécurité plus vicieuses, comme les CSRF (le principe c'est que admettons pour supprimer un article de ton site tu le fasse en GET via l'URL /article.php?mode=delete&id=42, il suffirait que quelqu'un te fasse cliquer - ou lancer - ce lien à ton insu pour supprimer un article). Cet exemple montre que les problèmes de sécurité peuvent aussi tout simplement venir de la conception de ton application.

Quand tu écris

- De ne jamais appeler une page php en redirection ou autre via l'url (évidemment ...)

tu penses aussi aux include() , require() ?

Sinon il faut faire attention au nommage des variables, surtout si tu travailles sur un serveur mutualisé car certains hébergeurs changent parfois la config register_global qui depuis php5 devrait être à off.
Si donc il leur vient à l'idée de mettre register_global sur on, $_SESSION['toto'] sera égale à n'importe qu'elle valeur de toto que tu passeras dans l'URL dans ce cas de figure :

<?php
session_start();

$toto = isset($_GET['toto'])? $_GET['toto'] : null;

$_SESSION['toto'] = isset($_SESSION['toto'])? $_SESSION['toto'] : null;

echo $_SESSION['toto'];
?>

Petite remarque concernant htmlentities() : Si tu envisages de travailler en utf-8, il faudra renseigner obligatoirement le charset de cette fonction... Cela dit dit quand on travaille en utf-8, on a souvent l'habitude d'utiliser htmlspecialchars() (ce qui évite d'avoir à spécifier le charset) à la place de htmlentities(). Cela n'a rien à voir avec la sécurité mais juste pour dire qu'un portage d'un code en ISO... vers utf-8 peut demander pas mal de vérifications/modifications dues (entre autre) à l'utilisation de cette fonction.

Genova:Oui bien sûr que la sécurité c'est compliqué. Mais si tu enlèves les trucs "courants", le gars qui voudra hacker ton site devra y avoir un intérêt, surtout si il doit y passer plusieurs heures/jours. Le but de la sécurité est de décourager un éventuel intrus, vu que le système parfaitement sécurisé n'existe pas.

T'as un lien pour ton histoire de CSRF, ou tu peux développer ?

AB:en parlant de ces histoires d'include() ou de require(), je n'ai pas très bien compris comment on pouvait utiliser ca pour en faire une faille ?

Admettons que j'ai ca dans un index :
Avec donc mon fichier toto.php dans le sous dossier include.

C'est quoi le risque ?

Tel quel, aucun risque, mais parfois pour appeler des pseudo frame ou autre, certains font passer le nom du fichier à inclure par l'URL, ce qui (si on ne vérifie pas les fichiers autorisés) est une faille facilement exploitable. Mais si tu t'es intéressé à la sécurité tu dois la connaître car c'est une des premières choses que l'on apprend.

Par contre les pb que peut induire une config serveur avec register global sur on peuvent être plus sournois (cf exemple plus haut) surtout si l'on teste en local avec register global sur off. D'autant plus que certains hébergeurs mutualisés changent parfois cette config sans nécessairement prévenir.

Ah oui, mais c'est de l'injection url ca ... ^^ ....

Pour les variables globales, j'ai mon propre serveur, donc pas de prob de ce coté.