Discussion :

[JackBeauregard]

Bonjour,

J'ai presque fini mon forum, alors je repasse sur la sécurité. Vous allez me dire si j'ai pas zappé des trucs, selon ce que vous avez pu voir dans votre expérience.
Les failles serveurs sont pas d'actualité ici, je suis sur un mutualisé, à priori ovh se débrouille.

Voilà tout ce que j'ai pu trouver comme failles et comment j'y ai parré:

- Attaques xss :
Parade : toutes les entrées, y compris les checkbox et les hidden sont filtrées par htmlspecialchars.

- Injection sql :
Parade : Utilisation de mysql_real_escape_string, sur toutes les entrées aussi.

- déclenchement d'erreur sql en changeant la valeur des variables passées en paramètre aux requêtes sql (ex : texte au lieu d'un numéro)
Parade : utilisation des expreg pour tester la nature des valeurs passées en paramètre à des requêtes sql via l'url.

- Modification du message d'un autre utilisateur :
Parade : test de correspondance entre l'id en session du membre qui veut modifier un message et l'id du propriétaire du message.

- Vol de session :
Parade : les sessions ne fonctionne que par cookie il faut donc une attaque xss pour en récupérer la valeur, mais ces attaques ne sont plus possible grace à htmlspecialchars comme dit plus haut. Ou alors le gars va fouiller sur place dans le pc.

- Force brute pour ouvrir un compte :
Parade : test sur IP et blocage au bout de 5 ratage.

- Possibilité de créer des sujets ou de répondre à des messages qui n'existent pas :
Vérification de l'existence des sujets parents afin de ne pas pouvoir entrer un faux id de sujet pour y répondre ensuite et créer des faux posts.

Qu'est-ce que j'ai oublié ?

[berceker united]

Je suis plutot d'avis de faire un test avant contact avec la base.
Par exemple : il y a des mots clé SQL à bannire.
Si le champs attend un int il faut lui donner un int et ne pas laisser le sgbd detecter l'erreur.
Faire une page ou il y a le champs de formulaire et une page qui va recevoir les variables du form et accepter seulement les variables provenant de la page du champs de formulaire.
en base de la page du formulaire
$_SESSION['from'] = $_SERVER['SCRIPT_NAME']

fichier de traitement.
if($_SESSION['from']=='monfichierform.php'){
...
}else echo 'Petit filou va '

[berceker united]

-Eviter les risques d'incohérance entre les valeurs passées en url ou post.
Si une pages attend x parametres alors il faut le controler et donner x parametre.
-Eviter les nom explicite et qui represente le nom des champs SQL. Personnellement je suis en train de mettre en place un systeme pour que les variables passées en parametre get ou post change tous les x temps.

[Eusebius]

contre le vol de session, on peut changer le PHPSESSID à chaque chargement de page, dans un petit script en include.

[berceker united]

haa j'y avais pas pensé mais est ce que php reconnaitra le nouveau nom entre l'ancien et le nouveau pour transférer les valeur de session?

[Eusebius]

haa j'y avais pas pensé mais est ce que php reconnaitra le nouveau nom entre l'ancien et le nouveau pour transférer les valeur de session?

T'inquiète... C'est fait pour

[Pepito2030]

Faire une page ou il y a le champs de formulaire et une page qui va recevoir les variables du form et accepter seulement les variables provenant de la page du champs de formulaire.
en base de la page du formulaire
$_SESSION['from'] = $_SERVER['SCRIPT_NAME']

fichier de traitement.
if($_SESSION['from']=='monfichierform.php'){
...
}else echo 'Petit filou va '

Si les valeurs postées sont directement traitées dans la page formulaire, autant faire un test comme ça, non ?

if($_SERVER['SCRIPT_FILENAME']=='formulaire.php'){
...
}

[berceker united]

En faite, j'ai réflechi à une chose. En faite ce que j'ai décrit ne sert strictement à rien. Il suffit que la personne soit sur la page de la provenance des données, là la variable de session sera affecté à cette page. De là, il peut attaquer le fichier de traitement de ses fichiers vu que ce dernier va voir que la variable de session est bonne puisqu'il a ouvert. De plus si cette personne n'es pas malhonnete. il ouvre un nouvelle onglet et se trouve dans une autre page de la même application il ne pourra pas poster puisque le from ne sera valide.

[Pepito2030]

Je ne connais pas toutes les techniques de sécurité, mais est ce que ce code :

if($_SERVER['SCRIPT_FILENAME']=='formulaire.php'){
...
}

sert a quelque chose ? vous allez me dire que oui, mais est t'il VRAIMENT utile ? Cela permet ainsi d'etre sure que le formulaire envoyé provient bien de la page d'origine.

Je suis moi aussi en train de coder mon forum. La base est prete, reste plus qu'à le sécuriser un minimum... heu je veux dire un maximum.

Déjà, je ne vais autoriser que les membres à y accéder (sauf la page d'index ).

[berceker united]

Normalement oui si le fichier de traitement est le même que le fichier de formulaire. Pour mon cas, je sépare les deux. Un fichier de formulaire envoy les données dans un fichier de traitement.

[JackBeauregard]

En faite, j'ai réflechi à une chose. En faite ce que j'ai décrit ne sert strictement à rien. Il suffit que la personne soit sur la page de la provenance des données, là la variable de session sera affecté à cette page. De là, il peut attaquer le fichier de traitement de ses fichiers vu que ce dernier va voir que la variable de session est bonne puisqu'il a ouvert. De plus si cette personne n'es pas malhonnete. il ouvre un nouvelle onglet et se trouve dans une autre page de la même application il ne pourra pas poster puisque le from ne sera valide.

Bonjour,

Alors donc j'allais m'atteler à ce problème qui consiste à vérifier que la page de provenance des informations du formulaire est bien celle que l'on attend et j'apprend, ô surprise, que ça ne fonctionnerait point ?
Mais comment cela-ce puisse-t'il être ?
Perso je récupère l'url de la page dans une variable (pour une histoire d'historique des pages visitées). Pour ce faire je la reconstruis, puisqu'il y a un url-rewriting.

Qu'est-ce qui m'empêcherait de vérifier sur la page de réception que les informations proviennent bien de la page que j'attend ?
Mettons j'ai sur la page d'envoie, la variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 $page="categorie-$url.php"

et je test sur la page de réception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ( $_GET[page] == $pageAttendu).

Vous me direz pour la passer, soit c'est dans le form en hidden, donc c'est facile de piger l'astuce, soit c'est en session et que ça passe par cookie c'est fastoche aussi.
Donc c'est bidon cette technique ou j'ai raté un épisode ?

[berceker united]

Tu as soulevé le problème. Si tu envoys les données via champs caché ou parametre effectivement c'est une porte ouverte. Je pense que le seul moyen c'est de configurer le serveur pour ne pas accepter des variables venant de l'exterieur. Personnellement, je ne sais pas comment est-ce possible mais c'est une piste. Autre piste voir si php peut lire le header et voir s'il y a l'information de la provenance de la page. Sauf que celle prévus par le protocole http car un firewall d'un client peut zaper l'envoy de cette information.

[David.Schris]

Bonsoir,

Vous me direz pour la passer, soit c'est dans le form en hidden, donc c'est facile de piger l'astuce, soit c'est en session et que ça passe par cookie c'est fastoche aussi.
Donc c'est bidon cette technique ou j'ai raté un épisode ?

Franchement ? Sans méchanceté aucune, je crois que tu as raté un épisode...mais j'ai peut-être mal compris ta première (dans la citation) phrase et pensé à tort que tu avais mal compris ce qu'étaient les variables de session.
Quand je lis "soit c'est en session et que ça passe par cookie", j'ai envie de dire "Stop ! Justement ! Si c'est dans une variable de session, ce n'est pas dans un cookie : c'est tout l'intérêt". D'ailleurs, si c'était pareil : pourquoi y aurait-il un tableau $_SESSION et un tableau $_COOKIE ? Hein ? Pourquoi ?
Fais l'expérience : crée un script qui initialise une session, stocke une longue chaîne de caractères dans une variable de session quand cette variable n'existe pas et affiche la chaîne quand la variable existe (et affiche dans tous les cas un lien qui pointe vers lui-même) ; dirige ton brouteur vers l'URL du script en question, clique deux ou trois fois sur le lien qui est affiché (la longue chaîne doit s'afficher à partir du permir clic) et regarde ce qui est stocké dans le cookie qui a pu être créé à l'occasion. Que vois-tu ? La longue chaîne stockée dans la variable de session ? Non : seulement l'identifiant de la session. La longue chaîne stockée dans la variable de session est, elle...sur le serveur. D'où, comme je l'écrivais plus haut, l'intérêt : un utilisateur indélicat pourra toujours tripoter ses cookies [1], il ne pourra pas modifier le contenu de la variable de session (sauf, bien sûr, si il est admin. du serveur).
Conclusion : les sessions c'est pas bidon.

À David.Schris :
J'ai retrouvé la page sur le site d'où venait mon erreur en parlant de certificat non valide.

Après l'étape où il crée le certificat, on peut y lire cette phrase à la fin de la page.

Lien : Apache 2.0.x / Windows - MOD SSL

C'est seulement pour ajouter où j'avais lu l'information.

Merci pour le retour d'info (ça c'est du SAV ! ).
Par contre, la citation sortie de son contexte et prise à la lettre peut prêter à confusion.
Son contexte : un article/tutoriel qui introduit l'utilisation de mod_ssl sous Windows mais ne parle ni des certificats clients, ni de la possibilité d'installer le certificat du serveur sur les clients.
Pour le côté "à la lettre", je pense au mot "valide"...qui peut avoir plusieurs sens/interprétations [2] : strictement techniquement parlant, le certificat généré dans l'exemple EST valide. Sinon, la manipulation décrite ne fonctionnerait pas.
Peut-on "en vouloir" à l'auteur de l'article ? A mon avis, non. Le but de cet article n'est pas de rentrer dans les détails et on ne peut pas reprocher à son auteur d'avoir voulu résumer le pourquoi de l'avertissement affiché par le navigateur sans expliquer tous les détails du fonctionnement de SSL et dans quels cas on pouvait utiliser (ou pas) un certificat qu'on a nous-même signé.
Bref, quand tu écris "la page sur le site d'où venait mon erreur", j'ai envie de répondre : "Ton erreur, petit scarabée [3], ne vient pas de la page ni du site. Elle vient principalement du fait que tu as oublié de replacer cette phrase dans son contexte".
Bon, fini la morale ! Au lit !

Très cordialement,
DS.

[1] - Pervers : s'abstenir.
[2] - En général, est-ce que "pas valide" veut dire "ayant un format non valide" ? "dont la date d'expiration n'est pas valide" ? "qui n'a pas été certifié par un tiers de confiance dont le certificat est préinstallé avec les navigateurs du marché" ? Et bien, en général : on ne peut pas savoir ce que cela veut précisément dire. C'est pourquoi il ne faut pas généraliser...et replacer les choses dans leur contexte en étant aussi précis que possible.
[3] - A prendre avec le sourire : ce n'est pas condescendant.