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

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

Par exemple, Django prendra ces crochets angulaires, les traduira au format HTML et refera le reste des caractères. Autrement dit, si la valeur de nom personnalisé contient des crochets, des guillemets doubles, etc., tous ces caractères seront exclus. Cela fera que le contenu ne sera pas interprété comme du code HTML du côté du navigateur client.



Alors maintenant, nous savons que ce n'est pas une défense très fiable contre certaines attaques de script intersite. La raison, comme nous l'avons montré dans l'exemple, est que ces grammaires pour HTML, CSS et JavaScript sont si complexes qu'elles peuvent très facilement confondre l'analyseur du navigateur.

Par exemple, nous avons une chose très courante faite dans le cadre de Django. Donc, vous avez une fonction div, et nous voulons lui attribuer une classe dynamique. Nous donnons à la classe la valeur de var, et ainsi de suite. L'idée est que lorsque Django traite cela, il doit comprendre quel est le style actuel et le coller ici.

Dans ce cas, un attaquant peut créer une chaîne définissant cette classe, par exemple, écrit «classe 1». Tout va bien jusqu'à ce point, car cela semble être une expression CSS valide.

Mais l'attaquant place ici l'opérateur onclick, qui est égal au code JavaScript qui effectue l'appel système.



Comme c'est faux, le navigateur devrait s'arrêter ici. Mais le problème est que si vous avez déjà vu le code HTML d'une vraie page Web, tout est cassé et confus, même pour des sites légitimes et "conviviaux". Donc, si le navigateur s'arrête avant chaque expression HTML erronée, pas un seul site que vous aimez ne fonctionnera tout simplement jamais. Si jamais vous voulez être déçu du monde et que je ne vous ai pas suffisamment aidé, ouvrez simplement la console JavaScript dans votre navigateur lorsque vous consultez le site pour voir combien d'erreurs cela vous donnera.

Vous pouvez, par exemple, aller sur CNN et voir simplement combien d'erreurs vous obtenez. Oui, essentiellement CNN fonctionne, mais de manière très inégale. Par exemple, pour ouvrir Acrobat Reader, vous devez constamment lever des exceptions de pointeur nul, et en même temps, vous vous sentirez un peu trompé par la vie. Mais sur Internet, nous avons appris à l'accepter sans trop d'indignation.
Par conséquent, comme les navigateurs devraient être très tolérants à de telles choses, ils essaieront de transformer le code malveillant en quelque chose qui leur semble raisonnable. Et c'est la vulnérabilité de sécurité.

Voilà comment fonctionne la désinfection du contenu, et c'est toujours mieux que rien. Elle peut attraper beaucoup de choses nuisibles, mais ne peut pas se défendre de tout.

Il y a encore une chose à laquelle penser: l'utilisation d'un langage de balisage moins expressif. Voyons ce que cela signifie.

Public: que dois-je faire si le nettoyage de contenu ne fonctionne pas?

Professeur: oui, c'est possible, par exemple, dans ce cas Django ne sera pas en mesure de déterminer statiquement que c'est mauvais. Par exemple, dans ce cas particulier. Mais dans le cas où j'insère une balise d'image malveillante ...

Public: dans ce cas particulier, je m'attendrais à ce que l'affectation de classe soit entre guillemets et dans ce cas ne devrait avoir aucun effet ...

Professeur: eh bien, vous voyez, il y a de petites astuces. En supposant que la grammaire du HTML et du CSS soit soigneusement définie, vous pouvez imaginer un monde dans lequel des analyseurs idéaux pourraient en quelque sorte attraper ces problèmes ou les transformer en quelque chose de normal. Mais en fait, la grammaire HTML et la grammaire CSS souffrent d'inexactitudes. De plus, les navigateurs n'implémentent pas de spécifications. Par conséquent, si vous utilisez une grammaire moins expressive, il nous sera beaucoup plus facile de désinfecter le contenu.

Ici, le terme Markdown est utilisé - «balisage facile à lire» au lieu du terme Markup - balisage ordinaire. L'idée principale de Markdown est qu'il est conçu comme un langage qui, par exemple, permet aux utilisateurs de publier des commentaires, mais ne contient pas la possibilité d'utiliser une balise vide, la prise en charge des applets, etc. Par conséquent, dans Markdown, il est en fait beaucoup plus facile d'identifier de manière unique la grammaire, puis de l'appliquer.



La désinfection est beaucoup plus facile dans un langage simple qu'en HTML, CSS et JavaScript. Et d'une certaine manière, c'est comme la différence entre la compréhension du code C et du code Python. Il y a vraiment une grande différence dans la compréhension d'un langage plus expressif. Par conséquent, en limitant l'expressivité, vous améliorez souvent la sécurité.

Pour se protéger contre les attaques de scripts intersites, CSP, Content Security Policy, est également utilisé. L'idée du CSP est qu'il permet au serveur web ...
Public: Je suis simplement curieux de découvrir ce langage Markdown. Tous les navigateurs sont-ils capables d'effectuer une analyse linguistique?

Professeur: non, non, non. Vous pouvez simplement convertir divers types de langues en HTML, mais les navigateurs ne les comprennent pas dans leur forme d'origine. En d'autres termes, vous avez un système de commentaires et il utilise Markdown. Autrement dit, les commentaires, avant d'être affichés sur la page, vont au compilateur Markdown, qui les traduit au format HTML.

Public: alors pourquoi ne pas toujours utiliser Markdown?

Professeur: Markdown vous permet d'utiliser du HTML intégré, et pour autant que je sache, il existe un moyen de le désactiver dans le compilateur. Mais je peux me tromper à ce sujet. Le fait est qu'il n'est pas toujours possible d'utiliser un langage limité et que tout le monde ne veut pas le faire.

Continuons donc la discussion sur la façon d'augmenter la sécurité à l'aide de la politique de sécurité du contenu. Cette politique permet au serveur d'indiquer au navigateur Web quels types de contenu peuvent être chargés sur la page qu'il renvoie, ainsi que la provenance de ce contenu.

Par exemple, dans la réponse HTTP, le serveur peut utiliser quelque chose comme ceci: il inclut l'en-tête Content - Security - Policy, la source par défaut est self et il recevra les données de * .mydomain.com.



Avec l'opérateur lui-même, le serveur indique que le contenu de ce site ne doit provenir que du domaine d'une page particulière ou de tout sous-domaine de mydomain.com. Cela signifie que si nous avions une liaison automatique avec foo.com, le serveur renverrait cette page au navigateur.

Supposons qu'une attaque de script intersite essaie de créer un lien vers bar.com. Dans ce cas, le navigateur verra que bar.com n'est pas auto et n'est pas un domaine de mydomain.com, et n'ignorera pas cette demande plus loin. Il s'agit d'un mécanisme assez puissant où vous pouvez spécifier des contrôles plus détaillés. Vous définissez des paramètres indiquant que vos images doivent provenir de telle ou telle source, des scripts de telle ou telle et ainsi de suite. C'est en fait pratique.

De plus, cette stratégie empêche en fait le JavaScript intégré, vous ne pouvez donc pas ouvrir la balise, écrire une sorte de script et fermer la balise, car tout ce qui peut aller dans le navigateur ne doit provenir que d'une source conditionnelle. CSP empêche les choses dangereuses comme l'utilisation de l'argument de la fonction eval (), qui permet à une page Web d'exécuter du code JavaScript généré dynamiquement. Donc, si l'en-tête CSP est défini, le navigateur n'exécutera pas eval ().

Public: Est-ce que tout CSP protège contre?

Professeur: non. Il y a toute une liste de ressources qu'il protège réellement, et vous pouvez configurer la protection contre de nombreuses choses indésirables, par exemple, spécifier où il est autorisé à accepter les CSS sortants et un tas d'autres choses.

Public: Mais outre eval (), il y a d'autres choses qui menacent la sécurité?

Professeur: oui, ils existent. Par conséquent, la question se pose toujours de l'exhaustivité de la protection. Ainsi, par exemple, non seulement eval peut générer dynamiquement du code JavaScript. Il y a aussi un constructeur de fonctions, il y a certaines façons d'appeler un timeout donné, vous allez sur la ligne et vous pouvez analyser le code de cette façon. CSP peut désactiver tous ces vecteurs d'attaque dangereux. Mais ce n'est pas une panacée pour l'isolement complet des exploits malveillants.

Public: Est-il vrai que le CSP peut être configuré pour empêcher tous les scripts internes d'être vérifiés sur la page?

Professeur: oui, cela aide à empêcher l'exécution de code généré dynamiquement, tandis que le code intégré doit être ignoré. Le navigateur doit toujours obtenir le code de l'attribut source. En fait, je ne sais pas si tous les navigateurs le font. L'expérience personnelle montre que les navigateurs présentent des comportements différents.

En général, la sécurité Internet s'apparente aux sciences naturelles, donc les gens avancent simplement des théories sur le fonctionnement des navigateurs. Et puis vous voyez comment cela se produit réellement. Et la vraie image peut décevoir, car on nous apprend qu'il existe des algorithmes, des preuves, etc. Mais ces navigateurs se comportent si mal que les résultats de leur travail sont imprévisibles.

Les développeurs de navigateurs essaient d'avoir une longueur d'avance sur les attaquants, et plus loin dans la leçon, vous en verrez des exemples. En fait, CSP est une chose assez cool.

Une autre chose utile est que le serveur peut définir un en-tête HTTP appelé X-Content-Type-Options, dont la valeur est nosniff.



Cet en-tête empêche MIME de supprimer la réponse du type de contenu publié, car l'en-tête indique au navigateur de ne pas remplacer le type de contenu de la réponse. Avec l'option nosniff, si le serveur dit que le contenu est text / html, le navigateur l'affichera comme text / html.
Autrement dit, cet en-tête empêche le navigateur de «renifler» la réponse du type de contenu déclaré afin que la situation ne se produise pas lorsque le navigateur dit: «oui, j'ai reniflé le décalage entre l'extension de fichier et le contenu réel, donc je vais transformer ce contenu en un autre compréhensible moi une chose. " Il s'avère que vous avez soudainement donné aux barbares les clés du royaume.

Par conséquent, en définissant cet en-tête, vous dites au navigateur de ne rien faire de tel. Cela peut considérablement atténuer les effets de certains types d'attaques. Voici un bref aperçu de certaines vulnérabilités pour les attaques de script intersite.

Voyons maintenant un autre vecteur d'attaque populaire - SQL. Vous avez probablement entendu parler d'attaques appelées «injection SQL» ou attaque par injection SQL. L'essence de ces attaques consiste à utiliser la base de données du site Web. Pour créer dynamiquement la page affichée à l'utilisateur, des requêtes de base de données sont émises qui sont émises vers ce serveur interne. Imaginez que vous ayez une demande pour sélectionner toutes les valeurs d'une table spécifique, où le champ ID utilisateur est égal à ce qui est déterminé sur Internet à partir d'une source potentiellement non fiable.



Nous savons tous comment cette histoire se terminera - elle se terminera très mal, il n'y aura pas de survivants. Parce que ce qui vient d'une source non vérifiée peut causer beaucoup de problèmes. Vous pouvez également donner à la chaîne d'ID utilisateur la valeur suivante: id utilisateur = «0; SUPPRIMER LE TABLEAU “.

Alors que va-t-il se passer ici? Fondamentalement, la base de données du serveur dira: "OK, je mettrai l'ID utilisateur à zéro, puis j'exécuterai la commande" supprimer la table "". Et c'est tout, vous avez terminé!

Ils disent qu'il y a quelques années, une certaine image virale est apparue. Certaines personnes en Allemagne ont installé des plaques d'immatriculation sur les voitures, sur lesquelles 0 était inscrit; SUPPRIMER LE TABLEAU. L'idée était que les caméras routières utilisent l'OCR pour reconnaître votre numéro, puis le mettent dans la base de données. En général, les gens de Volkswagen ont décidé d'exploiter cette vulnérabilité en plaçant du code malveillant sur leurs numéros.

Je ne sais pas si cela a fonctionné parce que ça a l'air drôle. Mais je voudrais croire que c'est vrai. Je répète donc encore une fois - l'idée de la désinfection est d'empêcher l'exécution de contenu provenant de sources non fiables sur votre site.



Par conséquent, faites attention au fait qu'il peut y avoir des choses simples qui ne fonctionnent pas comme elles le devraient. Donc, vous pourriez penser: «eh bien, pourquoi ne puis-je pas simplement mettre une autre citation au début de la ligne et une autre à la fin pour exclure l'exécution de code malveillant de l'attaquant entre des guillemets triples»?

id utilisateur = '"+ id utilisateur +'"

Mais cela ne fonctionnera pas, car un attaquant peut toujours simplement mettre des guillemets à l'intérieur de la chaîne d'attaque. Donc, dans la plupart des cas, un tel "demi-piratage" ne vous apportera pas autant de sécurité que vous attendez.

La solution ici est que vous devez chiffrer soigneusement vos données. Et encore une fois, je répète que lorsque vous recevez des informations d'une source non fiable, ne les insérez pas dans le système sous la forme dans laquelle elles se trouvent. Assurez-vous qu'il ne peut pas sauter du bac à sable si vous le placez pour effectuer un exploit malveillant.

Par exemple, vous souhaitez insérer une fonction d'échappement pour empêcher l'utilisation de l'opérateur virgule brut. Pour ce faire, de nombreux frameworks Web, tels que Django, ont des bibliothèques intégrées qui vous permettent d'éviter les requêtes SQL pour empêcher de telles choses de se produire. Ces frameworks encouragent les développeurs à ne jamais interagir directement avec la base de données. Par exemple, Django lui-même fournit une interface de haut niveau qui vous désinfecte.

Mais les gens se soucient toujours des performances, et parfois les gens pensent que ces cadres Web sont trop lents. Ainsi, comme vous le verrez bientôt, les gens feront toujours des requêtes SQL brutes, ce qui peut entraîner des problèmes.

Des problèmes peuvent survenir si le serveur Web accepte des noms de chemin provenant d'images non fiables. Imaginez que quelque part sur votre serveur, vous faites quelque chose de similaire: ouvrez avec «www / images /» + nom de fichier, où le nom de fichier est représenté par quelque chose comme ... / ... / ... / ... / etc / mot de passe.



Autrement dit, vous donnez la commande pour ouvrir l'image à cette adresse à partir d'un fichier utilisateur non fiable, ce qui peut en réalité vous nuire gravement. Ainsi, si vous souhaitez utiliser un serveur Web ou un framework Web, vous devriez pouvoir détecter ces caractères dangereux et les éviter afin d'empêcher l'exécution de ces commandes non gérées.

Prenons une pause pour discuter de la désinfection du contenu et parlons un peu des cookies. Les cookies sont un moyen très populaire de gérer les sessions afin de lier un utilisateur à un certain ensemble de ressources qui existent côté serveur. De nombreux frameworks comme Django ou Zoobar, que vous rencontrerez plus tard, mettent en fait un identifiant de session aléatoire dans les cookies. L'idée est que cet identifiant de session est un index dans une sorte de table côté serveur:

table [ID session] = informations utilisateur.

Autrement dit, l'identifiant de session est égal à certaines informations utilisateur. En conséquence, cet ID de session et les cookies sont des éléments très sensibles dans leur extension. De nombreuses attaques incluent le vol de cookies afin d'obtenir cet identifiant de session. Comme nous en avons discuté dans notre dernière conférence, la même politique de la même source d'origine peut vous aider, dans une certaine mesure, contre certaines de ces attaques de vol de cookies. Parce qu'il existe des règles basées sur la même politique d'origine qui empêchent la modification arbitraire des cookies.

La subtilité est que vous ne devez pas partager un domaine ou un sous-domaine avec quelqu'un en qui vous n'avez pas confiance. Parce que, comme nous l'avons dit dans la dernière conférence, il existe des règles qui permettent à deux domaines ou sous-domaines de même origine d'accéder aux cookies l'un de l'autre. Et par conséquent, si vous faites confiance à un domaine auquel vous ne devriez pas faire confiance, il peut être en mesure de définir directement l'identifiant de session dans ces cookies, auxquels vous avez tous deux accès. Cela permettra à l'attaquant de forcer l'utilisateur à utiliser l'identifiant de session de son choix.



Supposons qu'un attaquant définisse un cookie utilisateur Gmail. Un utilisateur se connecte à Gmail et tape quelques lettres. Un attaquant peut alors utiliser ce cookie, notamment utiliser cet identifiant de session, télécharger Gmail, puis accéder à Gmail comme s'il était un utilisateur victime. Ainsi, il existe de nombreuses subtilités que vous pouvez faire avec ces cookies pour gérer vos sessions. Nous en discuterons aujourd'hui et dans des conférences ultérieures.

Peut-être pensez-vous que vous pouvez simplement vous débarrasser des cookies? Après tout, ils apportent plus de problèmes que d'avantages. Pourquoi ne peuvent-ils pas être abandonnés?

stateless cookie, « », - , , , .

, , , . , . , , . , , , , .

— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .



, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .



, AWS HTTP, .

, , , :

GET /photos/ cat; .jpg HTTP/1.1, - AWS:

HOST: — - — - — , , :

DATE: Mon, June 4, , , . , ID , , , .



? , 3- .

, String To Sign :

— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .



, , HCK MAC. , . , . , . ?

, , , - . Amazon , stateless cookie, MD5 .

, , , cookie, . – , , .

, . , , “HCK, m”.



Dans le monde ordinaire, les cookies seraient utilisés à la place de l'autorisation ici. Mais maintenant, nous nous débarrassons d'eux et insérons ce message en texte clair GET / photos / cat dans la demande; .jpg HTTP / 1.1 et chiffrement, qui permet au serveur de savoir de qui vient cette chose. De cette façon, le serveur sait qui est l'utilisateur car il est intégré à la demande. Ce n'est pas un secret, non? Mais cela permet au serveur de dire: "Oui, je sais quelle clé secrète cet utilisateur aurait dû utiliser pour créer cette demande, s'il s'agit d'un véritable utilisateur."

56:15

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


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?