Hello,
Personellement, je ne suis pas d'accord avec cette approche. Je
considère que les administrateurs des sites
sont "grands" et "responsables".
Les administrateurs ont beau être grands et responsables, ils ne sont
pas souvent experts en programmation et encore moins en sécurité. Ils
peuvent d'autre part utiliser des filtres qui ont été livrés en standard
avec SPIP, ou fournis sur des sites comme spip_contrib. Là encore, on ne
peut pas leur demander d'évaluer le danger pour la sécurité inhérent à
ces filtres. Ils ne peuvent pas non plus vérifier tous les textes qui
passent sur leur site (surtout s'ils ont des forums publics ou des
pétitions).
Mettons par exemple un filtre qui supprimerait les tags HTML énervants
(du genre <blink>), afin qu'on ne puisse pas polluer l'affichage des
forums. Mettons un auteur malin qui entrerait dans son texte de forum :
<html><<blink>? mysql_query("delete * from spip_articles"); ?></html>
Si tu fais passer le filtre perso avant la sécurité anti-script, le
<blink> est enlevé puis le code PHP est détecté et désactivé par la
protection, sans que les administrateurs aient eu à intervenir à quelque
endroit que ce soit.
Si tu fais passer le filtre perso _après_ la sécurité, celle-ci ne
détecte pas le code PHP (puisque qu'il n'y a pas de "<?" dans le texte
qui lui est passé), néanmoins après le filtre perso on retrouve le texte
suivant :
<? mysql_query("delete * from spip_articles"); ?>
Ce code est stocké dans le cache et exécuté tel quel, il efface tous les
articles du site (sans passer par la poubelle de 48h ;-)).
Ce genre de mésaventure vaut aussi pour le code Javascript.
Si tu veux vraiment pouvoir créer du code PHP ou Javascript depuis tes
textes, il faut désactiver la sécurité "à la main". C'est-à-dire, au
lieu de :
[(#TEXTE|mon_filtre_dangereux)]
faire quelque chose comme :
<?php
$texte = '[(#TEXTE|mon_filtre_dangereux|texte_script)]';
$texte = inverser_securite($texte);
// eval('?>'.$texte.'<?php'); // pour javascript et php
echo $texte; // pour javascript simplement
?>
où inverser_securite() est une fonction à écrire qui annule les effets
de la sécurité (i.e. qui retransforme "<?" en "<?" et "<script" en
"<script").
L'avantage, c'est qu'un webmestre n'utilisera jamais cette construction
par hasard, mais bien parce qu'il s'autorise à ouvrir un trou de
sécurité. Le deuxième avantage, c'est que tu peux autoriser javascript
sans autoriser php, ce qui limite la taille du trou (depuis les filtres
on pourrait générer <script language="php">...</script> qui serait
exécuté sur le serveur : PHP: Basic syntax - Manual).
Amicalement
Antoine.