03-06-2015, 11:21 PM
(Modification du message : 03-06-2015, 11:23 PM par Akira777.
Raison de la modification: fooootes
)
Difficile de passer après Xenos, c'est exactement ça !
Pour apporter une petite touche vis à vis de PHP en particulier :
- Toujours protéger les liens effectuant des actions avec un jeton unique à chaque session utilisateur. Genre: index.php?page=equipement&action=supprimer&id=5 (ou via POST c'est pareil) peut-être utilisé de manière vilaine. C'est la base du CSRF.
- Quand on utilise un CMS (coucou WordPress), bien faire gaffe à le garder à jour et bien faire gaffe aux plugins / thème qu'on y installe.
- De préférence, toujours utiliser des requêtes préparées lors d'une interaction avec la SGBD.
- Sur les pages lourdes, genre génération d'un classement de joueur, bien veiller à ce qu'il ne soit pas généré à la demande, mais mis dans un système de cache (même à durée courte). Afin d'éviter les pinioufs qui vont l'ouvrir dans 150 onglets et saturer le serveur.
- Faire attention aux scripts qui redimensionnent les images à la volée via l'URL. Genre : index.php?image=avatar.jpg&width=150&height=150. Bien effectuer un max de contrôle dans ce genre de cas, ou bien définir des scénarios précis (Genre: index.php?image=avatar.jpg&size=thumb qui correspondrait à 150x150).
Ca évite encore une fois les péquenauds qui vont tenter de générer 13 millions d'images en testant 13 millions de combinaison de tailles différentes et ainsi saturer l'espace disque (en plus du CPU quand utilisation de GD par exemple).
- Surtout bien hasher les passwords. Xenos l'a dit mais je le répète parce que j'en ai marre de voir des pass en clair en BDD.
- Ne jamais laisser le listing des répertoires, on sait jamais... Genre l'accès direct à /includes/classes/ devrait afficher un forbidden et pas un listing de fichier.
Bon, de part leur organisations, peu de frameworks modernes rendent ça possible vu que le code est en dehors du root.
- En plus des requêtes, faire gaffe avec les en-têtes de la fonction mail(). Quand on laisse un message ou sujet libre dans un formulaire de contact, ça peut faire des dégâts si mal protégé.
- Garder ses plugins à jours, genre CKFinder, gestionnaire de fichiers en tout genre, scripts d'uploads, ... Et SURTOUT, ne jamais déployer ces scripts en laissant les fichiers d'examples de ces mêmes scripts. Ils sont souvent utilisés, une requête Google bien placé permet de savoir le numéro de version de l'outil et de trouver si ces fichiers d'exemple existent. Ca peut FAIRE DE GROS DEGATS.
Euh... Je crois que c'est tout pour le moment.
Pour apporter une petite touche vis à vis de PHP en particulier :
- Toujours protéger les liens effectuant des actions avec un jeton unique à chaque session utilisateur. Genre: index.php?page=equipement&action=supprimer&id=5 (ou via POST c'est pareil) peut-être utilisé de manière vilaine. C'est la base du CSRF.
- Quand on utilise un CMS (coucou WordPress), bien faire gaffe à le garder à jour et bien faire gaffe aux plugins / thème qu'on y installe.
- De préférence, toujours utiliser des requêtes préparées lors d'une interaction avec la SGBD.
- Sur les pages lourdes, genre génération d'un classement de joueur, bien veiller à ce qu'il ne soit pas généré à la demande, mais mis dans un système de cache (même à durée courte). Afin d'éviter les pinioufs qui vont l'ouvrir dans 150 onglets et saturer le serveur.
- Faire attention aux scripts qui redimensionnent les images à la volée via l'URL. Genre : index.php?image=avatar.jpg&width=150&height=150. Bien effectuer un max de contrôle dans ce genre de cas, ou bien définir des scénarios précis (Genre: index.php?image=avatar.jpg&size=thumb qui correspondrait à 150x150).
Ca évite encore une fois les péquenauds qui vont tenter de générer 13 millions d'images en testant 13 millions de combinaison de tailles différentes et ainsi saturer l'espace disque (en plus du CPU quand utilisation de GD par exemple).
- Surtout bien hasher les passwords. Xenos l'a dit mais je le répète parce que j'en ai marre de voir des pass en clair en BDD.
- Ne jamais laisser le listing des répertoires, on sait jamais... Genre l'accès direct à /includes/classes/ devrait afficher un forbidden et pas un listing de fichier.
Bon, de part leur organisations, peu de frameworks modernes rendent ça possible vu que le code est en dehors du root.
- En plus des requêtes, faire gaffe avec les en-têtes de la fonction mail(). Quand on laisse un message ou sujet libre dans un formulaire de contact, ça peut faire des dégâts si mal protégé.
- Garder ses plugins à jours, genre CKFinder, gestionnaire de fichiers en tout genre, scripts d'uploads, ... Et SURTOUT, ne jamais déployer ces scripts en laissant les fichiers d'examples de ces mêmes scripts. Ils sont souvent utilisés, une requête Google bien placé permet de savoir le numéro de version de l'outil et de trouver si ces fichiers d'exemple existent. Ca peut FAIRE DE GROS DEGATS.
Euh... Je crois que c'est tout pour le moment.