Echapper du html

Version imprimable

01/06/2010, 13h46
jeronimo83

Echapper du html
Bonjour.

Dans mon backoffice j'ai un champs ckeditor et lorsque j'ajoute un nouvel enregistrement dans ma BDD les balises html ne sont pas échappées.

Ceci est très gênant, et permet d'insérer du javascript par exemple qui serait exécuté (j'ai testé et c'est bien le cas)

Je m'explique dans mon champs ckeditor je met ceci.

Code:

<script>alert(document.cookie)</script>

j'ai le même code dans ma bdd, ca ne devrait pas être ceci à la place?

Code:

<script>alert(document.cookie)</script&gt

Dans mon fichier settings.yml j'ai pourtant bien ceci.
Code:

1 2 3 4 .settings: # Output escaping settings escaping_strategy: true escaping_method: ESC_SPECIALCHARS
Merci.
01/06/2010, 15h05
ThomasR

Bonjour,

D'après ce qui est dit dans cette doc cela ne sert qu'à échapper les variables dans les templates (c'est à dire à l'affichage et non à l'enregistrement) :

http://www.symfony-project.org/refer...fr/04-Settings

Tu peux faire un coup de htmlspecialchars avant d'enregistrer en DB.
01/06/2010, 18h01
Michel Rotta

En quoi le fait d'enregistrer du script dans la base pose-t-il un problème ?

Le MySql n'exécute pas le javascript.

Ce qu'il faut absolument, c'est l'échapper avant l'affichage, ce que symfony gère très bien.

Tu peux effectivement utiliser htmlspecialchars avant de le mettre dans la base, mais tu devra faire l'opération inverse lors de chaque récupération... Et t'es pas sorti de l'auberge.

Symfony est bien conçu niveau sécurité, là, il ne se trompe pas.
01/06/2010, 18h46
jeronimo83

Citation:

Envoyé par mimi68

En quoi le fait d'enregistrer du script dans la base pose-t-il un problème ?

Le MySql n'exécute pas le javascript.

Ce qu'il faut absolument, c'est l'échapper avant l'affichage, ce que symfony gère très bien.

Tu peux effectivement utiliser htmlspecialchars avant de le mettre dans la base, mais tu devra faire l'opération inverse lors de chaque récupération... Et t'es pas sorti de l'auberge.

Symfony est bien conçu niveau sécurité, là, il ne se trompe pas.

En fait ce champs contient du HTML, qui est donc inséré en bdd.
Lors de l'affichage je veux que ce code html soit interpreté, donc je fais un

Code:

$active_post->getExcerpt(ESC_RAW)

En faisant comme ceci mon post est donc bien nickel avec sa mise en forme html etc.

Cependant si quelqu'un insère du javascript il sera exécuté et ca il ne faut absolument pas; voila ce qui m'embête.
01/06/2010, 19h22
Michel Rotta
tu as parfaitement raison.

Je modifierais la méthode get de l'objet base de donnée.

Le méthode d'origine est expliquée sur développez.net supprimer les balise script et leur contenu.

Donc dans le modèle de ta table, le champ s'appellera info
Code:

1 2 3 4 5 6 public function getInfo($Info) { $info = preg_replace('@<script[^>]*?>.*?</script>@si', '', $info); parent::_set('info', $info); }
Ainsi tu n'a rien a changer dans tes form et d'où que vienne l'information tu es sur qu'elle sera propre dans la base.
01/06/2010, 19h56
jeronimo83

Merci mim68, c'est nickel :)

Après réflexion, ce n'est pas une bonne idée.

Il faudrait créer un nouveau validator basé sur sfValidatorString
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class sfValidatorStringNoScript extends sfValidatorString { protected function doClean($value) { $value = parent::doClean($value) if ( preg_match('@<script[^>]*?>.*?</script>@si', $info) { throw new sfValidatorError($this, 'No script allowed in this string'); } } }
A mettre dans lib/validator/sfValidatorStringNoScript.class.php.

Normalement, si tu appliques ce validateur dans ton form, tu empêches tous script d'entrer et tu préviens le "pirate" qu'il est repéré.

Et le code est valide pour tous les champs que tu veux tester, donc réutilisable.

Attention, je n'ai pas testé le code, il est fort possible qu'il ne soit pas parfait ! :ccool:

02/06/2010, 11h07
jeronimo83

Merci pour ce complément d'informations, je viens de tester la validateur, et la sauvegarde de l'objet s'effectue en clearant le champs et il s'insére un null en bdd.

J'aurais aimé qu'un message d'erreur apparaisse et bloquer la validation je vais essayer de voir cela.

:roll:

Ouups, j'ai oublié un truc essentiel !!

Il faut retourner la valeur en fin du traitement !!!!
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class sfValidatorStringNoScript extends sfValidatorString { protected function doClean($value) { $value = parent::doClean($value) if ( preg_match('@<script[^>]*?>.*?</script>@si', $info) { throw new sfValidatorError($this, 'No script allowed in this string'); } return $value; } }
Là, s'il y a du script renseigné tu devrais avoir un message d'erreur et si non les donnée seront chargée (return $value;).

Citation:
Envoyé par mimi68
:roll:

Ouups, j'ai oublié un truc essentiel !!

Il faut retourner la valeur en fin du traitement !!!!
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class sfValidatorStringNoScript extends sfValidatorString { protected function doClean($value) { $value = parent::doClean($value) if ( preg_match('@<script[^>]*?>.*?</script>@si', $info) { throw new sfValidatorError($this, 'No script allowed in this string'); } return $value; } }
Là, s'il y a du script renseigné tu devrais avoir un message d'erreur et si non les donnée seront chargée (return $value;).
Ouais je l'avais fait en allant voir le validateur parent, je viens de cc et ca passe.

Merci :)

02/06/2010, 13h19
Michel Rotta

En fait, ce qu'il faudrait c'est un validateur pour les textarea.

Qui puisse ne valider que certaines balises xhtml, et vire toutes les autres balises, y compris script.

Et qui soit capable de ne garder que certain argument dans les balises xhtml.

Là, on a le début...
02/06/2010, 14h06
ThomasR

Il y a la fonction strip_tags qui permet de supprimer uniquement certaines balises d'une chaine de caractères :

http://fr.php.net/strip_tags
02/06/2010, 17h19
Michel Rotta

Je la connais, mais elle présente le désavantage d'une fausse sécurité. Elle ne contrôle pas les attributs des balises, et laisserait donc passer des balises avec style, ou pire, avec des onclick ou autre.

Et la philosophie symfony serait plutôt, dans le validateur, de refuser le form tant que la zone contiens des balises non autorisées ou des arguments non autorisés dans une balise autorisée.

En fait, l'idéal serait d'avoir un plugin qui implémente du bbCode, ce qui permettrait de gérer des texte enrichis en toute sécurité. Faut que j'y pense.

Juste pour info, dans la doc de strip_tags une personne a créé une fonction permettant de filtrer les balises et attributs :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function strip_tags_attributes($string,$allowtags=NULL,$allowattributes=NULL){
    $string = strip_tags($string,$allowtags);
    if (!is_null($allowattributes)) {
        if(!is_array($allowattributes))
            $allowattributes = explode(",",$allowattributes);
        if(is_array($allowattributes))
            $allowattributes = implode(")(?<!",$allowattributes);
        if (strlen($allowattributes) > 0)
            $allowattributes = "(?<!".$allowattributes.")";
        $string = preg_replace_callback("/<[^>]*>/i",create_function(
            '$matches',
            'return preg_replace("/ [^ =]*'.$allowattributes.'=(\"[^\"]*\"|\'[^\']*\')/i", "", $matches[0]);'   
        ),$string);
    }
    return $string;
}

Par contre j'aurais plus tendance à stocker la fonction de remplacement appelée par preg_replace_callback dans une vraie fonction, car là ca va l'évaluer à chaque fois...

02/06/2010, 17h48
Michel Rotta

oui,

Mais on n'est toujours pas dans la philosophie du validateur, mais plutôt d'un rectificateur.

L'idée serait de générer une exception si du code non autorisé est présent dans la chaine, et donc, de ré afficher le formulaire à la personne qui l'a saisi.

S'il veut ce rajouter du script sur son propre écran, il a tous le loisir d'utiliser un outils comme greasmonkey sans la complication de le planquer dans un champ texte.