Zend FR

Delprog · 09-06-2009 13:57:27

Bonjour,

Question de sécurité

Les sites sont souvent victimes d'injection javascript.
Récemment j'ai eu le problème sur un vieux site de la société (html + ASP) dont je n'ai pas la charge. Un script malveillant est systématiquement injecté sur l'index. Un evalscript() sur des caractères encodés.

Les clients sont infectés par un trojan lorsqu'ils visitent le site.

Sauf qu'habituellement les injections se font à travers les formulaires. Or, sur cette page, aucun formulaire, je ne sais pas comment procède le hackeur. Quoi qu'il en soit il utilise forcément des paramètres dans l'url.

Résultat, comme je suis en charge de la nouvelle plateforme web, je migre le site vers une nouvelle version développée avec Zend Framework, sur un nouveau serveur php dédié.

J'ai rarement été confronté à ce genre de problème et je ne sais pas trop comment réagir et me protéger sur le nouveau site.

Comment se protéger contre ça ? Est-ce que ZF le fait nativement (objet "request" ?) ?

Merci pour votre aide,

A+ benjamin.

philippe · 09-06-2009 15:33:48

Bonjour,

Le ZF ne va pas te protéger contre ça, il ne le peut pas (l'objet $request ne fait rien à ce niveau). L'idée générale est de vérifier la validité de tous les paramètre que tu peux recevoir en entrée d'une page :
- les paramètres reçus en GET ou en POST
- les cookies
- les paramètres reçus directement dans l'URL

Si certains paramètres peuvent être envoyés à toutes les pages (langue, message d'erreur, url de redirection,...) il faut les valider de façon systématique dans un plugin.

Il n'y a pas de réponse toute faite : à chaque fois que tu as un paramètre, il faut regarder ce qu'il devient dans ton appli et vérifier qu'il ne peut pas faire de dégat pour ton serveur ou pour les autres internautes. Les 2 points capitaux à surveiller sont :
- les cross site scripting (ou XSS) : envoi de JS à tes internautes (ce que tu as décrit). Zend_Filter_StripTags peut t'aider pour les paramètres à risque (c'est à dire une donnée envoyée par un internaute, puis lue pas d'autres internautes. Typiquement un message de forum...)
- les injections SQL : un formulaire de login mal fait pourrait permettre à un internaute d'exécuter la requête SQL qu'il souhaite sur ta base... A priori Zend_Db et PDO te protègent bien contre les injections SQL, mais il faut bien comprendre les mécanismes... un $db->query("...") peut sans problème laisser passer une injection SQL quand même...

Il y a d'autres failles possibles, mais ce sont de loin les 2 pires....

A+, Philippe

Dernière modification par philippe (09-06-2009 15:36:19)

Delprog · 09-06-2009 15:48:02

Donc, le hackeur ne peut utiliser que les variables que j'utilise moi ?

En l'occurrence sur la page d'accueil du nouveau site les seuls paramètres que je reçois dans l'objet "request" sont le module, controller et l'action.

Je dois donc faire un plugin pour échapper et nettoyer ces paramètres au moment du routage ?

Dans mon cas, le script malveillant est injecté directement dans la balise <head> du site, ce qui est assez bizarre.
Une balise <script>evalscript()</script> qui est ré-injectée régulièrement.

Merci.

A+ benjamin.

Dernière modification par Delprog (09-06-2009 15:49:37)

philippe · 09-06-2009 16:31:39

Hum... j'ose espérer que les modules, controlleurs et actions sont déjà vérifiés par le ZF (je n'ai jamais regardé). Dans tous les cas je pense que tu n'affiches pas ces variables sur les pages de ton site, donc on ne peut pas a priori faire de XSS avec ces variables.

Sinon oui, un pirate ne peut utiliser que les variables que tu reçois toi (mais attention on ne pense pas toujours à tout, un pirate peut modifier aussi ses cookies, son user-agent, ses languages acceptés,...).

Dans le cas du site à problème, il suffit qu'un des paramètres envoyés dans l'URL ou à travers un formulaire soit inséré sans filtre dans le header et l'internaute peut injecter une chaîne qui :
- referme la balise courante
- ouvre une balise script
- met le code javascript qu'il souhaite dans la balise script

Après une fois qu'il injecte du javascript, "il est maître du monde" : il peut provoquer des rechargement réguliers, faire des requêtes où il veut, envoyer le cookie de session à l'adresse qu'il souhaite (donc les internautes peuvent se faire voler leur session...)... Javascript c'est super puissant dans un navigateur...

A+, Philippe
PS : c'est pas parce que je suis parano qu'ils ne sont pas tous contre moi...

Delprog · 09-06-2009 16:40:55

Hum on sent comme un vécu et une petite frustration dans tes mots

Tu connaitrais pas un article (un bon) qui explique comment se protéger correctement contre tout ça ?

Parce que tu donnes des exemples, comme le "user_agent", c'est vrai qu'on y pense pas, du coup il faudrait vérifier un bon paquet de variables dans les plugin, ça fait un peu peur.

S'il existe un site qui répertorie l'ensemble des possibilités connues que les hackeurs utilisent pour injecter du JS ce serait pas mal

Après je veux bien me faire un plugin qui contrôle tout ça.

Mais à priori, si j'ai bien compris, si les scripts sont présents dans les variables mais que je n'utilise pas ces dernières je ne risque rien.
Je dois nettoyer que celles que je vais traiter/afficher/utiliser ?

Merci pour ton aide en tous cas ! :p

A+ benjamin.

philippe · 09-06-2009 16:48:12

Désolé, je n'ai pas de site en tête.

Sinon effectivement si tu n'utilises pas la variable, aucun risque (c'est déjà ça de pris ).

Une petite frustration ? noooon... mais avec 10ans d'expérience dans le web et une bonne dose de parano, je pense que dans un projet raisonnablement gros, on continue à trouver des trous dans mes codes

A+, Philippe

Julien · 09-06-2009 19:02:23

Il est prévu dans ZF2 d'ajouter du filtrage dans l'objet de requête directement, qui est la seule porte d'entrée dans le script (si on ne touche pas à $_GET|POST etc...). C'est un des intérêts de MVC.

Il faut valider toute entrée, et échapper toute sortie. Oui, même $_SERVER est une entrée, la plupart des paramètres proviennent de HTTP. Forgez une requête HTTP avec Telnet et vous verrez. Il faut donc valider les paramètres get, post, cookie et server; ceci peut être fait directement en jouant avec l'objet de requête MVC et en le redéfinissant.

PHP5.2 possède une extension "filter", qui peut filtrer $_GET|POST (ou autre) avant même leur entrée dans le script PHP ( paramètres du php.ini ), c'est très efficace.

Mod_Security de Apache sait aussi parfaitement filtrer les entrées avant de les passer aux gestionnaires (handlers, dont PHP fait partie), au prix d'une baisse de performance globale (à mesurer).

Cherchez sur cgisecurity.org ou encore ha.ckers.org ; vous trouverez tout ce qu'il faut mais globalement il faut impérativement se dire que l'utilisateur de l'application n'est ni plus ni moins qu'un client HTTP, un gentil internaute sous son navigateur fétiche, une application Web faisant office de client (service Web), un téléphone mobile, une console de jeu, ou encore un pirate sous Telnet (ou autre outils). Boite noire contre boite noire, ya pas de secret, c'est HTTP.

vg33 · 09-06-2009 19:50:59

Pour juste compléter les propos de Julien :
Il faut valider toute entrée, échapper tout enregistrement en bdd, et échapper toute donnée utilisateur envoyée à la vue.

sekaijin · 09-06-2009 20:54:12

il ne faut jamais remettre dans la pages des éléments reçus sans les avoir traités.

j'ajoute qu'il faut réduire au maximum les éléments qui sont transmis dans le header et dans les urls

Si certains paramètres peuvent être envoyés à toutes les pages (langue, message d'erreur, url de redirection,...) il faut les valider de façon systématique dans un plugin.

Il faut les supprimer ça ne sert à rien d'envoyer systématiquement des valeur que le serveur peut conserver de sont côté. la langue ne doit être transmise au serveur que si elle change. elle doit l'être sous une forme qui n'est pas cette que le serveur utilise en interne. (ce qui oblige à la traiter pour la comprendre.)

ne conserver dans le dialogue avec le client que ce qui est strictement nécessaire. le reste doit être systématiquement éradiqué.

A+JYT

Delprog · 10-06-2009 13:21:02

Merci pour tous ces conseils.

Je me rend compte que j'appliquais déjà pas mal de choses instinctivement

Vos précisions vont me permettre de renforcer encore plus la sécurité.

A+ benjamin.

Zend FR

#1 09-06-2009 13:57:27

Zend & injection script malveillant javascript

#2 09-06-2009 15:33:48

Re: Zend & injection script malveillant javascript

#3 09-06-2009 15:48:02

Re: Zend & injection script malveillant javascript

#4 09-06-2009 16:31:39

Re: Zend & injection script malveillant javascript

#5 09-06-2009 16:40:55

Re: Zend & injection script malveillant javascript

#6 09-06-2009 16:48:12

Re: Zend & injection script malveillant javascript

#7 09-06-2009 19:02:23

Re: Zend & injection script malveillant javascript

#8 09-06-2009 19:50:59

Re: Zend & injection script malveillant javascript

#9 09-06-2009 20:54:12

Re: Zend & injection script malveillant javascript

#10 10-06-2009 13:21:02

Re: Zend & injection script malveillant javascript

Pied de page des forums