2010-09-02 3 views
1

Je travaille sur une interface publique qui utilise une base de données qui n'est pas fiable en raison de l'accès de plusieurs applications.XSS je le fais mal? CI/php

Je voudrais un moyen propre d'encoder toute ma sortie en UTF-8 avec htmlentities pour empêcher XSS. Codeigniter (CI) n'a rien intégré. Le filtre qui est là est destiné à l'entrée et ne filtre pas réellement toutes les attaques XSS.

Je préférerais une réparation de couverture, mais je ne pense pas qu'il y en ait une.

Ce que je suis vraiment après dans cette discussion est quelle est la meilleure façon de filtrer ma sortie? Et est-ce que la solution suivante est la meilleure/la plus concise? (Fonction encode est une enveloppe sur htmlentities avec UTF8 et ENT_COMPAT)

<?php 
    echo form_input(“start_date[”.encode($id).”]”, encode($action->start_date,true), class=“input input-date dateISO required” readonly=readonly title=“must set a date.”’); 
?> 

Comme vous pouvez le voir le code commence à chercher assez stupide aspergeant cette fonction encode partout. L'encodage au niveau du contrôleur n'est tout simplement pas une solution car CI n'utilise pas de modèle strict. L'encodage au niveau du modèle laisse d'autres possibilités ouvertes. L'encodage au moment de la sortie semble être le moyen le plus sûr/attraper tous les cas, je veux juste quelqu'un pour confirmer que je ne manque pas quelque chose d'évident et de plus agréable à regarder/maintenir

+0

double possible de [htmlspecialchars vs htmlentities quand concernés par XSS] (http://stackoverflow.com/questions/3623236/htmlspecialchars-vs-htmlentities-when-concerned- avec-xss) –

+0

Pourquoi devrais-je poser deux fois la même question? Ce n'est pas une dupe, si vous lisez l'une de mes questions et quelque chose de nouveau sur le sujet, vous savez qu'il n'y a pas de sujet connexe qui pose ces questions. Arrêtez de poster sur la merde que vous ne connaissez pas simplement pour les points. C'est ennuyant. – stuckinphp

+1

Vous ne recevez aucun point dans les commentaires. Pour ne pas mentionner l'autre fil aurait pu être répondu en prenant le temps de parcourir d'autres sujets sur le même sujet, surtout compte tenu de cette question qui a exactement le même sujet: http://stackoverflow.com/questions/46483/htmlentities- vs-htmlspecialchars et explique la différence entre les deux. –

Répondre

0

Si vous êtes seulement concerné par l'échappement HTML (comme tout ce qui se passe entre les balises de script est une histoire différente) alors je sous-classe la classe Model (appelez-la base_model), crée une méthode que vous passez toutes les sorties avant de la renvoyer au contrôleur, et sous-classe tous vos autres modèles du modèle base_modèle.

// Base Model 
class Base_model extends Model { 

    function __construct() 
    { 
     parent::Model(); 
    } 

    function escape_output($str) 
    { 
     return htmlentities($str, ENT_COMPAT); 
    } 

} 


// Whatever model is a subclass of base_model 
class Whatever_model extends Base_model { 

    function __construct() 
    { 
     parent::__construct(); 
    } 

    function get_all($table) 
    { 
     return $this->db->get($table)->result_array(); 
    } 

} 

// Some controller somewhere 
$data['first_name'] = $this->Whatever_model->escape_output($str); 

Vous pouvez même aller plus loin et créer une fonction d'aide à utiliser dans les vues.

Encore mieux, vous pourriez faire en sorte que escape_output s'exécute récursivement à travers le tableau de données $ qui échappe à tout avant de charger votre vue.

+0

merci pour l'entrée, j'ai déjà pensé ce genre d'idée et bien que ce soit une meilleure idée, j'ai dû utiliser des vues d'allumeur de code héritées et mal portées qui ont une certaine logique et même des appels de base de données dans cette solution ne résoudrait pas tous les cas. Plus précisément, je suis après quelque chose qui correspond à CI et toute la liberté de CI. Quelque chose que je ne pense pas va se passer. J'ai depuis réalisé le filtre XSS que CI a + encoder la fonction d'assistance pour passer chaque élément de sortie devrait suffire pour ce que je fais de toute façon. – stuckinphp

0

IMHO CodeIgniter ont été conçus pour filtrer à partir de l'entrée. Il suppose que vos données sont déjà propres lors de l'application ont été initialisé, et vous avez obtenu l'entrée de champs de formulaire avec la syntaxe correcte:

$data["field"] = $this->input->post("field",true); 

Le second paramètre à afficher est pour activer le filtrage XSS, voir la déclaration de la fonction de poste dans le système/bibliothèques/CI_Input.php:

function post($index = '', $xss_clean = FALSE) 
    { 
     return $this->_fetch_from_array($_POST, $index, $xss_clean); 
    } 
Questions connexes