Discussion :

[Stéphane le calme]

PHP : Imperva recommande l'élimination des paramètres superglobaux des requêtes,
« une menace à la sécurité du Web » pour l'entreprise

La compagnie américaine de sécurité Imperva a publié son rapport « PHP SuperGlobals: Supersized Trouble » dans lequel elle présente une analyse approfondie des attaques contre les applications PHP dont celles qui impliquaient des paramètres superglobaux. Étant donné que PHP est, pour la compagnie, la plateforme de développement d’applications web la plus répandue (l’entreprise estime que 80 % des sites l’utilisent parmi lesquels Facebook ou Wikipédia) l’importance accordée à la résolution des problèmes liés à la sécurité de PHP est capitale.

« Parce que les hôtes compromis peuvent être utilisés comme esclaves botnets pour attaquer d’autres serveurs, les exploits contre les applications PHP peuvent affecter la sécurité générale et la bonne santé de tout le Web » explique Amichai Shulman, Directeur de la Technologie chez Imperva.

Le rapport signale que les pirates développent au fil du temps de simples scripts avec des degrés de sophistication plus élevés, et identifient les paramètres superglobaux de PHP comme leur entrée favorite, qui leur octroie un retour sur investissement des plus élevés. Au sein de la communauté des pirates ils gagnent en popularité à cause des nombreux problèmes de sécurité (CVE-2011-2505, CVE-2010-3065 par exemple) qu’ils intègrent et permettent ainsi aux hackers de briser la logique d’une application et compromettre un serveur, ce qui peut entraîner le vol de données ou des transactions frauduleuses.

D’ailleurs, en un mois, l'équipe de recherche d'Imperva a noté une moyenne de 144 attaques par application qui contenaient des vecteurs d'attaque liés à des paramètres superglobaux. En outre, les chercheurs ont assisté à des campagnes d'attaque d'une durée de plus de cinq mois avec des salves d’inondations de requêtes atteignant les 90 coups par minute sur une seule application.

L’une des recommandations du rapport est de bloquer les paramètres superglobaux au niveau des requêtes. Pour eux rien n’explique leur présence à ce niveau et ils doivent donc être bannis.

Source : rapport (au format PDF)

Et vous ?

Qu'en pensez-vous ?

[transgohan]

J'en ai lu une partie mais il y a des failles que je ne comprends pas...
"4.1 External Variable Modification Attack - CVE-2011-2505"
Je ne vois pas pourquoi on garderai les données puisqu'on écrase $_SESSION après le parse_str. Et encore moins comment on garderai les données d'une session à une autre avec le session_destroy().
Quelqu'un pour m'expliquer ?

[rawsrc]

Bon j'ai lu en diagonale mais si le mec utilise parse_str() pour analyser l'url : il ne peut que s'en prendre qu'à lui-même aussi ^^

• Pour parser une URL : c'est parse_url() qui est prévu à cet effet et on extrait et valide manuellement les paramètres (query), les clés inattendues doivent être supprimées
• Ensuite on ne laisse jamais le moteur PHP créer tout seul des variables à partir des données utilisateur : JAMAIS : donc pas de extract() ni de parse_str()
• On n'utilise jamais $GLOBALS, ce n'est uniquement présent que pour la déco...
• Et le pompon c'est se plaindre d'un problème de sécurité alors que dans le code on fait appel à la chouette fonction : eval()

Concernant la sérialisation des classes : il vaut mieux l'éviter dans la mesure du possible et la remplacer par la sérialisation d'un tableau de paramétrage d'une classe qui sera injecté à la création de la nouvelle instance.

C'est un bon rappel pour les débutants mais quand on a un peu de bouteille c'est enfoncer des portes ouvertes en prenant même beaucoup d'élan, je trouve

[albesoft]

C'est bien joli mais...
comment récupérer les données d'un formulaire qui utilise la méthode "POST" autrement qu'en allant les rechercher dans la superglobale $_POST ?

Il y a longtemps que register_globals est désactivée par défaut et qu'on n'utilise plus $_REQUEST qui avait l'avantage/inconvénient (tout dépend de ce que l'on voulait faire) de "mélanger" $_POST et $_GET !

Quant aux sessions, elles sont, en principe, logées sur le serveur, dans des répertoires protégés par un .htaccess et donc non accessibles (quoique chez certains hébergeurs, le dossier nommé "sessions" doit se trouver directement sous le répertoire racine du site... )

En bref, respectez l'adage "ne jamais faire confiance aux données fournies par l'utilisateur", vérifiez vos formulaires avec un bon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

onsubmit="return verif();"

avant de soumettre la requête et, côté "action", vérifiez à nouveau l'existence et le contenu de chacun des champs attendus.

Pour terminer avec PHP, plus exactement avec PDO : cet objet est censé assurer la sécurité des requêtes paramétrées en utilisant, lors du lien paramètre->variable, les constantes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PDO::PARAM_STR, PDO::PARAM_INT

etc.

Eh bien, sachez que la vérification de type est "plus que légère", donc ne comptez pas dessus.
Comme quoi, la critique est facile mais l'art est difficile (autre proverbe connu)

Allez, faites-vous plaisir quand même avec PHP

[Jormund]

Si je peux me permettre, Albesoft, un peu de JavaScript ne "sécurise" rien.
Valider un formulaire en JS aide un utilisateur bienveillant mais ne dérange pas un hacker. Contre eux c'est côté serveur qu'il faut valider toute information qui vient de l'extérieur.