Parer la faille d'include avec solution dynamique

Marsh Posté le 18-04-2007 à 23:35:08

Bonjour,
le bous de code ci dessous à pour objectif d'éviter la traditionnelle faille "d'include".

Code :

<?
$pagesDir = 'pages/';
$pagesExt = '.php';
$default = 'index';
$opValide = array();
$extLen = strlen($pagesExt);
if(empty($_GET['op'])) $_GET['op'] = $default;
$dir = opendir($pagesDir);
while($file = readdir($dir))
if(is_file($pagesDir.$file)
&& strtolower(substr($file,-$extLen,$extLen)) == $pagesExt )
$opValide[] = substr($file,0,-$extLen);
if(in_array($_GET['op'],$opValide) && !preg_match('@\.php@',$_SERVER['REQUEST_URI']))
require($pagesDir.$_GET['op'].$pagesExt);
else
header('location: 404.html');
?>

Habituellement je fais le test sur un tableau définit en dur mais de projet en projets je commence à en avoir un peu ras le bol. Ceci dit, avant d'utiliser ça, j'aimerais tout de même avoir quelques avis sur l'aspect sécurité d'une pareille méthode. Et est-ce optimisable? Je pense notamment à glob() : ça vaut le coup?

J'en profite pour poser quelques autres questions :

Cette ligne : !preg_match('@\.php@',$_SERVER['REQUEST_URI']) me sert à éviter qu'un visiteur puisse accéder au pages directement en tapant les noms des script php puisque j'utilise de l'url rewriting. Est-ce convenable?
Quand on veut simuler correctement une erreur 404 avec page d'erreur personnalisée, à quel moment doit-on renvoyer l'erreur 404 dans l'entête http? Avant la redirection vers la page d'erreur? Sur la page d'erreur? Les deux?

En vous remerciant.

Message édité par dwogsi le 18-04-2007 à 23:39:03

---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/

Reply

Marsh Posté le 18-04-2007 à 23:35:08

Reply

Marsh Posté le 19-04-2007 à 03:14:08

c'est une solution...
mais ça fais de l'access en lecture sur le fs plus ou moins important celon la taille de ton repertoire a chaque page demandée... c'est forcement moins optimisé qu'en dur...

2) il me semble que c'est avant.
tu peux aussi changer les pages d'erreur dans la configuration d'apache

Message cité 1 fois

---------------
Blog photo/récits activités en montagne http://planetcaravan.net

Reply

Marsh Posté le 19-04-2007 à 05:19:57

Bah we la tu fais pleins de test, tu m etonnes que c'est securisee.

Code :

if(!is_file($_GET['op'].$pageExt)){
header(..)
}

Ca aurait suffit non ?

Ah pour le rewriting, t as les conditions qui font ce que tu vx tres bien. Je sais pas si ca vaut le coup de rajouter ce traitement dans le script PHP. Perso je le fais pas, je reste sur les $_REQUEST et ci avec php pas plus.

We le preg_match tu px le remplacer par un strpos.

Sinon ok pour la liste des pages a inclure

Le 404 c est dans la doc php

Message cité 1 fois
Message édité par supermofo le 19-04-2007 à 05:28:25

Reply

Marsh Posté le 19-04-2007 à 11:59:05

zecrazytux a écrit :

c'est une solution...
mais ça fais de l'access en lecture sur le fs plus ou moins important celon la taille de ton repertoire a chaque page demandée... c'est forcement moins optimisé qu'en dur...

Oui c'est aussi ce que je me disais, d'ailleurs je m'attendais bien à une remarque du genre donc je vais enregistrer la liste en dur mais en la générant dynamiquement. Comme ça je me fais pas trop chier en appelant simplement mon script de re-génération de la liste quand j'ajoute des pages.

supermofo a écrit :

Bah we la tu fais pleins de test, tu m etonnes que c'est securisee.

Franchement je préfère en faire trop que pas assez. une faille sur un include ça fait trop mal.

supermofo a écrit :

Code :

if(!is_file($_GET['op'].$pageExt)){
header(..)
}

Ca aurait suffit non ?

Oui effectivement c'est plus logique. Enfin... Pourquoi une négation sur la condition?
J'y vois plutôt sans la négation et avec un exit ou un break histoire pas aller plus loin inutilement.

supermofo a écrit :

Ah pour le rewriting, t as les conditions qui font ce que tu vx tres bien. Je sais pas si ca vaut le coup de rajouter ce traitement dans le script PHP. Perso je le fais pas, je reste sur les $_REQUEST et ci avec php pas plus.

Tu veux dire que je peux configurer apache pour générer des 404 en cas d'accès via les .php? Dans ce cas je savais pas et je vais étudier la question. Quelques indications?

supermofo a écrit :

We le preg_match tu px le remplacer par un strpos.

Oui tiens c'est pas bête ça.

supermofo a écrit :

Le 404 c est dans la doc php

Tout ce que je vois dans la doc php (http://fr.php.net/header) concernant les erreurs 404 et qui pourrait m'intéresser ça donne ça :

Citation :

l y a deux en-têtes spéciaux. Le premier commence par la chaîne "HTTP/" (insensible à la casse), qui est utilisée pour signifier le statut HTTP à envoyer. Par exemple, si vous avez configuré Apache pour utiliser les scripts PHP pour gérer les requêtes vers des fichiers inexistants (en utilisant la directive ErrorDocument), vous voulez-vous assurer que le script génère un code statut correct.

Donc ça reste un peu incomplet à mon goût.

---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/

Reply

Marsh Posté le 19-04-2007 à 13:33:08

[quotemsg=1544949,4,219001]
Tu veux dire que je peux configurer apache pour générer des 404 en cas d'accès via les .php? Dans ce cas je savais pas et je vais étudier la question. Quelques indications?

Oui tiens c'est pas bête ça.[/quote]

bien sur

tu fait une regle de url rewriting qui redirige les document ma-page-html.html vers une page index.php?page=ma-page-html mais tu peux aussi faire l'inverse:
tu redirige les fichier *.php vers 403.html

ça obligze les gens a passer par les urls réécrites. par contre du coup, plus aucun acces vers un fichier .php n'est possible (forum, etc, t'est dans la merde )

---------------
Blog photo/récits activités en montagne http://planetcaravan.net

Reply

Marsh Posté le 24-04-2007 à 04:06:15

on peut pas autoriser les .php d'un répertoire particulier (forum) puis rediriger tous les .php vers le 403.html ?

---------------
oui oui

Reply

Marsh Posté le 24-04-2007 à 11:23:29

ah c'est peut etre bien possible... j'ai pas fouillé le rewriting aussi profondément... tu as certainement des options d'exceptions...

---------------
Blog photo/récits activités en montagne http://planetcaravan.net

Reply

Marsh Posté le 24-04-2007 à 12:16:25

en fait, il me semble (je ne connais pas bien en fait ) que les lignes sont lues jusqu'à un match et la suite est niée.

donc s'il y a des règles genre :

si tu vois /forum/*.php tu laisses passer
si c'est un *.php -> 403

si c'est ok pour la première ligne, il va s'arrêter là, donc on pourra voir les .php
sinon, il lit la ligne suivante et bloque alors les .php

(à confirmer )

Message cité 1 fois
Message édité par art_dupond le 24-04-2007 à 12:16:58

---------------
oui oui

Reply

Marsh Posté le 24-04-2007 à 14:17:08

sinon un htaccess dans le sous dossier "forum" avec rewrite engine off et c'est fini, pas d'url rewriting dans "forum" et ses sous-dossiers ...

Reply

Marsh Posté le 24-04-2007 à 14:32:37

en fait ouai carrément plus simple

---------------
Blog photo/récits activités en montagne http://planetcaravan.net

Reply

Marsh Posté le 24-04-2007 à 14:32:37

Reply

Marsh Posté le 24-04-2007 à 17:08:30

art_dupond a écrit :

si c'est ok pour la première ligne, il va s'arrêter là, donc on pourra voir les .php
sinon, il lit la ligne suivante et bloque alors les .php

(à confirmer )

Ca se configure dans les options pour chaque règle.

RewriteRule [Masque] [Destination] [Option]

Avec un N ou un L comme option (je sais plus laquelle correspond à ce que tu veux faire mais c'est une des deux).

NewsletTux a écrit :

sinon un htaccess dans le sous dossier "forum" avec rewrite engine off et c'est fini, pas d'url rewriting dans "forum" et ses sous-dossiers ...

Ca reste quand même la solution la plus simple.

Message édité par dwogsi le 24-04-2007 à 17:09:03

---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/

Reply

Parer la faille d'include avec solution dynamique

Sujets relatifs:

Leave a Replay