Jouons avec $_GET – Partie 2 : #jeudiconfession n°4

Jouons avec $_GET – Partie 2 : #jeudiconfession n°4

Rappel

Je vous invite à lire la partie 1 de la semaine dernière : Jouons avec $_GET – Partie 1. Nous avions parlé sécurité et pus précisément de la faille XSS. Cette semaine, même problème de code, mais une autre faille sera présente : SQL Injection.

On y va

Une fois de plus, dites moi si ça vous choque :

On pourrait se dire « Oui ! Une faille XSS ! Protégeons avec un esc_machin() ou esc_truc() je ne sais plus. » mmmmoké en fait non. Ce genre de protection ici n’en est pas une. Unitule, vrament, évitez, vous pourriez croire qu’une protection est en place, mais c’est faux.

Voici la démo d’un exploit : ?/foo=-1%20or%201=1 ou celui-ci /?foo=-1%20UNION%20ALL%20SELECT%20*%20FROM%20wp_users%20WHERE%20user_login=%27admin%27

La 1ère URL lance la requête citée plus haut, mais au lieu de récupérer un seul article, cela récupère TOUS les articles puisque « or 1=1 » est toujours vrai. C’est donc la fameuse faille « SQL Injection », on injecte du code qui sera traité dans la requête. #bad
La seconde URL remplace les résultats par les informations du compte « admin » (si votre préfixe est « wp_ », vous avez compris pourquoi il faut la changer ? ;p )

Comment régler ça ?

La façon WordPress :

Vous DEVEZ préparer vos requêtes avec un prepare(), préparer ses requêtes est le meilleur moyen de se protéger contre les attaques SQL Injection.

La façon PHP :

N’utilisez pas la fonction esc_sql() en pensant que cela suffit, ni même htmlentities(). Des exploits sont encore possible avec ces fausses protections …

Outro

Cet article se nomme une fois de plus « $_GET » mais cela fonctionne avec « $_POST », « $_REQUEST », « $_COOKIE' », « $_SERVER » etc etc Même une donnée sortant de la base de données, et même si elle a été désinfectée AVANT son insertion, une fois en sortie, rien ne vous affirme qu’elle a pas été modifiée par autre chose 😉 #parano

Vous aimez ? Partagez !


Réagir à cet article

220 caractères maximum