[spip-dev] Créer ses propres saisies - Héritage - critère where - sécurité

Bonjour à tous,

Je suis en train de faire une nouvelle saisies, à l’attention du plugin Subdivisions, qui hérite tout simplement de la saisie selection.

Comme j’ai besoin de pouvoir isoler certaines subdivisions, j’ai inclus un argument where.
Mais je n’ai jamais vu personne le faire.
Aussi, je me demande s’il n’y a pas un problème de sécurité d’avoir une telle clause pour une saisie qui peut être placée dans l’espace public.

Voici le code :

APPEL depuis un squelette (l’argument where contraint à établir une liste de subdivisions dont le code ISO correspond aux régions d’outres-mers) :

#SET{where,‘iso_moi in (“FR-GUA”,“FR-MTQ”,“FR-GUF”,“FR-LRE”,“FR-MAY”)’}
[(#SAISIE{subdivisions, preferee, label=Ma région préférée, where=#GET{where}, explication=Choisissez votre collectivité d’outre-mer préférée, multiple=non})]

SAISIE (contrôleur d’une saisie dénommée subdivisions) :

[(#REM) On crée un tableau des subdivisions souhaitées]

#SET{datas,#ARRAY}

<BOUCLE_subdivisions(SUBDIVISIONS){par multi titre} {iso_pays ?} {iso_moi ?} {iso_parent ?} {nuts ?} {specifique ?} {where ?}>
#SET{datas, #GET{datas}|array_merge{#ARRAY{#ID_SUBDIVISION,#TITRE}}}
</BOUCLE_subdivisions>

[(#REM) On réutilise la saisie selection ]

<INCLURE{fond=saisies/selection, datas=#GET{datas}, env} />

Merci pas avance pour vos conseils.

Thrax.

il y a pas de raison que cela pose des problèmes de sécurités particuliers
1. TLe contenu de ton where est écrit en dur et ne dépend pas de l'internaute
2. De toute facon je pense que SPIP sanitanize directement les critères avant de les executer

Bonjour à tous,

Je suis en train de faire une nouvelle saisies, à l'attention du plugin Subdivisions, qui hérite tout simplement de la saisie selection.

Comme j'ai besoin de pouvoir isoler certaines subdivisions, j'ai inclus un argument where.
Mais je n'ai jamais vu personne le faire.
Aussi, je me demande s'il n'y a pas un problème de sécurité d'avoir une telle clause pour une saisie qui peut être placée dans l'espace public.

il y a pas de raison que cela pose des problèmes de sécurités particuliers
1. TLe contenu de ton where est écrit en dur et ne dépend pas de l'internaute

il peut être passé dans le _REQUEST (post ou get)

2. De toute facon je pense que SPIP sanitanize directement les critères avant de les executer

ça reste à vérifier...

il y a pas de raison que cela pose des problèmes de sécurités particuliers
1. TLe contenu de ton where est écrit en dur et ne dépend pas de l'internaute

il peut être passé dans le _REQUEST (post ou get)

pas de ce que je vois du code envoyé par Thrax

La nouvelle saisie reçoit ses arguments par l'environnement, c'est à dire _REQUEST.

Dans les conditions d'usage prévues par ce plugin, la noisette englobante décide la valeur de ces arguments,
mais des hackers n'utilisent pas le code mis à leur disposition dans les conditions prévues
puisque leur but n'est pas d'obtenir les fonctionnalités prévues.
Thrax envisage la possibilité qu'on appelle la noisette directement sans passer par la noisette qui l'inclut.

Comme le squelette d'une saisie est dans un sous dossier,
il n'y a que les webmasters (je crois même pas les admins ?) qui peuvent y accéder directement.
Ça limite le risque mais c'est pas absurde de se demander comment le where est sanitizé.

JL

moi je vois ca

#SET{where,'iso_moi in ("FR-GUA","FR-MTQ","FR-GUF","FR-LRE","FR-MAY")'}

dans le code de Thrax.

C'est bien un truc en dur.

Après s'il y a des choses qui remontent à plus haut en _request, j'y peux rien si Thrax l'indique pas...

Merci beaucoup pour vos réactions et vos éléments d’informations. Vous êtes super !

Je vais donc maintenir la saisie avec cet argument.

Il n’y a pas de code supplémentaire, Maïeul, mais la saisie ayant pour vocation à être réutilisée par les plugins qui utiliserait Subdivisions, je voulais m’assurer ne pas générer de problème.

La nouvelle saisie reçoit ses arguments par l'environnement, c'est à dire _REQUEST.

moi je vois ca
#SET{where,'iso_moi in ("FR-GUA","FR-MTQ","FR-GUF","FR-LRE","FR-MAY")'}
dans le code de Thrax.
C'est bien un truc en dur.

Oui mais il y a une nouvelle saisie qui se traduit par la création d'un nouveau squelette
saisies/subdivisions.html
qui sert pour le plugin Saisie à définir la #SAISIE
mais qui peut aussi potentiellement être appelé directement par ?page=saisies/subdivisions
avec la restriction précitée :
> comme [c]e squelette d'une saisie est dans un sous dossier,
> il n'y a que les webmasters (je crois même pas les admins ?) qui peuvent y accéder directement.
> Ça limite le risque mais c'est pas absurde de se demander comment le where est sanitizé.

JL

Oui. C’est exactement ma préoccupation/interrogation, JL.

oui mais c'est valable pour n'importe quel squelette, qu'est-ce que le fait que ce soit une saisie change la donne en terme de préoccupation?

Ce nest pas le fait que ce soit une saisie. L'interrogation porte sur le paramètre `where`.

Utiliser une balise #TEXTE dans un squelette se traduit par le passage d'une chaine de caractère qui est le nom du champ
et qu'il est facile de filtrer (ça doit être un nom de champ et parfois en plus on sait cadrer les valeurs possibles).
C'est tout ce qui passe, le reste c'est du code SPIP bien cerné.

Mais un where est un morceau de requête MYSQL qui est passé plus ou moins directement à l'interpréteur MYSQL.
Potentiellement il y a plein de trucs dedans.
Il faut donc avoir une vigilance particulière et la question est légitime
...même si les devs du noyau font d'ordinaire bien attention à ça
et ça m'étonnerait qu'ils aient négligé ça.

JL

je vais pas m’étendre sur le sujet parce que bon, mais oui la question initiale est légitime, et il y a un patch sur ce sujet dans les tuyaux

oui la question est légitime, là n'était pas le problème. Simplement le where en question étant écrit en dur, je ne comprend pas comment il aurait pu poser problème.

Non justement.
Il y a un where passé en argument "en dur" à la saisie depuis un squelette, ok, mais la saisie elle même exécute tout ce qu'on lui passe dans where.
Et on peut l'appeler de multiple façons cette saisie...