F�licitations � Nicolas D�sir qui recevra son prix par la poste d�s qu'il
m'aura donn� son adresse.
La r�ponse:
> if (defined($query->param('operation'))
> && &is_valid_operation($query->param('operation'))) {
$query->param('operation') peut retourner soit un scalaire (une variable),
soit un tableau, suivant le contexte Perl liste ou scalaire. Comme
is_valid_operation() est appel� en contexte liste mais qu'en suite on ne
prend que le premier scalaire de la liste:
my ($operation) = @_;
on ne teste que la validit� du premier �l�ment, et pas s'il y a plus
d'�l�ments.
Ensuite, lorsqu'on passe les param�tres � la fonction d'op�ration, on
utilise � nouveau $query->param('operation') dans un contexte de liste (de
param�tres) et donc le 2�me param�tre $is_admin est d�plac� (remplac� par
le deuxi�me �l�ment de $query->param('operation')).
Quand cela se produira-t-il ? Il suffit qu'on utilise une URL comme:
http://www.example.com/cgi-bin/buggy.pl?operation=lire&operation=1
> &do_operation($query->param('operation'), $is_admin);
L'op�ration est donc ex�cut�e avec privil�ge administrateur.
Solution: (une de celles-l�)
- v�rifier que scalar(@_) vaut 1 dans is_valid_operation().
- assigner $query->param('operation') � une variable scalaire d�s
ou avant de valider.
- passer une r�f�rence au tableau � &do_operation() (si le cas
multivalu� est normal), ou comme dernier param�tre tableau (risqu�
si on fait �voluer le code ensuite)
- utiliser la v�rification de param�tres que Perl peut apporter
(prototypage) que je n'ai pas encore essay�.
Comme quoi m�me des langages sans pointeurs peuvent �tre sensibles � des
attaques de buffer overflow un peu particuli�res :))
-
Pour poster une annonce: [EMAIL PROTECTED]
