Vaste sujet...
Alors, tout d'abord, pour éviter un maximum d'erreur, il faut développer en affichant toutes les erreurs PHP (ini_set('display_errors', '1'); et ini_set('error_reporting', '-1');) et si tu vois des NOTICE PHP, il faut les corriger.
Ensuite, avant même de regarder les bugs directement liés aux fonctions de PHP, il faut absolument verrouiller ton flux de données entrant et sortant.
Exemple : tu as un script qui récupère un paramètre 'toto' dans l'URL.
- Comment réagit ton script si ce paramètre n'est pas présent ?
- Comment réagit ton script si ce paramètre est une chaine de caractère alors que toi tu attendais un chiffre ? (ou l'inverse ?)
- Si le paramètre peut et doit prendre seulement X valeurs possibles, testes tu bien que ce paramètre fait bien partie des valeurs que tu attendais ?
- Si tu affiches le contenu de ce paramètre dans ta page, utilises tu bien htmlentities (faille XSS) ?
- Si tu utilises ce paramètre pour faire une requête SQL, utilises tu bien mysql_real_escape_string (injection SQL) ?
Ensuite, il te faut vérifier la cohérence des actions de ton site.
Exemple : tu as un espace membre, et une page permettant à un membre de modifier son profil.
- Vérifies tu bien que tu as un membre logué pour effectuer cette action ?
- En manipulant les données GET ou POST, est ce qu'un membre peut agir sur le profil d'un autre membre ?
En vérifiant ce strict minimum, tu éviteras pas mal de pièges.
Après, dans le même contexte, en poussant le vice un peu plus loin, tu as les failles de type CSRF.
Exemple : tu as un espace membre, et une page permettant à un membre de supprimer son compte grâce à l'URL : http://site.com/del.php
- Un site tiers place alors dans son code html une image du genre : <img src="http://site.com/del.php" />
- Un de tes membres va sur ton site, il est donc logué sur ton site (grâce aux sessions)
- Ce membre va ensuite sur ce "site piège"
- Comme le membre est toujours logué sur ton site (les sessions n'expirent pas quand le membre change l'URL de son navigateur sauf si il clic sur un lien "déconnexion"), ce membre fera le hit sur ton URL de suppression de compte, et son compte sera supprimé sans qu'il s'en aperçoive.
Pour fixer ce genre de problème, tu peux utiliser un paramètre "spécial" qui te permettra de vérifier l'action de l'utilisateur.
- Tu initialises en session un paramètre qui prendra une valeur aléatoire (tu peux utiliser la fonction uniqid par exemple) lorsque la personne arrive sur la page où l'action de suppression de compte est faisable via un clic de souris.
- Ensuite, si l'action de suppression se fait via un lien, tu mettras en plus dans l'URL un paramètre du genre 'check' qui prendra la valeur de ton paramètre de session (si tu utilises un formulaire, utilise un champ hidden).
- Enfin, dans la page del.php, tu vérifieras non seulement que la valeur existe en session, mais aussi que le paramètre 'check' (en GET ou en POST) existe également, et enfin tu regarderas si ces deux valeurs sont identiques. Si oui, alors tu pourras lancer l'action de suppression.
etc, etc, etc...
Bref, la sécurité est un très vaste sujet qu'il ne faut pas prendre à la légère, et cela demande un vrai travail qui peut sembler long et fastidieux, mais c'est ce qui fait qu'un développeur sera considéré comme bon.
Faire un script "qui marche" c'est bien, mais faire un script "qui marche" et qui gère tous les cas de figure possible, c'est mieux.
