Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

checkbox

2 views
Skip to first unread message

Freegate

unread,
Jun 29, 2008, 2:46:51 AM6/29/08
to
Bonjour,

Voila le code que j'utilise pour mettre à jour ma base de données :

if (isset($_POST['submit']))
{


$sql="";
foreach ($_POST as $indice => $valeur)
{
if ($indice!="submit") {$sql=$sql."
".$indice."='".htmlentities($valeur)."',";}
}

$sql=substr($sql, 0, -1);
echo $sql;
$req="UPDATE $table SET $sql WHERE $filtre";
mysql_query($req) or die (mysql_error()." : ".$req);

}

Ce script a été mis en place pour mettre à jour n'importe quelle page
de mon site. Mon problème est que dans mon formulaire à envoyer, j'ai
plusieurs champs de type checkbox. Lorsque les cases à cocher ne le
sont pas, les POST['checkbox'] ne sont pas initialisés, et les champs
correspondants dans la base mysql ne peuvent se mettre à jour avec la
valeur "0". Par contre quand la case est cochée le POST renvoie bien la
valeur "1").

Avez-vous une astuce pour régler ce problème, sans perdre l'idée que le
script de mise à jour est un include qui doit fonctionner avec
n'importe quelle page de mon site ?

Merci.

Mickael Wolff

unread,
Jun 29, 2008, 3:12:30 AM6/29/08
to
Freegate a écrit :

> Voila le code que j'utilise pour mettre à jour ma base de données :
>
> if (isset($_POST['submit']))
> {
>
>
> $sql="";
> foreach ($_POST as $indice => $valeur)
> {
> if ($indice!="submit") {$sql=$sql."
> ".$indice."='".htmlentities($valeur)."',";}

Htmlentities doit être utilisé pour échapper des données à envoyer au
navigateur.
Pour échapper des données à insérer dans la base de données, il faut
que tu utilises mysql_escape ou mysql_real_escape. Dans l'état actuel de
ton développement, il est sensible à des failles de type SQL Injection.

> Avez-vous une astuce pour régler ce problème, sans perdre l'idée que le
> script de mise à jour est un include qui doit fonctionner avec n'importe
> quelle page de mon site ?

Pour savoir si une checkbox n'est pas cochée, il n'y a pas de secret,
il faut chercher la clé dans $_POST. Son absence indique que la case est
décochée. Tu ne peux pas faire autrement.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Olivier Miakinen

unread,
Jun 29, 2008, 4:54:31 AM6/29/08
to
Le 29/06/2008 08:46, Freegate a écrit :
>
> Voila le code que j'utilise pour mettre à jour ma base de données :
>
> if (isset($_POST['submit']))
> {
> $sql="";
> foreach ($_POST as $indice => $valeur)

Hum... j'espère que tu as un solide contrôle des noms d'indices
autorisés avant d'appeler ce code.

> [...]


>
> Ce script a été mis en place pour mettre à jour n'importe quelle page
> de mon site. Mon problème est que dans mon formulaire à envoyer, j'ai
> plusieurs champs de type checkbox. Lorsque les cases à cocher ne le
> sont pas, les POST['checkbox'] ne sont pas initialisés, et les champs
> correspondants dans la base mysql ne peuvent se mettre à jour avec la
> valeur "0". Par contre quand la case est cochée le POST renvoie bien la
> valeur "1").
>
> Avez-vous une astuce pour régler ce problème, sans perdre l'idée que le
> script de mise à jour est un include qui doit fonctionner avec
> n'importe quelle page de mon site ?

Eh bien avant d'appeler cet include, lors du contrôle des noms d'indices
que tu *dois* faire, tu utilises unset sur les noms inattendus ou non
désirés (ce qui incluera à la fois les checkbox et les valeurs qui
pourraient avoir été envoyées par un pirate).

Un truc du genre :

foreach ($_POST as $indice => $valeur) {

switch ($indice) {
case 'submit':
/* bouton de soumission */
break;
case 'truc':
/* nombre entre 3 et 7 */
if ($valeur < 3 || $valeur > 7) die(...)
if (... autres tests ...) die(...)
break;
case 'bidule':
... etc.
break;
default:
unset $_POST[$indice]; /* ou die(...) */
break;
}
}

Freegate

unread,
Jun 29, 2008, 1:51:08 PM6/29/08
to
Mickael Wolff a écrit :

> Pour savoir si une checkbox n'est pas cochée, il n'y a pas de secret,
> il faut chercher la clé dans $_POST. Son absence indique que la case est
> décochée. Tu ne peux pas faire autrement.

Ce qui veut qu'il faut que j'adape ce code à chaque page car il ne peut
savoir à l'avance si un $_POST[checkbox] est absent ou pas !!!

Mince !!!

Freegate

unread,
Jun 29, 2008, 4:13:36 PM6/29/08
to
Mickael Wolff a utilisé son clavier pour écrire :

>> Avez-vous une astuce pour régler ce problème, sans perdre l'idée que le
>> script de mise à jour est un include qui doit fonctionner avec n'importe
>> quelle page de mon site ?
>
> Pour savoir si une checkbox n'est pas cochée, il n'y a pas de secret,
> il faut chercher la clé dans $_POST. Son absence indique que la case est
> décochée. Tu ne peux pas faire autrement.

justement je me dis qu'il y a moyen de contourner le pb. J'ai pensé aux
champs de type hidden. Voila ce que j'ai codé dans la page :


<script language="javascript">

function value_box(mybox)
{
if (mybox.checked==true){this.value=1;document.myform.active.value=1}
else {this.value=0;document.myform.active.value=0;}
}

</script>
<body>


<form action="test.php" method="post" name="myform">
<input type="hidden" name="active" value="1" />
<label>test <input name="active" onclick='value_box(this)'
type='checkbox' value="1" checked="checked" /></label>
<br />
<input type='submit' name='submit' value='Enregistrer' />
</form>

L'idée est modifier le value d'un champ hidden de 0 à 1 lorsque je
coche la case en question. Mais manifestement le champs hidden n'est
pas mis à jour. Je ne comprends pas pourquoi car je ne maitrise pas le
javascript !!!

Pensez-vous que je doive insister dans cette voie ?

Olivier Miakinen

unread,
Jun 29, 2008, 4:37:46 PM6/29/08
to
Le 29/06/2008 22:13, Freegate a écrit :
>>
>> Pour savoir si une checkbox n'est pas cochée, il n'y a pas de secret,
>> il faut chercher la clé dans $_POST. Son absence indique que la case est
>> décochée. Tu ne peux pas faire autrement.
>
> justement je me dis qu'il y a moyen de contourner le pb. J'ai pensé aux
> champs de type hidden. Voila ce que j'ai codé dans la page :
>
> <script language="javascript">
>
> [...]

>
> L'idée est modifier le value d'un champ hidden de 0 à 1 lorsque je
> coche la case en question. Mais manifestement le champs hidden n'est
> pas mis à jour. Je ne comprends pas pourquoi car je ne maitrise pas le
> javascript !!!

Tu peux aller te renseigner du côté de fr.comp.lang.javascript.

> Pensez-vous que je doive insister dans cette voie ?

J'en doute, mais toi seul peut savoir l'impact qu'auraient des données
incomplètes ou corrompues dans ta base de données. En effet, sans même
parler des utilisateurs honnêtes qui désactivent le javascript (auquel
cas ton script n'aura aucun effet), tu dois savoir que les pirates sont
capables, avec une facilité enfantine, d'envoyer absolument n'importe
quelles données à ton script. Par rapport à ce que tu t'attends à
recevoir, ils peuvent envoyer des valeurs incorrectes pour des champs
existants, mais aussi rajouter des champs imprévus, ou au contraire
supprimer des champs obligatoires.

Et donc, à moins d'un contrôle rigoureux dans le script PHP, tu te
retrouveras avec des valeurs complètement bidons.

Freegate

unread,
Jun 29, 2008, 6:21:35 PM6/29/08
to
Dans son message précédent, Olivier Miakinen a écrit :

> Le 29/06/2008 22:13, Freegate a écrit :
>>>
>>> Pour savoir si une checkbox n'est pas cochée, il n'y a pas de secret,
>>> il faut chercher la clé dans $_POST. Son absence indique que la case est
>>> décochée. Tu ne peux pas faire autrement.
>>

>


> Et donc, à moins d'un contrôle rigoureux dans le script PHP, tu te
> retrouveras avec des valeurs complètement bidons.

En fait je développe une "application" web accessible uniquement en
intranet, voire en extranet.

Et j'ai rajouté une fonction à chaque page qui vérifie si javascript
est activé. en cas de non activation, ça fait un redirect vers une page
de sortie du site.

Olivier Miakinen

unread,
Jun 29, 2008, 6:21:35 PM6/29/08
to
À la relecture, une petite précision me semble nécessaire.

Le 29/06/2008 22:37, je répondais à Freegate :


>
> J'en doute, mais toi seul peut savoir l'impact qu'auraient des données
> incomplètes ou corrompues dans ta base de données. En effet, sans même
> parler des utilisateurs honnêtes qui désactivent le javascript (auquel
> cas ton script n'aura aucun effet),

^^^^^^
Je parlais ici du script JavaScript.

> tu dois savoir que les pirates sont
> capables, avec une facilité enfantine, d'envoyer absolument n'importe
> quelles données à ton script.

^^^^^^
Et là du script PHP.

> Par rapport à ce que tu t'attends à
> recevoir, ils peuvent envoyer des valeurs incorrectes pour des champs
> existants, mais aussi rajouter des champs imprévus, ou au contraire
> supprimer des champs obligatoires.
>
> Et donc, à moins d'un contrôle rigoureux dans le script PHP, tu te
> retrouveras avec des valeurs complètement bidons.

Voilà.

Mickael Wolff

unread,
Jun 30, 2008, 3:03:39 AM6/30/08
to
Freegate a écrit :

> Ce qui veut qu'il faut que j'adape ce code à chaque page car il ne peut
> savoir à l'avance si un $_POST[checkbox] est absent ou pas !!!

C'est d'ailleurs un bonne pratique. Ne pas contrôler les entrées de
ton programme t'expose à des risques liés à la sécurité des données de
ton client/patron.

Je te conseille de revoir ton approche de l'application web.

Mickael Wolff

unread,
Jun 30, 2008, 3:03:39 AM6/30/08
to
Freegate a écrit :

> En fait je développe une "application" web accessible uniquement en
> intranet, voire en extranet.

Une application web privée quoi ;)

> Et j'ai rajouté une fonction à chaque page qui vérifie si javascript est
> activé. en cas de non activation, ça fait un redirect vers une page de
> sortie du site.

Et en cas de problème de sécurité grave due au javascript, tu fais
comment ?

Freegate

unread,
Jul 1, 2008, 4:08:37 AM7/1/08
to
Mickael Wolff a formulé ce lundi :

> Freegate a écrit :
>> En fait je développe une "application" web accessible uniquement en
>> intranet, voire en extranet.
>
> Une application web privée quoi ;)
>
>> Et j'ai rajouté une fonction à chaque page qui vérifie si javascript est
>> activé. en cas de non activation, ça fait un redirect vers une page de
>> sortie du site.
>
> Et en cas de problème de sécurité grave due au javascript, tu fais
> comment ?

A quoi penses tu ? J'ai du mal à voir où tu veux en venir !!

La fonction de vérification en question n'est pas du javascript. C'est
juste un redirect html inséré dans la balise <script></noscript>

Mickael Wolff

unread,
Jul 1, 2008, 6:20:48 AM7/1/08
to
Freegate a écrit :

> A quoi penses tu ? J'ai du mal à voir où tu veux en venir !!

Tout simplement qu'un problème grave de sécurité peut te contraindre à
devoir désactiver le javascript. À une époque, certaines entreprises
avaient même interdit les images, car des buffer overflow dus à un bogue
de MSIE permettaient la diffusion de virus.

> La fonction de vérification en question n'est pas du javascript. C'est
> juste un redirect html inséré dans la balise <script></noscript>

Ce qui n'est pas valide
<http://www.w3.org/TR/html4/interact/scripts.html#edef-NOSCRIPT> en plus
:-D

Olivier Miakinen

unread,
Jul 1, 2008, 9:49:24 AM7/1/08
to
Le 01/07/2008 12:20, Mickael Wolff a écrit :
>
>> La fonction de vérification en question n'est pas du javascript. C'est
>> juste un redirect html inséré dans la balise <script></noscript>

Je suppose qu'il faut lire <noscript></noscript>

> Ce qui n'est pas valide
> <http://www.w3.org/TR/html4/interact/scripts.html#edef-NOSCRIPT> en plus
> :-D

En effet. L'élément NOSCRIPT est un %block; (donc il ne peut pas se
trouver dans le HEAD) et il ne peut contenir rien d'autre qu'un ou
plusieurs %block;.

Denis Beauregard

unread,
Jul 1, 2008, 6:11:17 PM7/1/08
to
Le 29 Jun 2008 17:51:08 GMT, Freegate <free...@free.fr> écrivait dans
fr.comp.lang.php:

Pourquoi ?

Disons que la page1 contient la variable a1 et la page2, la variable
a2. Tu valides les deux variables dans les deux cas, donc même code
inclus.

Ce que tu dois prévoir, c'est la liste de toutes les variables et
aussi, des moyens simples de valider toutes les variables. Pour les
chaînes de caractères, il faut aussi prévoir la possibilité de code
injecté dans la chaîne, donc interdire la présence de certains
caractères (je suppose que " et ; seront suffisants comme caractères
interdits) ou recoder la chaîne avant de l'insérer dans la base de
données avec mysql_escape par exemple.


Denis

Freegate

unread,
Jul 2, 2008, 6:11:01 PM7/2/08
to
Mickael Wolff vient de nous annoncer :

En tout cas merci pour les conseils, vos interpellations sur la
sécurité m'ont fait réflechir, il faut que j'y accorde plus de temps.

SAM

unread,
Jul 5, 2008, 12:26:03 PM7/5/08
to
Mickael Wolff a écrit :

> Freegate a écrit :
>
>> A quoi penses tu ? J'ai du mal à voir où tu veux en venir !!
>
> Tout simplement qu'un problème grave de sécurité peut te contraindre à
> devoir désactiver le javascript.

Je serais intéressé par des urls concernant ce sujet.
Merci.

> À une époque, certaines entreprises
> avaient même interdit les images, car des buffer overflow dus à un bogue
> de MSIE permettaient la diffusion de virus.

suivi vers JavaScript news:fr.comp.lang.javascript

--
sm

0 new messages