web-dev-qa-db-fra.com

Quelque chose décape toutes les entités html avant la sortie vers le navigateur

J'ai un vilain problème. Dans mon site wordpress, quelque chose échappe à toutes les entités html avant d’envoyer des données au navigateur. Cela se produit dans tous les cas suivants:

echo ""XSS"  
print_r( htmlspecialchars( '"XSS' ) );  
esc_html( '"XSS' );
// output in all cases is unescaped
// im running version 3.4.1 with a bunch of plugins all disabled

// error_log() is fine and manages to put " in the log file

Fonctionne bien dans un fichier ne contenant pas de code wordpress, mais dans un plugin ou un thème. Blam. Tuez toutes les sorties qui s'échappent en une fois. C'est bizarre.

Où puis-je regarder?
ob_list_handlers ne mentionne que le "gestionnaire de sortie par défaut" et la recherche du code wp pour htmlspecialchars_decode et html_entity_decode ne révèle pas grand chose d’intéressant.

mettre à jour
Retourner à wp3.1 et installer vingt-onze ne change pas le problème.

Ok, je l'ai trouvé.

Firefox "voir la source de sélection" et firebug "inspecter un élément avec firebug" feront le décodage pour vous .... :-(

Ce genre de choses me tue!

"Voir la source de la page" ne fait pas cela. Merci à ceux qui ont pensé avec moi.

securityescaping
1
user16124

Il s'agissait d'un cas de codage de caractères UTF-8 prenant en charge la vue présentation de votre navigateur et convertissant ces entités HTML en leurs contre-parties, un texte lisible par l'homme.

Après tout, vous auriez peut-être très bien voulu une chaîne qui ressemblait à; "BLA pour une raison ou une autre aux yeux de votre spectateur au lieu de "BLA.

Du point de vue de la sécurité, une telle entrée, surtout si elle se présente sous la forme de données générées par l’utilisateur (non échappé) , pose un grand risque. Nous avons donc des fonctions telles que,

htmlentities       //Native PHP function
htmlspecialchars   //Native PHP function
esc_html           //WordPress API function
esc_attr           //WordPress API function

... s'occuper de l'encodage et du décodage des entrées en fonction de nos besoins.

En fait, htmlspecialchars_decode et html_entity_decode et d'autres révèlent des informations intéressantes sur la manière dont les chaînes peuvent être traitées.

Les chaînes dans 'single quotes' sont traitées différemment des chaînes dans "double quotes".

Je vous encourage à lire les documents PHP sur Types de chaînes , ainsi que,

Parce qu’ils donnent vraiment une bonne idée du sujet à traiter.

Au-delà de cela, je vous recommande de lire,

Ce qui expose les fonctions des API WordPress pour une grande partie de ce qui précède et plus encore.

Lorsque vous regardez sous le capot, comme vous l'avez mentionné par View Page Source , vous voyez réellement le fonctionnement réel du traitement de PHP et de WordPress. les données, qui, comme mentionné ci-dessus, ont été obscurcies par votre vue parce que WordPress appliquait le codage de caractères UTF-8 et dans les fonctions présentées dans votre message d'origine, htmlspecialchars était utilisé de manière standard, sans passer aucun paramètre supplémentaire peut avoir produit des résultats différents et un peu moins frustrant aussi;)

Jetez un coup d'œil à ce qui suit et à la façon dont ils traitent la sortie lorsque vous visualisez la source via "View Page Source ;

    $string = '"XSS"';

    echo htmlspecialchars($string);  
    //output -> "XSS"
    //converts double quotes, but also converts existing html entities
    //specifiy double_encode = false to prevent double encoding of entities
    //wordpress preferred method is esc_attr($string) (does not double encoding)

    echo htmlspecialchars_decode($string);
    //outputs -> "XSS"
    //decodes special char " back to " (double quote) 
    //default formatting is ENT_COMPAT which only converts double quotes not single

    echo htmlspecialchars_decode($string, ENT_NOQUOTES); 
    //output -> "XSS"
    //ignores decoding for special chars ' (single) and " (double) quotes

    echo htmlspecialchars_decode($string, ENT_QUOTES); 
    //outputs -> "XSS"
    //decodes special char " back to " (double quote)

    echo htmlentities($string, ENT_NOQUOTES);
    //output -> "XSS"

    echo htmlentities($string, ENT_COMPAT);
    //output -> "XSS"

    echo esc_attr($string);
    //output -> "XSS"
    //encoding "UTF-8"

    $stringed = "\x8F!!\"!";

    echo htmlentities($stringed, ENT_QUOTES);
    //output -> ?!!"!  (notice ? character)
    //PHP < 5.4 defaults encoding to "ISO-8859-1"
    //PHP >= 5.4 defaults encoding to "UTF-8"

    echo htmlentities($stringed, ENT_QUOTES | ENT_IGNORE, "UTF-8");
    //output -> !!&quot;!
    //ENT_IGNORE prevents an otherwise empty string being returned (potential security risk)

    echo htmlentities($stringed, ENT_QUOTES, "UTF-8");
    //returns an empty string

    echo html_entity_decode($stringed, ENT_QUOTES | ENT_IGNORE);
    //output -> ?!!"!   (notice ? character)
    //PHP < 5.4 defaults encoding to "ISO-8859-1"
    //PHP >= 5.4 defaults encoding to "UTF-8"

    echo esc_attr($stringed);
    //returns an empty string
    //encoding "UTF-8"

Ainsi, pendant que tout se passe sous le capot, dans la source, voici ce que vous auriez vu pour chacune de ces fonctions dans le navigateur.

enter image description here

J'ai écrit ceci au cas où cela pourrait aider d'autres personnes qui rencontrent des problèmes similaires, ce qui semble être un problème en premier lieu, mais ce n'est pas le cas lorsque vous comprenez ce qui fait quoi.

1
userabuser