Cours MIT "Sécurité des systèmes informatiques". Conférence 9: Sécurité des applications Web, partie 3

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3

Public: qu'est-ce qui empêche un attaquant de trouver une clé? Où se trouve cette clé secrète?



Professeur: oui, c'est une bonne question. Dans la plupart des cas, le client pour AWS n'est pas un navigateur, mais certaines machines virtuelles s'exécutant dans le cloud. Ainsi, vous ne voyez que la communication entre les machines virtuelles. Vous pouvez également imaginer que les utilisateurs peuvent en quelque sorte diffuser ces liens ou les intégrer d'une manière ou d'une autre en HTML. Si vous avez quelque chose comme celui montré sur le tableau à l'intérieur du code source HTML ou JavaScript, vous aurez le code pour créer une telle demande. Par conséquent, si je vous fournis une de ces choses, vous pouvez faire une demande en mon nom.

Public: Est-il possible d'utiliser MAC pour des clients normaux?

Professeur: pour normal - voulez-vous dire les navigateurs?

Public: pour les utilisateurs ordinaires.

Professeur: le fait est que la question de savoir où réside réellement la clé est cruciale. Parce que si la clé peut être volée aussi facilement que les cookies, alors nous n'avons rien gagné. Par conséquent, dans de nombreux cas, toutes ces choses sont stockées quelque part dans le cloud et servent à échanger des données entre les machines virtuelles et sont transmises de serveur à serveur également dans le cloud. Ainsi, le développeur d'applications lance la machine virtuelle, qui utilise l'externalisation d'un tas de choses stockées dans AWS.

Public: y a-t-il un problème de retard du réseau ici, afin que l'attaquant puisse envoyer la même demande immédiatement après l'utilisateur et également y accéder?

Professeur: oui, il suffit de dire que plusieurs personnes ont défendu des thèses sur le thème de la sécurité des horodatages. Mais vous avez absolument raison, car nous avons considéré un exemple assez grossier.



Imaginez qu'ici, dans cet exemple String To Sign, sur la ligne DATE, nous aurons la valeur «lundi 4 juin». Ensuite, si l'attaquant peut accéder à tout cela, il pourra répéter la demande de l'utilisateur. Le fait est qu'AWS vous permet d'utiliser la date d'expiration de ces choses. Ainsi, une chose que vous pouvez faire est d'ajouter le champ Expire ici, et nous supposerons qu'une date d'expiration a été définie.



Ensuite, je peux donner ce lien à un tas de personnes différentes, et le serveur vérifiera si leurs demandes ont expiré.

Public: même si la date d'expiration n'est que de 200 millisecondes, mais que l'attaquant surveille le réseau, il pourra envoyer au cas où plusieurs copies de la demande au lieu d'une.

Professeur: il est absolument vrai que si l'attaquant attaque le réseau et voit comment ces choses sont transmises par fil, et qu'il y a suffisamment de marge de manœuvre dans la date d'expiration, alors il peut certainement faire cette attaque.

C'était donc un aperçu du fonctionnement des cookies apatrides. Cela soulève une question intéressante: que signifie la déconnexion avec des cookies de ce type? La réponse est que vous ne sortez pas vraiment. Je veux dire, vous avez cette clé et chaque fois que vous voulez envoyer une demande, vous la envoyez. Mais le serveur pourrait révoquer votre clé.

Supposons que le serveur ait révoqué la clé. Mais vous pouvez créer l'une de ces choses GET, et lorsque vous envoyez un message au serveur, il dit: "Oui, je connais déjà votre ID utilisateur, la clé a été révoquée, donc je ne répondrai pas à votre demande." Cependant, il y a des nuances, et si nous parlons de choses comme SSL, il est beaucoup plus facile d'autoriser une personne que de les rappeler.

En tant que tel, il existe plusieurs autres choses que vous pouvez utiliser si vous souhaitez éviter les cookies traditionnels pour implémenter l'authentification. L'un d'eux est l'utilisation du stockage DOM, qui contient des informations sur l'authentification du côté client. Vous pouvez utiliser le référentiel DOM pour stocker certains états de session qui sont généralement placés dans des cookies.



Si vous vous souvenez de la dernière conférence, le référentiel DOM est une interface clé des valeurs que le navigateur fournit à chaque source, c'est-à-dire que le navigateur les prend à partir de là et les insère dans une chaîne.

La bonne chose est que le DOM n'a pas de règles aussi stupides concernant les mêmes politiques de la même origine. Donc, s'il s'agissait de cookies réguliers, vous pourriez faire toutes ces astuces de sous-domaine et autres. Le référentiel DOM est en fait strictement lié à une seule source, vous ne pouvez donc pas étendre de sous-domaine. Par conséquent, des frameworks tels que Meteor utilisent ce stockage.

Mais notez que si vous souhaitez enregistrer les informations d'authentification dans le référentiel DOM, vous devrez écrire vous-même du code JavaScript pour transférer ces informations sur le serveur, les chiffrer, etc. Voici ce que vous devez faire dans ce cas.
On pourrait utiliser des certificats côté client, par exemple, le format x.509, qui contient des informations sur le propriétaire, une clé publique, des informations sur une autorité de certification et une signature numérique électronique. La bonne chose à propos de ces certificats est que JavaScript n'a pas d'interface explicite pour accéder à ces choses. Contrairement aux cookies, où il y a toujours une «course aux armements» pour trouver des erreurs de politique de même origine, les certificats n'ont pas d'interface JavaScript explicite pour cela. C'est donc très bien du point de vue de la sécurité.

L'un des problèmes que j'ai mentionnés brièvement et que nous aborderons en détail dans les conférences suivantes est la révocation des certificats. Si un utilisateur quitte votre organisation, comment pouvez-vous lui retirer un certificat? C'est assez compliqué.



De plus, ces choses ne sont pas très pratiques à utiliser, car personne ne veut installer un tas de certificats pour chaque site que vous visitez. Par conséquent, les certificats d'authentification ne sont pas très populaires, à l'exception des entreprises ou des organisations qui sont responsables de la sécurité avec une grande responsabilité. Ceci conclut notre discussion sur les cookies.

Parlons maintenant des vulnérabilités de protocole dans la pile Web. L'un des types d'attaques intéressants consiste à utiliser des erreurs dans les composants du navigateur, par exemple, lors de l'analyse des URL. Alors, comment l'analyse d'URL peut-elle nous causer des problèmes?

Supposons que nous ayons une URL du type où des caractères étranges sont intégrés à la fin pour une raison quelconque:

exemple.com : 80 @ foo.com.

La question est, quelle est l'origine de cette URL particulière? Flash aurait pensé que le nom d'hôte était example.com. Mais lorsque le navigateur analysera l'adresse, il pensera que l'origine de l'hôte dans ce cas est foo.com.



C'est très mauvais, car lorsque nous avons deux entités différentes qui sont confuses quant à l'origine de l'origine de la même ressource, cela est semé de problèmes désagréables.
Par exemple, un code flash peut être malveillant et télécharger du matériel sur example.com. Si l'exploit était intégré à la page avec foo.com, il pourrait également y faire des choses diaboliques. Et puis il prend du code d'exemple.com et l'exécute avec les pouvoirs de foo.com. De nombreuses règles d'analyse complexes comme celles-ci rendent la vie très difficile. Cela arrive tout le temps.

Nous venons d'examiner la désinfection du contenu, dont l'idée principale est qu'elle est souvent bien meilleure lorsqu'il existe des règles d'analyse plus simples pour ce genre de chose. Cependant, rétrospectivement, cela est difficile à faire, car le HTML est déjà là.
Parlons maintenant de ma vulnérabilité de sécurité préférée - les fichiers avec l'extension .jar, qui sont une archive ZIP avec une partie d'un programme Java. Les fichiers JAR du navigateur deviennent la cible de l'attaque, principalement des applets Java. Vers 2007, un excellent site appelé lifehacker.com a expliqué comment intégrer des fichiers zip dans des images. Il n'est pas clair de qui vous essayez de vous cacher en faisant cela, mais lifehacker.com s'assure que vous pouvez le faire.

Ils utilisent principalement le fait que si vous regardez les formats d'image, tels que les GIF, alors, en règle générale, l'analyseur fonctionne de haut en bas. Il trouve d'abord les informations dans l'en-tête, puis regarde les bits restants situés en bas.



Il s'est avéré que les programmes qui manipulent généralement les fichiers ZIP fonctionnent de bas en haut, c'est-à-dire à l'opposé du sens de l'analyse des images. Tout d'abord, ils trouvent les informations dans le pied de page du fichier et décompressent ce qui se trouve à l'intérieur de l'archive. Ainsi, si vous placez un fichier image contenant une archive ZIP, il passera toutes les vérifications, même la vérification Flickr, comme toute autre image, et il s'affichera même sous forme d'image dans votre navigateur.

Mais vous seul connaîtrez la vérité cachée. Vous seul serez conscient que si vous prenez ce fichier, vous pouvez le décompresser et utiliser les informations qu'il contient. Cela semble être une astuce bon marché, mais les pirates ne dorment jamais, ils veulent constamment ruiner nos vies. Alors, comment mettent-ils en œuvre cette idée?

Ils comprennent que les fichiers JAR sont dérivés du format .zip. Cela signifie que vous pouvez créer une animation GIF ou une image statique qui aurait un fichier JAR, c'est-à-dire du code exécutable JavaScript, tout en bas.

Plus tard, les gens ont appelé cette méthode d'attaque GIFAR, moitié GIF, moitié JAR, et les deux moitiés sont mauvaises. C'était génial. Lorsque les gens ont découvert une telle opportunité pour la première fois, ils l'ont trouvée incroyable, mais n'ont pas du tout compris comment l'utiliser. Mais comme il s'est avéré, sur la base de ces éléments, les choses suivantes peuvent être faites.



Alors, comment pouvez-vous faire cela? Vous utilisez simplement CAD. Prenez .gif, prenez .jar, utilisez l'archive auto-extractible - boom, et GIFAR vous a attaqué!

Donc, une fois que vous avez cela, que pouvez-vous faire? Il existe certains sites sensibles qui permettent aux utilisateurs de fournir des données, mais pas des types de données arbitraires. Donc Flickr ou quelque chose comme ça peut ne pas vous permettre d'envoyer ActiveX arbitraire ou tout autre HTML arbitraire. Mais vous serez autorisé à envoyer des images. Vous pouvez donc créer l'une de ces choses et la soumettre à l'un de ces sites confidentiels qui vous permet d'envoyer des images. Que devez-vous faire pour mener une attaque réussie dans ce cas?



Tout d'abord, envoyez cette image «bourrée» à l'un de ces sites. Deuxièmement, utilisez la méthode d'attaque de script intersite XSS, en utilisant les vulnérabilités existantes. Pour ce faire, vous devez insérer l'applet, en écrivant en JavaScript une telle expression:

Ce code exploite la vulnérabilité de script intersite, il sera donc lancé dans le contenu du site. GIFAR passera le contrôle d'origine, car il provient d'un site avec une source d'origine commune, malgré le fait que ce code ait été inséré par un attaquant.

Ainsi, l'attaquant a maintenant la possibilité d'exécuter cette applet Java dans le contexte du site de la victime avec toutes les autorisations d'origine. Et l'une de ces choses sera en fait correctement identifiée comme une image GIF. Mais il y a du code caché ici. Permettez-moi de vous rappeler qu'au début, le navigateur décompresse les fichiers archivés, donc, tout d'abord, il lancera la partie JAR, ignorera la partie supérieure du GIF. C'est en fait assez étonnant.

Il existe des moyens assez simples de résoudre ce problème. Par exemple, vous pouvez utiliser le chargeur d'applet, qui comprend qu'il ne doit pas y avoir de déchets aléatoires. Dans de nombreux cas, les informations de métadonnées utilisées indiquent la longueur de cette ressource. Dans ce cas, le chargeur démarre, comme prévu, par le haut, analyse sa longueur, voit que l'applet se termine en haut et s'arrête. Il ne se soucie pas de la partie inférieure, il est possible que ce soit même 0. Dans notre cas, un tel chargeur n'aidera pas, car il commencera à traiter la demande de la partie inférieure, archivée, et s'arrêtera devant la partie supérieure, l'ignorant.

Ce que j'aime à ce sujet, c'est qu'il montre vraiment la largeur de la pile de logiciels Internet. En ne prenant que ces deux formats, GIF et JAR, vous pouvez créer une attaque vraiment désagréable.

Vous pouvez faire de même avec les fichiers PDF. Vous pouvez mettre un PDF au lieu d'un GIF et appeler cette attaque quelque chose des dangers de PDFAR. Mais à la fin, les gens ont compris ce problème et les vulnérabilités de ce type sont maintenant éliminées.

Public: que pouvez-vous faire avec ce type d'attaque, qui ne peut pas être fait avec une attaque de script intersite XSS régulière?

Professeur: C'est une bonne question. Donc, ce qui est bien à ce sujet, c'est que Java peut souvent être un outil plus puissant que JavaScript normal, car il utilise des règles légèrement différentes, la même politique d'origine, etc. Mais vous avez raison de dire que si vous pouvez exécuter des scripts intersites, exécuter JavaScript vous-même peut être assez dommageable. Mais le principal avantage de cette méthode est que cette technologie d'attaque fonctionne à l'intérieur de l'applet et peut faire ce qu'elle ne peut pas faire avec du code de script malveillant ordinaire.

Donc, comme je l'ai dit, c'est mon attaque préférée de tous les temps, principalement parce qu'elle a fait penser à un mot comme GIFAR.

Une autre chose intéressante est l'utilisation d'attaques basées sur le temps. Habituellement, les gens ne considèrent pas le temps comme une ressource, qui peut être un vecteur d'attaques. Mais comme je l'ai noté il y a quelques minutes, ce temps peut en fait être un moyen d'introduire un exploit dans le système.

L'attaque spécifique dont je vais vous parler est l'attaque par canal secret. L'idée de cette attaque est qu'un attaquant trouve un moyen d'échanger des informations entre deux applications, et cette opération d'échange n'est pas autorisée. Un attaquant utilise en quelque sorte une partie du système pour transférer des bits d'informations entre deux ressources différentes.

Un bon exemple d'une telle chose est une attaque CSS reniflant. Qu'est-ce qu'une telle attaque?

Supposons qu'un attaquant dispose d'un site Web qu'un utilisateur peut visiter. Faire en sorte qu'un utilisateur visite un site Web est en fait assez simple. Vous créez une annonce ou envoyez un e-mail de phishing.

Ainsi, l'attaquant dispose d'un site Internet que l'utilisateur visite. Et le but de l'attaquant est de savoir quels autres sites l'utilisateur a visités. Un attaquant pourrait vouloir le savoir pour plusieurs raisons. Peut-être qu'il est intéressé par les requêtes de recherche de l'utilisateur, ou qu'il essaie de savoir où cette personne travaille, ou peut-être qu'il veut savoir si cette personne visite des sites "honteux" et ainsi de suite.



Comment un attaquant va-t-il faire cela si la seule chose qu'il contrôle est un site Web qu'il veut convaincre un utilisateur de visiter? Une façon possible consiste à utiliser des couleurs de lien. Comme vous le savez, si vous avez suivi un lien une fois, la prochaine fois, il apparaîtra dans votre navigateur dans une couleur différente, indiquant que vous avez déjà effectué la transition vers ce lien. Il s'agit en fait d'une vulnérabilité de sécurité.

Parce que cela signifie que sur votre site, un attaquant peut générer une énorme liste d'URL possibles que vous pourriez visiter, puis utiliser JavaScript pour voir la couleur acquise par ces URL. Et si la couleur du lien URL est violette, cela signifie que vous avez visité ce site. .

, URL-. , , . , , URL- , ? , . , , URL — cnn.com, Facebook.com . , . , .

, , , : «, , !», .



Covert channel attack? , JavaScript . JavaScript , , . , . , , JavaScript , . , , ? , .

, , — . – , .

, , . , , .



, — , , , , , . , , , , . ?

, . . , .

, Google Map Tiles. , «» Google Map, , , , . .

? , . , , , . , .

, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .



: JavaScript .

: , !

: , , , , ?

: , . , — - , , , - URL. , API– , .

: - , , ?
:vous avez absolument raison. Je pense que l'API de partage d'écran est une mauvaise idée. Mais je ne suis pas le président du monde, que puis-je faire? D'une manière ou d'une autre, les attaques basées sur DNS fonctionnent même si la mise en cache échoue.

Alors, que se passe-t-il si nous utilisons uniquement les adresses IP source de tous nos hôtes? Nous ne cachons rien! Et nous passons à un navigateur mis à jour qui ne fournit pas de couleurs de lien pour JavaScript. Donc tout est en ordre chez nous. Mais je suis là pour dire que tu ne vas pas bien! Parce qu'en fait, un attaquant peut profiter de la capacité d'attaque de rendu.

L'idée principale ici est de rendre plus rapidement l'URL que vous avez visitée plus tôt.

       <iframe>,    , ,   , , , ,    ,        <iframe>.     <iframe> ,   ,   <iframe>      .       ,    origin,        . 

Ainsi, l'attaquant ne peut plus rien toucher et conclut qu'il a pu déterminer le site que vous avez précédemment visité.

Rendez-vous à la prochaine conférence!


La version complète du cours est disponible ici .

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander ici .

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?