Comment empecher les failles de type GET

[niahoo]

Je soutiens Xenos, à mon avis il ne faut pas présumer des intentions de l'utilisateur, car à trop le faire on risque de prendre des erreurs réelles pour des tentatives de hack. Il suffit de correctement se protéger et renvoyer une code d'erreur si les données ne sont pas valides, point barre.

[Akira777]

Ah ben ok, avec cette information, je vais vite foncer sur le forum, m'inscrire, et mettre comme avatar l'image



Bannissement à tous ceux qui afficheront cette image. Si je l'utilise comme avatar, peu de gens m'attaqueront dans le jeu...
C'est une belle faille CSRF.

Pour le abs, d'accord, mais je pense qu'il faudra quand même l'expliciter (commentaire?) dans le code, sinon, cela sera délicat à relire.

Code :

$quantite = abs((int) filter_input(INPUT_POST, 'quantite', FILTER_VALIDATE_INT));
// Negative quantity is not allowed here: abs will switch it to positive,
// so one testing/hacking the interface with negative values will be forced to sell the items

Xenos, tu pars un peu trop vite en besogne

Tout ceci n'empêche en rien de mettre tout ce qui nécessaire en sécurité, si le fait d'avoir mis en place mon petit "easter-egg" (qui n'existe plus d'ailleurs) ouvrait une faille aussi béante je ne l'aurais pas fait.

Soit dit en passant, faire ce que je fais n'ouvre aucun autre débat sur le reste, utiliser un abs() est un très bon moyen en lisant le code de se rappeler la valeur est UNSIGNED. Cette lecture ne me gêne absolument pas.

Mais, je plussoie que par soucis de qualité du code je préfère tout de même cela (enfin un truc du genre) :

Code PHP :

<?php 

filter_var($var, FILTER_VALIDATE_INT, array('options' => array('min_range' => 1, 'max_range' => $item->quantity)); 

[julp]

En fait, avec MySQL ce n'est pas gagné :

•  pas de contrainte CHECK, parce que c'est là, au minimum, qu'il aurait fallu la mettre en place (sinon il faut l'écrire soi-même via un trigger en before insert/update qui lève une erreur)
  

•  si tu mets ta colonne en UNSIGNED, a priori, une valeur négative finit en 0 avec un simple warning (out of range)
  

Au moins, avec PostgreSQL, unsigned n'existe pas et check est implémenté.


Je ne suis vraiment pas convaincu par abs non plus : ça signifie que tu acceptes les valeurs négatives en entrée et que tu te retrouves en sortie avec une valeur positive. Niveau documentation, je pense qu'on a vu mieux. filter_var me paraît bien plus adapté aussi.

[Akira777]

En fait, avec MySQL ce n'est pas gagné :

•  pas de contrainte CHECK, parce que c'est là, au minimum, qu'il aurait fallu la mettre en place (sinon il faut l'écrire soi-même via un trigger en before insert/update qui lève une erreur)
  

•  si tu mets ta colonne en UNSIGNED, a priori, une valeur négative finit en 0 avec un simple warning (out of range)
  

Au moins, avec PostgreSQL, unsigned n'existe pas et check est implémenté.

Je ne suis vraiment pas convaincu par abs non plus : ça signifie que tu acceptes les valeurs négatives en entrée et que tu te retrouves en sortie avec une valeur positive. Niveau documentation, je pense qu'on a vu mieux. filter_var me paraît bien plus adapté aussi.

De toute façon, je n'ai jamais dis que c'était une solution globale satisfaisante, et malheureusement on ne peut pas vraiment dire "accepter les valeurs négatives en entrée". L'utilisateur passera sans difficulté les contrôles HTML et autres joyeusetés javascript.

Tout est question de point de vue. C'est ni forcément une bonne solution, ni une bonne solution. En tout cas, dans tout un tas de cas elle remplie parfaitement son rôle.