appel de fonction paramétrable ?

In article <4e28916c$1@meta.neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Le 21/07/2011 13:04, mb a écrit :

>> > > h='do_' + nom + '(' + params+ ');';

> mais comment pourrait-elle être illicite ?

Je n'en sais rien, n'ayant pas le code complet. En outre, même si
j'avais le code complet à la date du 21 juillet 2011, et si je
pouvais prouver qu'elle n'a aucun moyen d'être illicite aujourd'hui,
qu'est-ce qui prouve qu'un changement mineur fait dans un coin en
février 2013 ne pourrait pas ouvrir une faille dans ce bout de code
oublié depuis longtemps ?

je ne vois toujours pas ,
la chaîne h écrite au-dessus ne dépend que de nom et params

si do_nom et une fct , javascript va "évaluer" les arguments
et leur appliquer la fonction
le problème peut donc être au niveau de l'interprétation de params
mais c'est le même avec la version switch ( nom) { ... }

si do-nom n'est pas une fonction il sera interprété comme une variable
et sa concaténation avec la parenthèse (params) va provoquer une erreur
qui fait que js abandonnera et passera à la ligne suivante

si nom est formé de caractères qui ne sont pas acceptés par l'interprète
pour les variables et les fonctions , il y aura aussi une erreur
et abandon

> elle est formée à partir des éléments donnés

Donnés par quoi ou par qui, ces éléments ?

si nom et params sont issus d'une forme et renvoyés au serveur
il y a un problème
mais il situe avant les 2 lignes h=.... et eval(h)
ou avant le switch d'ailleurs
et donc eval n'est pas en cause

> et si "nom" n'existe pas JS ne fera rien ,

Ah ? Même s'il existait quelque part une fonction do_resetall,
censément jamais appelée sauf par un script privé, et dont la
tâche consiste à effacer l'ensemble des bases de données ?

une fonction do-resetall en javascript qui attaque une base de donnée
ce n'est pas eval qui est en cause mais cette fonction

C'est généralement le cas de toutes les failles de sécurité : on
ne voit pas où est le problème avant qu'elles aient été exploitées
par une personne malveillante.

Du coup, le principe de base de toute programmation un tant soit
peu « défensive », c'est de verrouiller au départ tout risque de
comportement imprévu. D'où le switch qui recense tous les cas
possibles, avec un traitement d'erreur pour les cas non prévus.

il faut donc aussi éviter la version switch
à cause de la chaîne params dont on ne sait pas
ce qu'elle contient vraiment et qui va être interprétée

c'est vrai qu'une fct équivalente à eval en php serait
catastrophique
mais ici ce n'est que du js inoffensif ...

bonnes vacances

--
mb

In article <4e28916c$1@meta.neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Le 21/07/2011 13:04, mb a écrit :

>> > > h='do_' + nom + '(' + params+ ');';

> mais comment pourrait-elle être illicite ?

Je n'en sais rien, n'ayant pas le code complet. En outre, même si
j'avais le code complet à la date du 21 juillet 2011, et si je
pouvais prouver qu'elle n'a aucun moyen d'être illicite aujourd'hui,
qu'est-ce qui prouve qu'un changement mineur fait dans un coin en
février 2013 ne pourrait pas ouvrir une faille dans ce bout de code
oublié depuis longtemps ?

je ne vois toujours pas ,
la chaîne h écrite au-dessus ne dépend que de nom et params

si do_nom et une fct , javascript va "évaluer" les arguments
et leur appliquer la fonction
le problème peut donc être au niveau de l'interprétation de params
mais c'est le même avec la version switch ( nom) { ... }

si do-nom n'est pas une fonction il sera interprété comme une variable
et sa concaténation avec la parenthèse (params) va provoquer une erreur
qui fait que js abandonnera et passera à la ligne suivante

si nom est formé de caractères qui ne sont pas acceptés par l'interprète
pour les variables et les fonctions , il y aura aussi une erreur
et abandon

> elle est formée à partir des éléments donnés

Donnés par quoi ou par qui, ces éléments ?

si nom et params sont issus d'une forme et renvoyés au serveur
il y a un problème
mais il situe avant les 2 lignes h=.... et eval(h)
ou avant le switch d'ailleurs
et donc eval n'est pas en cause

> et si "nom" n'existe pas JS ne fera rien ,

Ah ? Même s'il existait quelque part une fonction do_resetall,
censément jamais appelée sauf par un script privé, et dont la
tâche consiste à effacer l'ensemble des bases de données ?

une fonction do-resetall en javascript qui attaque une base de donnée
ce n'est pas eval qui est en cause mais cette fonction
et le script privé ne l'est pas assez

C'est généralement le cas de toutes les failles de sécurité : on
ne voit pas où est le problème avant qu'elles aient été exploitées
par une personne malveillante.

Du coup, le principe de base de toute programmation un tant soit
peu « défensive », c'est de verrouiller au départ tout risque de
comportement imprévu. D'où le switch qui recense tous les cas
possibles, avec un traitement d'erreur pour les cas non prévus.

il faut donc aussi éviter la version switch
à cause de la chaîne params dont on ne sait pas
ce qu'elle contient vraiment et qui va être interprétée

c'est vrai qu'une fct équivalente à eval en php serait
catastrophique
mais ici ce n'est que du js inoffensif ...

bonnes vacances

--
mb

In article <4e28916c$1@meta.neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Le 21/07/2011 13:04, mb a écrit :

>> > > h='do_' + nom + '(' + params+ ');';

> mais comment pourrait-elle être illicite ?

Je n'en sais rien, n'ayant pas le code complet. En outre, même si
j'avais le code complet à la date du 21 juillet 2011, et si je
pouvais prouver qu'elle n'a aucun moyen d'être illicite aujourd'hui,
qu'est-ce qui prouve qu'un changement mineur fait dans un coin en
février 2013 ne pourrait pas ouvrir une faille dans ce bout de code
oublié depuis longtemps ?

je ne vois toujours pas ,
la chaîne h écrite au-dessus ne dépend que de nom et params

si do_nom et une fct , javascript va "évaluer" les arguments
et leur appliquer la fonction
le problème peut donc être au niveau de l'interprétation de params
mais c'est le même avec la version switch ( nom) { ... }

si do-nom n'est pas une fonction il sera interprété comme une variable
et sa concaténation avec la parenthèse (params) va provoquer une erreur
qui fait que js abandonnera et passera à la ligne suivante

si nom est formé de caractères qui ne sont pas acceptés par l'interprète
pour les variables et les fonctions , il y aura aussi une erreur
et abandon

> elle est formée à partir des éléments donnés

Donnés par quoi ou par qui, ces éléments ?

si nom et params sont issus d'une forme et renvoyés au serveur
il y a un problème
mais il se situe avant les 2 lignes h=.... et eval(h)
ou avant le switch d'ailleurs
et donc eval n'est pas en cause

> et si "nom" n'existe pas JS ne fera rien ,

Ah ? Même s'il existait quelque part une fonction do_resetall,
censément jamais appelée sauf par un script privé, et dont la
tâche consiste à effacer l'ensemble des bases de données ?

une fonction do-resetall en javascript qui attaque une base de donnée
ce n'est pas eval qui est en cause mais cette fonction
et le script privé ne l'est pas assez

C'est généralement le cas de toutes les failles de sécurité : on
ne voit pas où est le problème avant qu'elles aient été exploitées
par une personne malveillante.

Du coup, le principe de base de toute programmation un tant soit
peu « défensive », c'est de verrouiller au départ tout risque de
comportement imprévu. D'où le switch qui recense tous les cas
possibles, avec un traitement d'erreur pour les cas non prévus.

il faut donc aussi éviter la version switch
à cause de la chaîne params dont on ne sait pas
ce qu'elle contient vraiment et qui va être interprétée

c'est vrai qu'une fct équivalente à eval en php serait
catastrophique
mais ici ce n'est que du js inoffensif ...

bonnes vacances

--
mb

In article <alfred-bitller-1B277B.02311022072011@news.orange.fr>,
mb <alfred-bitller@orange.fr> wrote:

c'est vrai qu'une fct équivalente à eval en php serait
catastrophique

oh fan !
elle existe !

--
mb

Bol <Bol@wanadoo.fr> wrote:

> j'ai une string search|save|edit|view et je voudrais qu'elle appelle les
> fonctions relatives, par exemple :
> do_search(params) | do_save(params) | do_edit(params) | do_view(params)

un truc du genre

function do_( f, p )
{
f = this['do_'+f];
return ( typeof f == 'function' ) ? f(p) : null;
}

do_( 'edit', params );

ou

window.do_( 'edit', params );

ou

element.do_ = window.do_;
element.do_edit = function (p) { /* code */ };
element.do_( 'edit', params );

ou prototype ... etc ...

A+
Bol

OK; un grand merci à tous; j'en sais suffisamment

Le 21/07/2011 09:55, mb a écrit :

In article<1k4qxc3.1g01zop1qutu77N%unbewusst.sein@fai.invalid>,
unbewusst.sein@fai.invalid (Une Bévue) wrote:

j'ai une string search|save|edit|view et je voudrais qu'elle appelle les
fonctions relatives, par exemple :
do_search(params) | do_save(params) | do_edit(params) | do_view(params)

comment kon fait ?

Bonjour ,

appel d'une fct par son nom ?

h='do_' + nom + '(' + params+ ');';

// nom = search ou edit ou ...
// pour fabriquer do_search(params);

// et

eval(h);

// pour exécuter

j'espere avoir compris la question

Moi je suis pas sûr puisque personne n'en a parlé : ne serait-il pas ici
opportun d'utiliser les fonctions dynamiques (ou fonctions variables) ?
Et si on veut contrôler les actions, on les met dans un array et on
contrôle avec un in_array ?

À (at) Fri, 22 Jul 2011 02:31:10 +0200,
mb <alfred-bitller@orange.fr> écrivait (wrote):

In article <4e28916c$1@meta.neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Le 21/07/2011 13:04, mb a écrit :

>> > > h='do_' + nom + '(' + params+ ');';

> mais comment pourrait-elle être illicite ?

Je n'en sais rien, n'ayant pas le code complet. En outre, même si
j'avais le code complet à la date du 21 juillet 2011, et si je
pouvais prouver qu'elle n'a aucun moyen d'être illicite aujourd'hui,
qu'est-ce qui prouve qu'un changement mineur fait dans un coin en
février 2013 ne pourrait pas ouvrir une faille dans ce bout de code
oublié depuis longtemps ?

je ne vois toujours pas ,
la chaîne h écrite au-dessus ne dépend que de nom et params

si do_nom et une fct , javascript va "évaluer" les arguments
et leur appliquer la fonction
le problème peut donc être au niveau de l'interprétation de params
mais c'est le même avec la version switch ( nom) { ... }

Le simple fait que vous ne voyez pas la différence entre la solution à
base de 'eval' et celles basées sur un switch ou une recherche dans un
tableau associatif montre que la solution à base de 'eval' est
dangereuse... puisque vous ne mesurez pas correctement les risques de
son utilisation.

[...]

c'est vrai qu'une fct équivalente à eval en php serait
catastrophique
mais ici ce n'est que du js inoffensif ...

Javascript n'est pas inoffensif. Sinon pourquoi tenterait-on de bloquer
le cross-site scripting ? De plus, dans tous les langages (dont PHP) où
une fonction de type 'eval' existe, il est toujours fortement
déconseillé de l'utiliser. Et dans la plupart des cas où on croit en
avoir besoin, il y a moyen de s'en passer en produisant un code plus
lisible, plus sûr et donc de meilleure qualité et de maintenance plus
aisée.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

In article <wt9oc0mg42f.fsf@enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:

Le simple fait que vous ne voyez pas la différence entre la solution à
base de 'eval' et celles basées sur un switch ou une recherche dans un
tableau associatif montre que la solution à base de 'eval' est
dangereuse... puisque vous ne mesurez pas correctement les risques de
son utilisation.

donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?

la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
mais je ne demande pas mieux que d'apprendre , les forum ne sont-ils
pas fait pour ça ?

donc expliquez moi où est le danger en javascript ( hors php )

[...]
> c'est vrai qu'une fct équivalente à eval en php serait
> catastrophique
> mais ici ce n'est que du js inoffensif ...

Javascript n'est pas inoffensif. Sinon pourquoi tenterait-on de bloquer
le cross-site scripting ?

le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php

merci pour toute explication

--
mb

Le 22/07/2011 02:31, mb a écrit :

>> > > h='do_' + nom + '(' + params+ ');';

> mais comment pourrait-elle être illicite ?

Je n'en sais rien, n'ayant pas le code complet. En outre, même si
j'avais le code complet à la date du 21 juillet 2011, et si je
pouvais prouver qu'elle n'a aucun moyen d'être illicite aujourd'hui,
qu'est-ce qui prouve qu'un changement mineur fait dans un coin en
février 2013 ne pourrait pas ouvrir une faille dans ce bout de code
oublié depuis longtemps ?

je ne vois toujours pas ,
la chaîne h écrite au-dessus ne dépend que de nom et params

Oui. Je suis d'accord qu'il faut aussi contrôler params, mais là n'était
pas vraiment la question.

si do_nom et une fct , javascript va "évaluer" les arguments
et leur appliquer la fonction
le problème peut donc être au niveau de l'interprétation de params
mais c'est le même avec la version switch ( nom) { ... }

La différence principale entre mon code et le tien, ce n'est pas tant
l'utilisation ou non d'eval que le 'default' avec traitement d'erreur.

Si tu tiens absolument à 'eval', je n'ai rien contre, à partir du moment
où l'on s'est protégé des cas possiblement illicites. Par exemple :

switch(nom) {
case "search":
case "save":
case "edit":
case "view":
h='do_' + nom + '(' + params+ ');';
eval(h);
break;
default:
//
// traitement d'erreur
//
}

si do-nom n'est pas une fonction il sera interprété comme une variable
et sa concaténation avec la parenthèse (params) va provoquer une erreur
qui fait que js abandonnera et passera à la ligne suivante

Déjà, le fait de « passer à la ligne suivante » au lieu de faire un
traitement d'erreur approprié et réfléchi, c'est aussi un risque.

si nom est formé de caractères qui ne sont pas acceptés par l'interprète
pour les variables et les fonctions , il y aura aussi une erreur
et abandon

Abandon ? Tu veux dire que le script s'arrêtera, ou qu'il continuera ?
S'il s'arrête, il peut y avoir des cas où il aurait mieux valu qu'il
continue, et inversement.

si nom et params sont issus d'une forme et renvoyés au serveur
il y a un problème
mais il se situe avant les 2 lignes h=.... et eval(h)
ou avant le switch d'ailleurs
et donc eval n'est pas en cause

Ce n'est pas moi qui ai dit que eval était un problème en soi. Ce que
je dis, c'est que si le contrôle de validité de 'nom' est fait à un
endroit, et que la construction du nom de la fonction est fait à un
autre endroit, il y a toutes les chances pour qu'un jour (mettons lors
d'un changement mineur en février 2013) les deux ne soient plus tout
à fait en phase, ce qui ouvrira une faille de sécurité.

> et si "nom" n'existe pas JS ne fera rien ,

Ah ? Même s'il existait quelque part une fonction do_resetall,
censément jamais appelée sauf par un script privé, et dont la
tâche consiste à effacer l'ensemble des bases de données ?

une fonction do-resetall en javascript qui attaque une base de donnée
ce n'est pas eval qui est en cause mais cette fonction
et le script privé ne l'est pas assez

Encore une fois, je n'ai pas dit que 'eval' était en cause. Une
fonction dangereuse *peut* exister, elle peut même être parfaitement
justifiée. Ma version avec 'switch' et 'default' permet d'éviter
d'appeler une telle fonction par erreur ou par négligence, alors
qu'une version sans contrôle est beaucoup plus risquée.


Cordialement,
--
Olivier Miakinen

In article <4e29fb37$1@meta.neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:

Si tu tiens absolument à 'eval', je n'ai rien contre, à partir du moment
où l'on s'est protégé des cas possiblement illicites. Par exemple :

switch(nom) {
case "search":
case "save":
case "edit":
case "view":
h='do_' + nom + '(' + params+ ');';
eval(h);
break;
default:
//
// traitement d'erreur
//
}

ça parait plus clair ,
je ne fais pas de fixation sur la fonction eval ,
mais tronquer un langage de ses fonctions alors que c'est lui qui permet
d'améliorer la sécurité à la source c'est pas raisonnable

> si nom est formé de caractères qui ne sont pas acceptés par l'interprète
> pour les variables et les fonctions , il y aura aussi une erreur
> et abandon

Abandon ? Tu veux dire que le script s'arrêtera, ou qu'il continuera ?
S'il s'arrête, il peut y avoir des cas où il aurait mieux valu qu'il
continue, et inversement.

je n'ai pas analysé complètement le comportement en cas d'erreur ,
il y a des cas ou il abandonne le script complètement d'autres où il
passe à la ligne suivante
( je n'en ai pas vu ou il passe à l'instruction suivante sur la même
ligne )

Ce n'est pas moi qui ai dit que eval était un problème en soi. Ce que
je dis, c'est que si le contrôle de validité de 'nom' est fait à un
endroit, et que la construction du nom de la fonction est fait à un
autre endroit, il y a toutes les chances pour qu'un jour (mettons lors
d'un changement mineur en février 2013) les deux ne soient plus tout
à fait en phase, ce qui ouvrira une faille de sécurité.

il faudrait être sùr de pouvoir analyser tous les cas possibles ,
lors d'une modification on sait bien qu'il peut y avoir des répercussions

Encore une fois, je n'ai pas dit que 'eval' était en cause. Une
fonction dangereuse *peut* exister, elle peut même être parfaitement
justifiée. Ma version avec 'switch' et 'default' permet d'éviter
d'appeler une telle fonction par erreur ou par négligence, alors
qu'une version sans contrôle est beaucoup plus risquée.

exact , mais la fonction dangereuse dans un script "public"
appelée par un script privé, est-ce bien raisonnable ?

à propos du danger de eval ( mais c'est pas toi ! )
après réflexion que penser de :
onClick , onSubmit , ....
de innerHTML ...
et j'en passe

bonne journée

--
mb