Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

PROTECTION CONTRE FAILLE XSS


Information sur le tutorial

Catégorie :Astuces Date de création : 02/05/2006 18:40:17 Vu : 11 618 fois

Note :
7 / 10 - par 1 personne
7,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

Commentaire sur cette source (11)
Ajouter un commentaire et/ou une note

Description

Voici une faille, assez simple a utiliser, donc courament utilisée ... la faille XSS. Ce tutorial est fait a titre d'information, et non de hacking. C'est plutot étudier la faille, pour pouvoir se proteger ...

Tutorial

Lorsqu'en javascript certaines variables sont mal protégées, et son directement mise dans l'url, il est donc possible d'injecter du code arbitraire.Par exemple imaginons un script pour afficher une page :

<?php
[...]
print("page : $page");
[...]
?>

Si le nom de la page est hack me.htm cela donnera :

http://site_vulnerable.com/?page=hack%20me

Le hacker peut donc envoyer n'importe quel code via l'url grace a la faille XSS :

http://site_vulnerable.com/?page=<script>alert("alph4net");</script>

Ce qui aura pour effet de faire apparaitre une boite de dialogue avec ecrit alph4net
dedans, et la, au cas ou vous ne l'auriez pas vu, il y a une faille, c'est une faille
XSS non-permanente

Maintenant pour securiser tous ca, a chaque fois que vous utilisez les fonctions
echo et print() pour afficher une variable faite ceci :

<?
print(htmlspecialchars($variable));
?>

ou

<?
echo htmlspecialchars($variable);
?>

Au lieu de ca:

<?
print($variable);
?>

ou

<?
echo ($variable);
?>

Voila, je le répète, c'est a titre d'information, c'est pour que les personnes qui créer des script php, les sécurisent au Max. Certain (meme beaucoup) connaissent cette faille, mais il n'y a pas que des ingénieurs sur ce site ... ;)

 

 

signaler à un administrateur
Commentaire de igratuit le 05/05/2006 16:44:55

Sympa ...

signaler à un administrateur
Commentaire de FhX le 05/05/2006 20:00:05

Pour sécuriser les variables par $_GET (donc les vars via URL) :
Suffit de parser $_GET[] et de récupérer que ce qu'on a besoin.

La protection des variables se fait pendant la récupération de la-dite variable... pas au moment de faire un echo() :)

signaler à un administrateur
Commentaire de DJ_BoOmEr le 07/05/2006 08:43:09

Salut a tous, et merci pour vos commentaire 0_o (loool)

C'est tres motivant je doit dire de se faire planter meme quand on essaye d'aider d'autre T_T ...

FHX si tu lis bien il parle de quand tu fais quelque chose avec echo ou print, donc pour afficher les variables, il faut séciriser avec "htmlspecialchars". M'enfin bon ... Je sais pas cec que je fous sur ce site vu qu'a chaque fois que je post une source ou un tuto, je me fait planter ... :/

signaler à un administrateur
Commentaire de Anthomicro le 11/05/2006 21:49:10

Salut,

en même temps FhX a raison...

Concernant ça, tu fais un htmlentities de l'url décodée, ça le fait mieux car ça t'affiche tout.

Il vaut mieux quand on a des messages à afficher passer par un chiffre et afficher un message en fonction de ce chiffre.

signaler à un administrateur
Commentaire de arsworld le 21/08/2006 21:36:36

Merci pour cette info :)
simple et d'une grande aide.

signaler à un administrateur
Commentaire de kankrelune le 08/11/2006 15:30:54

Je ne suis pas du tout d'accord avec ce que dit FhX... les données doivent être traitées au besoin et non pas dès la réception... imaginons par exemple un livre d'or avec base de données... on récupère les données on échappe les caractères pour l'insertion en base, on insert les données puis on affiche le message après l'avoir passé dans htmlentities... si on suit ton raisonement FhX il faudrait insérer le code passé dans htmlentities dans la base de données et affiché le code avec les quotes et autre échappé ce qui est plutot inutile... une attaque XSS ne concerne que des données qui sont affichées inutile donc de faire du traitement dès la reception ce dernier doit être fait au moment de l'affichage... .. .

// on receptionne les données
// on insert en bdd en prenant soin de traiter les données (mysql_real_escape_string())
// on affiche le text après un passage dans htmlspecialchars ou htmlentities

@ tchaOo°

ps : pour une fois que je suis pas d'accord avec FhX... il va pleuvoir... .. . :oD

signaler à un administrateur
Commentaire de RaphAstronome le 13/08/2007 13:52:07

Oui mais on affiche bien plus souvent les données qu'on ne les ajoute/modifie.
C'est bien moins coûteux de faire les htmlspecialchars, les conversions de BB code, les smileys une fois et les intégrer dans la base de donnés que de les traiter à chaque fois.
Je joue à un jeu PHP (Kraland) au début il faisait la transition BB code -> HTML à chaque affichage maintenant qu'il le traite avant leur serveur est plus rapide.
Le gros problème par contre c'est qu'il faut faire la traduction inverse HTML -> BB code si on édite et c'est assez dur à programmer.

signaler à un administrateur
Commentaire de willeraser le 06/08/2008 23:27:30

foreach ($_GET as $key => $val)
{  $_GET[$key] = preg_replace("/[^_A-Za-z0-9-\.&=]/i",'', $val); }  

et

foreach ($_POST as $key => $val)
{  $_POST[$key] = preg_replace("/[^_A-Za-z0-9-\.&=]/i",'', $val); }  

Au moins, pas de soucis :)
Néanmoins, la regex peut s'avérer très, voire beaucoup trop restrictive. Ensuite, suffit de personnaliser le masque.

signaler à un administrateur
Commentaire de kankrelune le 07/08/2008 00:18:12

@ RaphAstronome... tout dépend de tes besoins mais d'une manière générale traiter à l'affichage tes données est préférable car c'est plus souple mais tout dépend des besoins de ton site/appli... la perte que tu as dans le traitement à l'extraction tu peux la compenser avec un bon système de cache... .. .

@ willeraser... je ne comprend pas bien l'utilité de ton code... hormis utiliser des expressions régulières pour rien ça n'a pas grande utilité autant traiter les entrée dans GET et POST une à une en fonction de ce qu'elle sont censé contenir et en imaginant que tu passe un preg_* sur chaque index tu aura au moins économisé une boucle... .. .

Pourquoi chercher des lettres dans une valeur numérique... de toute façon il me faudra une valeur numérique et de manipuler un int donc, sauf cas particulier, autant le caster ($maval = (int)$maval;) comme ça pas de soucis...

Pourquoi ne pourrait il pas y avoir des caractères comme le # dans une donnée soumise en POST ou en GET... un commentaire d'article par exemple... puisque dans ton expression régulière tu vire tout ce qui n'est pas alphanumérique ou un _-.& et =...

Bref mieux vaut travailler sur chaque donnée séparément plutôt que d'économiser quelques lignes de code autant pour les perf que pour la sécurisation de son code... .. . :o)

@ tchaOo°

signaler à un administrateur
Commentaire de kankrelune le 07/08/2008 00:22:37

Et filtrer les globales $_GET et $_POST c'est bien mais il ne faut pas oublier de filtrer la globale $_COOKIE... si on l'utilise bien entendu... .. . ;o)

@ tchaOo°

signaler à un administrateur
Commentaire de legerf le 15/08/2008 12:22:58

La question du débutant : Si sur un formulaire (method="POST"), j'ai des champs de saisie (exemple : adresse d'un client) et si je peux déterminer pour chaque champs une expression régulière qui élimine les caractères inutiles ou dangeureux (comme # " ' ...) alors je supprime tout risque de SQL Injection ?
Evidemment pour des champs à structure plus complexe (comme ce commentaire) cela ne fonctionne pas avec cette seule règle.

Ajouter un commentaire



Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Comparez les prix Nouvelle version

Photothèque Nouveau !



Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,094 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.