Je réponds sur spip-dev :
- J'insère dans la base de données les infos tirés d'une formulaire: je fais
quoi? Les fonctions sql_...q garantissent ma sécurité ou non?
Certaines, oui (sql_insertq par exemple), mais c'est rare.
- Je récupère un fichier uploadé, j'en fais quoi? Est-ce qu'il y a une
fonction de copie qui assure ma sécurité (comme dans ajouter_document), ou
bien je dois le faire à la main.
SPIP n'offre pas de méthode pour récupérer un fichier uploadé, donc là
tu es tout seul.
- Je veux afficher (en PHP) une variable qui m'arrive d'une formulaire: je
fais quoi? Est-ce que les _request de SPIP sont sécurisés, est-ce qu'ils
devraient l'être?
Ils ne le sont pas et n'ont pas à l'être : ils contiennent la donnée
brute telle que le client l'a envoyée. Le seul truc qu'on peut
sécuriser à ce niveau c'est les caractères interdits du genre %00 et
autres (cf. le plugin ecran de sécurité)
Qu'est-ce que je dois faire dans mon code?
Utiliser les échappements sql quand tu mets ces données dans sql, et
les échappements HTML quand tu les envoies dans HTML. C'est ainsi que
#ENV{toto} est sécurisé *pour le html* (mais pas pour le sql, vu que
c'est pas les mêmes contraintes !).
Pour mémoire : pour SQL on va échapper les apostrophes (' et ") en \'
et \" ; pour HTML on va supprimer les trucs du genre "<?php" "<", etc.
Si la donnée est installée dans les forums, signatures de pétition,
articles syndiqués, on va en plus passer safehtml() qui tente de
supprimer les javascript etc.
(Tiens, est-ce qu'il y a des risques à faire n'importe quoi dans les pipelines de typo - si
typo ne vire plus les scripts, est-ce que j'ai des trous là où je me
contentais de faire un typo avant d'afficher un truc?).
non pas de risque particulier, car interdire_scripts passe à la fin
-- Fil