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

[JackBeauregard]

Je suis plutot d'avis de faire un test avant contact avec la base.
Par exemple : il y a des mots clé SQL à bannire.

C'est très bon, je vais approfondir la chose. Un problème qui me vient comme ça : si le script se connecte pas, ça va bugger dans la page et le message d'erreur va donner des informations au pirate. Il faut donc que j'initialise une variable qui interdise aux require de la page d'être effectué, via un if (encore des conditions de plus, j'ai peur que ça surchage, mais trois if ne devrait pas changer grand chose).

Si le champs attend un int il faut lui donner un int et ne pas laisser le sgbd detecter l'erreur.

Je vais voir pour le faire là où c'est possible et en tout cas je vais forcer un masque pour les variables $_GET[].

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 '

ça c'est bon aussi, mais je me demande si ce que je fais déjà n'est pas suffisant :
Je test à chaque fois si il y a au moins une variable de session genre

Code :

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

if(isset($_SESSION['numeroConnexion']))

Le gars peut-il encore se connecter et alors utiliser un formulaire bidon situé ailleurs que sur mon site ?

Eviter les nom explicite et qui represente le nom des champs SQL.

Je m'étais déjà dis ça, j'ai même lu un post sur le sujet ici, et les gars disait c'est pas grave...

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

J'ai lu pas mal de post ici même où ils disent que l'on peut compareur deux valeur de session : une dans l'url et un en cookie (ou les deux en cookie peut être) : si un gars chope la session, il n'a pas l'autre numéro situé chez le client, dans le cookie : la comparaison foire ==> les deux sont déconnecté (bon là j'abrège, mais c'était ça l'idée).

D'autres ruses de sioux ? A part s'attaquer à la base par injection sql, tenter une attaque xss, pirater une session ou tout ce que j'ai dit plus haut, que peut faire le gars ?
Pas grand chose de plus je pense, hormis attaquer le serveur. Après ce sont les méthodes pour faire ces attaques qui diffèrent, c'est ça ?

[berceker united]

Là c'est pas du piratage ou presque mais éviter les multipostes. C'est à dire qu'apres avoir envoyé un post la personne ne puisse pas faire un F5 et injecter encore le même post. Il faut une page intermédiaire.
Page1(saisie du post)=>Page2(enregistrement des données+ verrouillage)=>Page3(liste des postes+plus possible de revalider le meme post via precedent).

De cette manière tu peux aussi contrôler l'origine des pages via l'exemple du $_SESSION['from']=$_SERVER['SCRIPT_NAME'] .

[JackBeauregard]

Je suis plutot d'avis de faire un test avant contact avec la base.
Par exemple : il y a des mots clé SQL à bannire.

Quelques exemples seraient fort intéressants, je pense.

[berceker united]

Tous simplement en utilisant la fonction is_int, is_boolean, ...
Doc
Ainsi vous verrez si le type est retourné correspond au type attendu.

- Caché le maximum d'info concernant la base de données. Exemple : ne pas indiqué le nom des champs dans l'url si vous gérez l'affichage d'une liste sujet par exemple . ex: ?champs=idsujet&sens=ASC
- Faire passer dans l'url le nom du fichier à inclure et oui j'ai déjà vu cela.
ex: ?file=toto.php
- Poser des sortes de sonde qui indique s'il y a tentative de manipulation. Par exemple s'il y a plusieurs requete sur une page d'identification venant de la même personne c'est qu'il y a une tentative de penetration. Alert mail voir SMS (oui oui c'est possible et plus facile que vous le pensez) ainsi si c'est possible vous pouvez agire.
- Si quelqu'un tente d'accéder a votre zone admin laissez le rentrer au bout de la 30eme fois.

[berceker united]

Chelou! personne à réagi à ma derniere suggestion !

[JackBeauregard]

Bah je suis passé sur autre chose et ce post m'est complètement sortie de la tête. Tu fais bien de le faire remonter berceker united.

Alors, où en étions nous :

Tous simplement en utilisant la fonction is_int, is_boolean, ...
Doc
Ainsi vous verrez si le type est retourné correspond au type attendu.

C'est plus léger qu'une expreg, mais sans doute moins fiable non ? Ex : j'attend un chiffre dans mon url, tu penses pas qu'une expreg n'est pas plus fiable qu'un test sur le type attendu ?

Caché le maximum d'info concernant la base de données. Exemple : ne pas indiqué le nom des champs dans l'url si vous gérez l'affichage d'une liste sujet par exemple . ex: ?champs=idsujet&sens=ASC

Bon ça en ce qui me concerne c'est trop tard, j'avais posé une fois la question sur un forum et on m'avait dit "pas la peine", alors maintenant je rechange pas tout, tant pis.

Poser des sortes de sonde qui indique s'il y a tentative de manipulation. Par exemple s'il y a plusieurs requete sur une page d'identification venant de la même personne c'est qu'il y a une tentative de penetration.

Bah là j'ai fait un système de blocage par ip. Mais en effet je vais faire un truc pour être averti des tentatives douteuses, comme par exemple si un membre envoit des faux paramètres dans l'url, alors je le met sous surveillance.

Alert mail voir SMS (oui oui c'est possible et plus facile que vous le pensez)

Si tu peux en toucher deux mots, sur le sms, juste par curiosité...

Si quelqu'un tente d'accéder a votre zone admin laissez le rentrer au bout de la 30eme fois.

Alors là je pige pas ce que tu veux dire, s'il tente d'accéder à l'admin, il est pas question de le laisser rentrer du tout de toute façon.

[berceker united]

haa enfin quelqu'un qui réagie sur le dernier élément . En faite j'ai pas tout dit. Effectivement, si quelqu'un tente desespérement de rentrer dans la zone et que c'est un bon il va peut être réussir. Le but c'est de le laisser rentrer en lui faisant croire qu'il est dans la zone admin. En faite ce n'est qu'un faux quelque formulaire pensant qu'il y a la configuration du site les login des utilisateurs etc... Entre temps son attaque à cessé le temps d'être prevenu et réagire. Bien souvent les hackers son satisfait d'être rentré le reste il s'amuse et laisse tomber. C'est comme un chat ils aiment jouer avec leur victime "vivante" apres il le lache .
J'en parle en connaissance de cause suite à une attaque. Le piège a fonctionner plusieurs fois et du coup nous avons eu deux équipe. L'un pour la fausse zone admin et une pour la vrai. La premiere équipe avait pour but de rendre crédible la fausse admin et croyez moi ils avaient des idées énormes.

[JackBeauregard]

C'est à creuser, maintenant comment tu fais pour savoir si le gars doit être redirigé sur un faux formulaire ?
comment le script va faire la différence ?

Parce que le gars à loupé 5 fois ? Mais s'il a les codes parce qu'il a sniffé le réseau ?

Le mieux c'est encore https, non ?

[berceker united]

sur force brute. Comme je l'ai dit s'il y a 50 fois la même requete venant de la même personne identifié par divers critères.

[berceker united]

Je conseille un excellent article concernant la sécurité qui se trouve sur le site de directionphp. Article datant de 02/2006 article gratuit.

[Maxoo]

Je conseille un excellent article concernant la sécurité qui se trouve sur le site de directionphp. Article datant de 02/2006 article gratuit.

tu peux passer un lien sur cette article ?

[berceker united]

Poka Yoké
Alors je précise qu'il faut avoir un bon niveau en php pour bien comprendre les subtilités.

[balu]

Pour la section d'administration, elle pourrait ne pas être sur le serveur du site et être accessible uniquement par un serveur local.

Ça peut être intéressant si le but n'est pas d'y accéder par l'extérieur, non?

[JackBeauregard]

Ah ça c'est pas mal, mais en cas de déplacement ou en cas d'urgence chez un ami, impossible sans avoir une admin en ligne. Ceci dit c'est possible de se faire une admin en ligne sans s'en servir sauf à l'occasion. Ce serait bien le diable qu'une connexion à celle-ci soit sniffée juste à ce moment là.
Et le gars ne risque-t'il pas de pirater directement le pc ?