[PHP] Comment sécuriser son site ?

[theocrite]

Et hop !

Pour ceux d'entre vous qui codent du PHP, que ce soit fréquemment ou de temps en temps, je vous conseille de lire ça : http://blog.sesse.net/blog/tech/2005-11-27...ed_harmful.html

C'est très clair, et ça pointe du doigt les failles de sécurité les plus fréquentes dans les codes PHP

[Helfima]

bon, je donne mon avis sur quelque rêgle a respecter pour minimiser les risques.

ne jamais mettre dans un include une variable diretement passée par l'url

moi j'utilise une variable genre $page puis j'inclu mes fichiers avec un switch qui teste $page

exemple

l'url du navigateur est: http://monsite/index.php?page=accueil

switch($_GET["page"]){

case "accueil":

include(page_pour_mon_accueil.php);

break;

......

default:

echo "erreur : on ne bidouille pas les variables url ca sert a rien, vilain!";

}

deplus en utilisant $_GET on s'assure que c'est bien de l'url que provient la variable

avec une tel méthode personne ne peut utiliser votre fichier pour appeler une autre page que parmis celle du switch et donc tout est prédéfini.

pour des pages avec des droits

moi j'utilise une méthode simple et efficace

dans tous, je dis bien tous les fichiers appeler par la page je teste le niveau de droit et je redirige même pas.

if (!checkaccess("niveau de droit") {

die("acces denied"); //message d'erreur

exit; //arrete du script

}

la fonction checkaccess vérifie la validité des doit d'accès selon le niveau "niveau de droit" requis, elle utilise le login et le password de la session en cours

même parfois dans ma méthode d'analyse de droit j'arrive même à bloquer les droit de webmestre au cours de mes dévellopement et dans 100% cas le déblocage passe par une édition direct dans les bases mysql

dans tout mes scripts je n'affiche jamais rien avant d'avoir fini le traitement de toutes les variables, ce qui permet de faire des redirections ou même stoper le script sans rien dévoilé du contenu de la page.

ah, j'oubliai, lors de l'utilisation de formulaire je vérifie toujours que les variables ont bien été postées avec $_POST["nom de ma variable"]

les variables en $_GET j'évite du fait que ca provient soit de formulaire en methode get ou de l'url.

de toute facon vu que pour les formulaires j'utilise des niveaux de droit je sais à quel niveau de sensibilité je suis et qui plus est j'autorise jamais d'écrire du script ou si je l'autoriserai je le renderai inerte.

[ggbce]

$page=preg_replace("/[^a-z0-9_ ]/i", "", $page);
if(!@include("includes/$page.php")) die("Cette page n'existe pas sur le serveur, merci d'informer le webmaster du site si ce problème venait à se reproduire.");

Si c'est du chinois pour vous, soyez assuré que cette méthode remplira son rôle, quelques explications : Ce mini code inclu votre page en enleveant les caractères spéciaux, les "/" par exemple, et affiche un message d'erreur si votre include échoue, pourquoi est-ce efficace ? Car le piratin a obligatoirement besoin d'utiliser "/" pour taper "http://",

The Lootrophile, je crois qu'utiliser une string implicite tel que http://, ftp:// et https:// pourrait être mieux, car si le include local n'est pas dans le même dossier que la page en question, il ne sera pas possible d'utiliser le "/" pour changer de répertoire !

[Nyro Xeo]

Quel dommage de constater qu'un peu plus d'une année après avoir posté ma remarque, elle n'ait pas été prise en compte :(

Bonne année à tous...

[woodystable]

Il semble que The Lootrophile ne passe plus aussi.

Peut être que quelqu'un devrait reprendre le topic ?

Bonne année à toi aussi

[ano_635206457069767051]

dans un bouquin php il combinait le traitement et le formulaire dans un seul fichier php, avec vérification de validation du bouton submit de la mm page qui permet de controler la provenance...

mais je sais pas si c'est suffisant. pas le temps maintenant mais je peux vous passer son code plus tard ...

C'est facile à faire :)

Dans le action de ton formulaire, il faut mettre action="tapage.php?foo=bar" (foo et bar étant bien sur des trucs bidons hein :))

Qque chose de ce genre là :

<form method="post" action="tapage.php?foo=bar" >
</form>

Dans ton formulaire php , commence avec

<?php
if( isset ($_GET ['foo']) && $_GET['foo'] == 'bar')// si on choppe foo dans l'url et que ce foo est égale à bar
//ton code de traitement
?>

Je sais pas si c'est très sécurisé par contre, mais à priori, je vois pas de problèmes.

[FiP_]

c'est pas déplacé dans le forum création web ça?

[theocrite]

Bonne question.

Les tutos/topics importants sont bien ici je pense plutôt que noyés sous des dizaines de topics CSS / IE qui afiche mal le html, problèmes php.

Ceci dit il peut y être déplacé tout en conservant un lien ici.

L'important étant qu'il reste visible ici, c'est IHMO l'un des plus important topics de la section.

[FiP_]

Merci bien pour ces précisions.

Commentaires:

1. le jaune et le orange ne sont pas très lisibles :(

2. Ca a déja été dit, mais

Comment y remédier ? C'est très simple, et pas très contraignant :

$page=preg_replace("/[^a-z0-9_ ]/i", "", $page);
if(!@include("includes/$page.php")) die("Cette page n'existe pas sur le serveur, merci d'informer le webmaster du site si ce problème venait à se reproduire.");

N'est pas forcement la meilleure solution; sur mon site j'utilise un switch-case:

switch($page)
{
case "blog":
	//afficher le blog
	break;

case "articles":
	//afficher les articles
	break;

default:
	//afficher un message d'erreur

	/* mode vraiment paranoiaque: le script vous envoie un mail contenant
	   la variable $page qui à été envoyée: si c'est une erreur de votre part,
			   vous êtes tout de suite au courant; et si c'est un méchant pirate,
			   et ba.. vous savez ce qu'il a tenté, et quelle est son ip :D */
	break;
}

Ainsi, si qqun tente d'inclure un truc pas prévu, ca ira tout seul sur le traitement suivant "default", chez moi un message d'erreur.

3.

4. La faille XSS ? Ca me donne de l'herpes ! Par The Lootrophile

Comment y remédier ? Il y a un grand nombre de solutions pour pallier à ce problème : Definir votre texte comme étant une HTML, ou empecher l'emplois de "javascript" (ainsi, aucun script javascript ne pourra etre executé), comme suit : $message=str_replace("java script:","",$message)

Là en revanche, un preg_replace pourait convenir :)

ou simplement un $message = htmlspecialchars($message); qui transformera le code javascript en texte simple.

4.

6. La faille urldecode() dans les requetes SQL, par Savory

Oula! Je ne la connaissais pas celle là! J'ai bien fait de venir ^^

Pas bete du tout comme technique, mais il n'y a pas assez de remarques sur sa resolution... :(

5. Ajouts.

- Souvent lorsque l'on dévellope, on se met des moyens de "passer" en mode debbogage, au moyen par exemple d'une variable "$debug" que l'on met à 1 ou à 0.

Attention à ce que l'on laisse dans son site mis en ligne! Une technique parfois instructive est de rajouter "&debug=1" à la fin des url, histoire de voir si le develloppeur n'aurait pas laissé certains trucs.. Et qui sait ce qui peut trainer dans un mod debug! Connection sans mot de passe, affichage de details du code ou de la structure de la base de données.... méfiez vous.

- ne pas afficher les messages d'erreur. Pour une application "en production", afficher les messages d'erreur de php ou de sql pourrait permettre à quelqu'un d'obtenir des informations sur la maniére dont est organisé votre site. Pas véritablement une faille donc, mais aide les méchants :).

Pour ne pas afficher les erreurs, vous pouvez utiliser

error_reporting(0);

... voir: http://fr3.php.net/error-reporting

Pour éviter qu'une fonction en particulier ne raconte sa vie si quelquechose ne va pas, utilisez une arobase:

$fp = @fopen('/home/toto/fichier');

- si un des parametres demandé à l'utilisateur est un nom de fichier sur le serveur, méfiez vous des "../", qui signifient "remonter d'un niveau dans l'arborescence".

utiliser la fonction basedir(); pour les supprimer.

- dans la même optique, devenez paranoiaque et méfiez vous absolument de toutes les variables qui viennent de l'exterieur: si un formulaire attend un chiffre, essayez de saisir "['(-``/!§" dedant pour voir se qui se passe. S'il attend un nombre entier positif, saisissez "-3" :) Essayez de pourrir vos propres entrées pour avoir une idée de la maniére dont réagit votre application.

- Dans la base de données, si vous avez des compte utilisateur, ne notez pas leur mots de passes "en clair":

utilisez la commande md5():

$mdp_chiffre = md5($motdepasse);

Ainsi, quelqu'un accédant au contenu de la table des utilisateurs n'aura pas leur mot de passe pour autant.

:)

Pour vérifier le mot de passe d'un utilisateur, lors de sa connection par exemple, faites:

$a_verifier = md5($ce_qui_a_ete_saisi);

et comparez ce que vous obtenez avec ce qui est stocké dans la base de données.

note: à la place de md5(), vous pouvez utiliser Mcrypt, Mhash, crypt, etc.

- cacher php:

Dans la configuration d'apache, vous pouvez préciser:

# Make PHP code look like other code types
AddType application/x-httpd-php .asp .py .pl

Vous pourrez alors renommer vos applications en ".asp", ".py", etc...

-----------------------------------------------------------------

EDIT:

A ceux qui lisent ce thread dans le but d'apprendre à savoir utiliser les failles de sécurité, passez votre chemin, vous ne trouverez ici aucune information pour vous.

hein? Soit on parle vraiment de failles, et oui ca peut donner des idées a certains, soit on les cache, mais je ne vois pas bien comment ca poura aider a sécuriser un site.. ^^;

Le pirate peut egalement intégrer ses pages malveillantes (comme cela : http://www.votresite.com/?page=http://www.....com/script.php, PS pour les "pirates", cette méthode ne marche pas, n'essayez même pas. ;-)

La aussi, il faudrait savoir... ça marche ou ça ne marche pas?? oO

[.BöD.]

Hello,

Il y a quelque chose a ne surtout pas oublier quand on fait un site c'est de mettre :

Options -Indexes

Dans le .htaccess a la racine du site, ca évite que les petit malins aillent fouiller dans vos répertoires pour chercher la faille...

[The Lootrophile]

Le pirate peut egalement intégrer ses pages malveillantes (comme cela : http://www.votresite.com/?page=http://www.....com/script.php, PS pour les "pirates", cette méthode ne marche pas, n'essayez même pas. ;-)

La aussi, il faudrait savoir... ça marche ou ça ne marche pas?? oO

Ca ne marche pas parce que la personne inclu dans son code une page php, le fichier va etre parsé (interprété) sur le serveur où il est puis inclu à la page qui comporte la faille, il ne sera donc inclu qu'un code html bénin (voir du javascript..)

Le réel danger est d'include un fichier .txt qui ne sera pas interprété sur le serveur distant, mais bien sur le serveur où il y a la faille..

Par exemple : Si j'inclu un fichier php contenant la fonction destroy_tout (fictive, bien sur), sur le site www.jesuisunhackeur.com, la faille se trouve sur le site www.jesuisunevictime.fr

La démarche serait donc du type : http://www.jesuisunevictime.fr/?page=www.j...com/destroy.php

Là, la fonction destroy_tout() va tuer le site du "pirate", car va etre interprétée labas

La démarche du type : http://www.jesuisunevictime.fr/?page=www.j...com/destroy.txt (contenant le meme code que la version php)

Et la fonction destroy_tout() tuera le site comportant la faille.

Pour le reste, je viens de constater que mon topic avait été mis en persistant, je vais lire vos remarques et faire les ajouts et modifications qui s'imposent. =)

[Baldurien]

Grosse remarque :

<? c'est le mal, <?php c'est le bien.

Sur mon serveur la première syntaxe est désactivée, et donc à fortiori le code est visible. Ce qui n'est pas le top.

Donc <?php, parce que c'est portable, et que <? sera désactivé par défaut en php6. (d'autant que <% par à la poubelle)

Autrement, le jaune c'est pas très lisible.

[The Lootrophile]

Grosse remarque :

<? c'est le mal, <?php c'est le bien.

Sur mon serveur la première syntaxe est désactivée, et donc à fortiori le code est visible. Ce qui n'est pas le top.

Donc <?php, parce que c'est portable, et que <? sera désactivé par défaut en php6. (d'autant que <% par à la poubelle)

Autrement, le jaune c'est pas très lisible.

Ca a été rédigé sur l'autre theme anciennement par défaut de ce forum, qui était sombre, je vais remanier le sujet, et tenir compte de tes remarques. J'attends juste une autorisation demandée à un admin avant de faire tout cela.

[Quarky]

Ce topic a été complètement repris pour en refaire un nouveau plus complet. Celui-ci ne sera donc plus mis à jour !

Merci de consulter le nouveau :

 Les failles de sécurité courantes.