href="css/<?php echo $style ?>.css"
Chaque fois que vous émettez une chaîne de texte au format HTML, vous devez utiliser htmlspecialchars()
sur la valeur, sinon des caractères hors de bande comme <
, &
ou dans ce cas "
éclatera du contexte (valeur d'attribut) et permettre à un attaquant d'insérer du code HTML arbitraire dans la page, y compris du contenu JavaScript.
Ceci dans un trou d'injection HTML, et vous devriez le réparer. Cependant, ce n'est pas encore directement une vulnérabilité XSS, car la source de $style
est $_COOKIE
. Ce cookie doit avoir été défini par vos scripts ou par l'utilisateur lui-même; Contrairement aux valeurs $_GET
et $_POST
, il ne peut pas être défini sur le navigateur d'un utilisateur par un tiers. Cela ne devient une vulnérabilité que si vous autorisez un tiers à définir des cookies arbitraires pour les cookies de l'utilisateur.
Cependant, style-switcher.php
fait exactement cela:
$style = $_GET['style'];
setcookie("style", $style, time()+604800);
sans vérifier que $style
est une valeur approuvée, et pas vérifier que la demande de changer de styles a été faite par l'utilisateur lui-même et non pas un arbitraire lien sur un site tiers: c'est-à-dire qu'il est vulnérable à XSRF. Dites un attaquant inclus un lien ou img src
dans une page visitée par l'utilisateur, indiquant:
http://www.example.com/style-switcher.php?style="><script>steal(document.cookie);</script>
ce script va maintenant être exécuté à chaque fois que l'utilisateur charge une page de votre site.(Techniquement, les "
, ;
et <
/>
caractères dans cet exemple besoin d'être URL codé avec %
, mais je l'ai laissé cru ici pour une meilleure lisibilité.), Vous devriez vraiment
(POST également à l'aide . forme pour cela, car il a une action d'effets secondaires)
pire encore, le même script contient une injection écho directe qui est le plus certainement XSS vulnérables:
if(isset($_GET['js'])) {
echo $style;
}
ce trou permet l'injection du contenu arbitraire . Bien que normalement vous nous attendrons à ce script avec js
d'être appelé par un XMLHttpRequest
(via jQuery get()
), il n'y a rien qui empêche un attaquant appelant en liant un utilisateur à une URL comme:
http://www.example.com/style-switcher.php?style=<script>steal(document.cookie);</script>&js=on
et en réponse ils obtiendront leur <script>
renvoyé en écho dans une page qui, sans Content-Type
en-tête explicitement défini, sera par défaut à text/html
, causant l'exécution de JavaScript du choix de l'attaquant dans le contexte de sécurité de votre site.
header("Location: ".$_SERVER['HTTP_REFERER']);
Ce n'est pas une bonne idée pour d'autres raisons. L'entête Referer
n'est pas garantie de se rendre jusqu'à votre serveur. Pour s'assurer que cela fonctionne, passez l'URL-to-return-to dans un paramètre au script.
Je ne voudrais probablement pas déranger avec le côté PHP à cela. Je voudrais juste mettre le cookie pertinent de JavaScript et location.reload()
ou manipuler le DOM de feuille de style à mettre à jour. Le script PHP est une tentative de faire fonctionner le switcher sans JavaScript, mais à moins que vous ne puissiez prendre la peine de l'implémenter correctement et en toute sécurité avec la protection XSRF, c'est une responsabilité.
Si vous incluez vos feuilles de style alternatives en tant que <link rel="alternate stylesheet">
, vous donnerez le support de changement de feuille de style aux utilisateurs sans JavaScript de toute façon.
Il est possible de définir la valeur Cookie, par site Web tiers dans un contexte particulier. Voir http://en.wikipedia.org/wiki/Cross-site_cooking – HoLyVieR
ok - merci beaucoup. Si vous pouviez essayer de faire une version sécurisée de ce script, beaucoup de ppl de net.tutsplus.com vous en remercieraient - parce que cela a un très bel effet. Mais si le côté php a une vulnérabilité XSRF je vais chercher une meilleure alternative javascript pour ce script! – ciprian
btw j'ai essayé cet exemple: http://www.example.com/style-switcher.php?style= & js = on et mon site tombe en panne :) plus de css donc vous avez raison! – ciprian