Discussion :

[Eylun]

Bonjour, bonjour !

Alors en attendant des réponses à mon premier sujet concernant les tchats (ça serait vraiment gentil de m'aider :'(), je suis également à la recherche d'une idée simple et efficace à la fois pour pouvoir sécuriser au mieux ses scripts PHP.

Par exemple, sur nos sites, on a parfois besoin de créer des scripts qui ont une tâche précise (prenons par exemple le cas d'un script qui aurait pour but de calculer des statistiques). Ce genre de script n'affiche rien de spécial, il s'occupe juste de la tâche qu'il a à faire.

Comment les sécuriser ?

J'ai tenté en vérifiant la validité des variables envoyées par exemple, genre si elles existent, si elles sont sous la bonne forme, etc etc. Mais j'ai l'impression que cela ne suffit pas.

J'ai également créé un script que j'ai appelé "securite_url", qui en gros prend l'url de la page courante et vérifie si la personne a bien le droit d'être là. Par exemple, si un gars tente d'écrire style "http://lesite.com/connexion.php", le script aura une condition qui dira "si url = connexion.php, redirige la personne vers telle page".

J'ai même mis des fichiers index dans mes sous-dossiers avec des codes de redirection dedans.

Comme je ne suis pas experte en sécurité web, je me demandais quelle serait une méthode plus ou moins fiable pour protéger ses scripts ? Est-ce que je m'y prends de la bonne façon ? Ou est-ce qu'il y a un moyen plus simple et plus efficace ?

De même, le moindre de mes formulaires, je vérifie également chaque variable envoyée, avec des coups tordus pas possibles, et j'utilise un maximum de requêtes préparées pour le SQL.

Voilà, voilà, si vous avez des méthodes plus efficace, je suis preneuse !

Merci d'avance En espérant avoir des réponses à mes sujets ^^ (je vois qu'on répond à d'autres, alors pourquoi pas moi aussi ? xD)

[grunk]

Bonjour,

Ce genre de script n'affiche rien de spécial, il s'occupe juste de la tâche qu'il a à faire

Si il n'a pas besoin d'être joint via une url , il suffit de ne pas le mettre dans la racine web. De fait, seul tes scripts pourront l'inclure et l'utiliser mais il ne pourra jamais être appeler autrement.

Pour te donner un exemple sur mes applications , il n'ya qu'un seul fichier accessible c'est index.php qui en fonction des url va charger les bons scripts.
Toutes les autres classes sont dans des dossiers non accessibles via une url et donc par conséquent non executable. C'est comme ca que fonctionne tous les framework.

je vérifie également chaque variable envoyée, avec des coups tordus pas possibles

y'a pas de coup tordu possible , il existe des filtres pour ce genre de chose.
intval() si c'est un entier
floatval() si c'est un float
filter_var pour tous le reste : http://php.net/manual/fr/function.filter-var.php

Une fois que la variable est filtrée il faut juste vérifier qu'elle correspond bien à ce qu'on attends avant de l'utiliser.

[Eylun]

Merci de votre réponse

Alors quand je parle de "coups tordus", je fais en fait référence à "je tente de me mettre à la place d'un c****** qui cherche à me planter mon site", donc en cherchant la moindre "petite bête" qui pourrait faire planter mes systèmes.

Par exemple, il m'est arrivée genre au moins 5 fois sur l'ancienne version de mon site que des gens s'inscrivaient...en mettant un espace à la fin de leur pseudo, avant de se plaindre qu'ils ne parvenaient pas à se connecter sur la zone de connexion (forcément puisque du coup, le système ne voit pas les deux pseudos de la même façon). Que pour ça, j'ai du faire une condition stupide visant à vérifier le dernier caractère des pseudos que l'on peut entrer dans le champ "pseudo" de mon formulaire d'inscription...c'est véridique ! Personnellement, je n'ai jamais compris l'intérêt d'une telle pratique, mais bon.

Concernant les variables, vous m'apprenez quelque chose avec int_val et tout, sinon, pour votre dernière phrase, c'est ce que je fais. Mes scripts "exécutables" sont dans un dossier spécifique, mais rien n'empêche par exemple l'utilisateur d'écrire dans son url : http://lesite.com/dossier/ pour avoir accès aux fichiers.

C'est pour ça que je demande : si dans ce cas, j'ajoute dans ce fameux dossier un fichier index.php qui redirige là où je le souhaite, est-ce fiable ou pas du tout ? Y'a-t-il d'autres façons de protéger ses dossiers ?

Voilà en gros ^^ Cela m'intéresse pas mal parce que je bosse en ce moment sur la toute nouvelle version de mon site, et j'aimerai bien "bien" le faire, au maximum ^^

[grunk]

Merci de votre réponse
Par exemple, il m'est arrivée genre au moins 5 fois sur l'ancienne version de mon site que des gens s'inscrivaient...en mettant un espace à la fin de leur pseudo, avant de se plaindre qu'ils ne parvenaient pas à se connecter sur la zone de connexion (forcément puisque du coup, le système ne voit pas les deux pseudos de la même façon). Que pour ça, j'ai du faire une condition stupide visant à vérifier le dernier caractère des pseudos que l'on peut entrer dans le champ "pseudo" de mon formulaire d'inscription

La fonction trim() est là pour ça, par exemple :

Code :

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

$login = filter_var(trim($_POST['login']), FILTER_SANITIZE_STRING,FILTER_FLAG_NO_ENCODE_QUOTES);

Mes scripts "exécutables" sont dans un dossier spécifique, mais rien n'empêche par exemple l'utilisateur d'écrire dans son url : http://lesite.com/dossier/ pour avoir accès aux fichiers.

Ca c'est un problème. C'est ce que je t'ai dit dans mon message précédent , tu dois mettre ces script dans un dossier qui n'est pas accessible via le navigateur et ne garder que certains script (idéalement un seul) qui va aller inclure ces scripts quand il en a besoin.
Sur un hébergement mutualisé classique , tu as en général le dossier "www" qui est accessible depuis le web , mais rien ne t'empèche de créer des dossiers au même niveau que www (pas à l’intérieur donc) qui eux ne seront jamais accessible via un navigateur.

Après l'idéal reste quand même de passer par un framework un peu réputé qui va gérer la plus part de ces problématiques de sécurité "basique" à ta place. Par contre ca implique une phase d'apprentissage importante et un niveau en développement déjà un minimum avancé

[nektarfl]

Tu peux aussi tester la page qui envoie à ta routine php

Code :

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

 if ($_SERVER['HTTP_REFERER']="http://tonurl.com/index.php")

Si ça ne correspond pas, c'est que l'appel a été tenté d'ailleurs, c'est ensuite à toi de voir si tu donnes des valeurs erronées pour tromper la tentative, ou si ton site devient totalement silencieux

[ABCIWEB]

Concernant les formulaires il y a deux problèmes distincts :

1/ Savoir si le script php reçoit bien des données en provenance du formulaire.
2/ Vérifier dans la mesure du possible que les données reçues correspondent au format attendu dans les limites attendues.

1/ La solution qu'indique grunk de mettre tous les fichiers php qui peuvent l'être - c.a.d ceux qui sont inclus en php - dans des répertoires situés en dehors du répertoire www, - est déjà un premier niveau de sécurité puisque seules des pages php en provenance de ton site pourront appeler ces fichiers php. Mais cela ne lie pas automatiquement les formulaires et leur script de traitement puisque le script pourra être exécuté depuis n'importe quelle page du site donc depuis n'importe quel formulaire du site par exemple.

Pour lier un formulaire et son script php de traitement, il y a les token. Renseignes-toi si tu ne connais pas car c'est relativement simple à mettre en place et assez efficace. Je dis "assez efficace" car dans tous les cas il restera la possibilité de simuler une navigation sur ton site mais le pirate sera obligé de respecter la liaison entre le formulaire et le script php... tout en sachant qu'il pourra rajouter des champs dans le formulaire.

2/ Donc en complément du token, le script php ne doit rapatrier que les variables strictement nécessaires et contrôlées le plus possible. On évitera d'utiliser des fonctions comme extract, et l'on utilisera des requêtes préparées pour insérer les valeurs en bdd, et l'on oubliera pas de protéger l'affichage des données, etc.

Et on utilisera https le plus possible puisque c'est disponible aujourd'hui gratuitement y compris pour les mutualisés entrée de gamme (même si c'est moins secure que les certificats individualisés), surtout si le site dispose d'une interface de mise à jour pour sécuriser l'authentification.

Faut pas mal de temps et d'expérience pour faire "le tour" de la question. L'oswap référence le top 10 des risques les plus courants (potentiellement catastrophiques) et donc des principales erreurs à ne pas commettre et ils vont jusqu'à 25 (dans le premier lien) si tu veux plus d'informations sur le sujet.

Si tu tiens à tout coder par toi-même cela va te faire de la lecture. Mais bon quitte à passer beaucoup de temps sur ces questions (pas toujours évidentes à comprendre) il y a aussi la possibilité d'utiliser un framework comme disait grunk. Cela dit, en commençant par des choses simples on peut limiter la casse mais si tu veux développer plus rapidement des choses plus compliquées et potentiellement risquées c'est une bonne solution à envisager. Après d'un point de vue général, c'est mieux de connaître à peu près bien la liste des 10 plus gros risques et jeter un oeil sur les suivants, même si on laisse au framework le soin de traiter le problème*.

* Plus les framework te laissent de liberté (ex: micro framework), moins ils font de taff à ta place, mais plus ils sont simples à apprendre (le bon compromis n'est pas toujours facile à trouver, choisir aussi en fonction du support disponible sur le web ...).