Bonjour, je me pose la question suivante : est-il préférable de vérifier le
contenu des variables GET ?
Actuellement je fais une vérification logique (présence ou pas si ce
paramètre est indispensable, puisqu'en général je m'arrange pour que la non
présence ne retourne que des "pas d'enregistrements trouvés")
Par contre je me demande se qui se passe si un petit malin tente de saisir
manuellement dans l'url des valeurs excessivements longues, par exemple :
&rub_id=121323131213213232132131321313123132321321321 (sur deux kilomètres)
Y a-t-il un risque de débordement ? Lors des affectations ? Voire lors de
l'utilisation de ces valeurs dans une requête SQL ?
Bonjour, je me pose la question suivante : est-il préférable de vérifier le contenu des variables GET ? ...
Y a-t-il un risque de débordement ? Lors des affectations ? Voire lors de l'utilisation de ces valeurs dans une requête SQL ?
la taille des url est limitée soit par php ou apache et aussi selon un standard je suppose a 4Ko environ.
et php ne deborde pas avec des strings de 4ko.
Frederic BISSON
Bonjour, je me pose la question suivante : est-il préférable de vérifier le contenu des variables GET ? Oui, il faut toujours vérifier ce que l'on t'envoie (que ce soit en _POST
ou en _GET d'ailleurs) ou s'assurer qu'une valeur farfelue ne pourra jamais faire planter ton code.
Par contre je me demande se qui se passe si un petit malin tente de saisir manuellement dans l'url des valeurs excessivements longues, par exemple : &rub_id1323131213213232132131321313123132321321321 (sur deux kilomètres) La plupart des navigateurs ont une limite en ce qui concerne la longueur
maximum d'une URL (paramètres GET compris) qui se trouve à 2083 pour Internet Explorer.
Y a-t-il un risque de débordement ? Lors des affectations ? Voire lors de l'utilisation de ces valeurs dans une requête SQL ? Et si oui, comment se défendre ? La longueur ne peut pas être infinie :
- ton serveur web (Apache ou autre) possède une limite - la plupart des installations PHP ont également une limite en ce qui concerne l'espace mémoire consommé par un script (8 Mo généralement). Tout débordement entraîne la fin immédiate du script
Pour des valeurs plus raisonnables mais totalement dénuées de sens (exemple : 2000 caractères pour une recherche), il existe la fonction strlen qui t'indiquera la taille d'une chaîne. A toi ensuite de mettre des limites (128 caractères par exemple).
@+
Frédéric
Bonjour, je me pose la question suivante : est-il préférable de vérifier le
contenu des variables GET ?
Oui, il faut toujours vérifier ce que l'on t'envoie (que ce soit en _POST
ou en _GET d'ailleurs) ou s'assurer qu'une valeur farfelue ne pourra
jamais faire planter ton code.
Par contre je me demande se qui se passe si un petit malin tente de
saisir manuellement dans l'url des valeurs excessivements longues, par
exemple :
&rub_id1323131213213232132131321313123132321321321 (sur deux
kilomètres)
La plupart des navigateurs ont une limite en ce qui concerne la longueur
maximum d'une URL (paramètres GET compris) qui se trouve à 2083 pour
Internet Explorer.
Y a-t-il un risque de débordement ? Lors des affectations ? Voire lors
de l'utilisation de ces valeurs dans une requête SQL ?
Et si oui, comment se défendre ?
La longueur ne peut pas être infinie :
- ton serveur web (Apache ou autre) possède une limite
- la plupart des installations PHP ont également une limite en ce qui
concerne l'espace mémoire consommé par un script (8 Mo généralement).
Tout débordement entraîne la fin immédiate du script
Pour des valeurs plus raisonnables mais totalement dénuées de sens
(exemple : 2000 caractères pour une recherche), il existe la fonction
strlen qui t'indiquera la taille d'une chaîne. A toi ensuite de mettre
des limites (128 caractères par exemple).
Bonjour, je me pose la question suivante : est-il préférable de vérifier le contenu des variables GET ? Oui, il faut toujours vérifier ce que l'on t'envoie (que ce soit en _POST
ou en _GET d'ailleurs) ou s'assurer qu'une valeur farfelue ne pourra jamais faire planter ton code.
Par contre je me demande se qui se passe si un petit malin tente de saisir manuellement dans l'url des valeurs excessivements longues, par exemple : &rub_id1323131213213232132131321313123132321321321 (sur deux kilomètres) La plupart des navigateurs ont une limite en ce qui concerne la longueur
maximum d'une URL (paramètres GET compris) qui se trouve à 2083 pour Internet Explorer.
Y a-t-il un risque de débordement ? Lors des affectations ? Voire lors de l'utilisation de ces valeurs dans une requête SQL ? Et si oui, comment se défendre ? La longueur ne peut pas être infinie :
- ton serveur web (Apache ou autre) possède une limite - la plupart des installations PHP ont également une limite en ce qui concerne l'espace mémoire consommé par un script (8 Mo généralement). Tout débordement entraîne la fin immédiate du script
Pour des valeurs plus raisonnables mais totalement dénuées de sens (exemple : 2000 caractères pour une recherche), il existe la fonction strlen qui t'indiquera la taille d'une chaîne. A toi ensuite de mettre des limites (128 caractères par exemple).
@+
Frédéric
nospam
Zouplaz wrote:
Bonjour, je me pose la question suivante : est-il préférable de vérifier le contenu des variables GET ?
Actuellement je fais une vérification logique (présence ou pas si ce paramètre est indispensable, puisqu'en général je m'arrange pour que la non présence ne retourne que des "pas d'enregistrements trouvés")
Par contre je me demande se qui se passe si un petit malin tente de saisir manuellement dans l'url des valeurs excessivements longues, par exemple :
&rub_id1323131213213232132131321313123132321321321 (sur deux kilomètres)
Pour être sur de pas avoir de problème avec ce genre de trucs, tu peux toujours forcer le type de chaque variable en GET ou POST dans ton script.
Par exemple un: settype($_GET["rub_id"], "integer");
Peut déjà t'éviter queqlues problèmes, car la valeur sera ensuite un entier limité à 2147483647 (2 milliards et des brouettes).
Si jamais tu as vraiment besoin de valeurs plus grandes (ça fait pas mal de rubriques ;) tu peux toujours utiliser double à la place de integer.
Remplacez nospam par mon prénom pour me contacter par email
Zouplaz <pouet@pouet.com> wrote:
Bonjour, je me pose la question suivante : est-il préférable de vérifier le
contenu des variables GET ?
Actuellement je fais une vérification logique (présence ou pas si ce
paramètre est indispensable, puisqu'en général je m'arrange pour que la non
présence ne retourne que des "pas d'enregistrements trouvés")
Par contre je me demande se qui se passe si un petit malin tente de saisir
manuellement dans l'url des valeurs excessivements longues, par exemple :
&rub_id1323131213213232132131321313123132321321321 (sur deux kilomètres)
Pour être sur de pas avoir de problème avec ce genre de trucs, tu peux
toujours forcer le type de chaque variable en GET ou POST dans ton
script.
Par exemple un:
settype($_GET["rub_id"], "integer");
Peut déjà t'éviter queqlues problèmes, car la valeur sera ensuite un
entier limité à 2147483647 (2 milliards et des brouettes).
Si jamais tu as vraiment besoin de valeurs plus grandes (ça fait pas mal
de rubriques ;) tu peux toujours utiliser double à la place de integer.
Bonjour, je me pose la question suivante : est-il préférable de vérifier le contenu des variables GET ?
Actuellement je fais une vérification logique (présence ou pas si ce paramètre est indispensable, puisqu'en général je m'arrange pour que la non présence ne retourne que des "pas d'enregistrements trouvés")
Par contre je me demande se qui se passe si un petit malin tente de saisir manuellement dans l'url des valeurs excessivements longues, par exemple :
&rub_id1323131213213232132131321313123132321321321 (sur deux kilomètres)
Pour être sur de pas avoir de problème avec ce genre de trucs, tu peux toujours forcer le type de chaque variable en GET ou POST dans ton script.
Par exemple un: settype($_GET["rub_id"], "integer");
Peut déjà t'éviter queqlues problèmes, car la valeur sera ensuite un entier limité à 2147483647 (2 milliards et des brouettes).
Si jamais tu as vraiment besoin de valeurs plus grandes (ça fait pas mal de rubriques ;) tu peux toujours utiliser double à la place de integer.
