Université d'État d'Adams. Comment pirater des sites Web. Partie 1Parlons de notre prochaine attaque. Je vais vous dire comment les serveurs vous identifient. Pour ce faire, le protocole HTTP est utilisé entre le navigateur et le serveur sans enregistrer l'état, lorsque la communication avec le serveur se produit par des paires requête-réponse indépendantes. Par conséquent, le serveur vous oublie dès que la connexion est établie et lors de la prochaine session, il ne se souvient plus de qui vous êtes.
Cependant, il se souvient de vous lorsque vous utilisez l'application Web, car lorsque vous mettez des choses dans le panier que vous souhaitez acheter, vous pouvez continuer à magasiner et revenir pour voir le contenu de votre panier. L'implémentation de la "mémorisation" se fait à l'aide de cookies d'identification de session. Dès que vous vous connectez au serveur, il génère un cookie, qui est une séquence unique de lettres et de chiffres, et l'envoie à votre navigateur, qui stocke ce cookie localement sur votre ordinateur. Après cela, le navigateur renvoie des cookies au serveur avec chacune de vos demandes pour une seule session. En recevant ces cookies, le serveur comprend quel type d'utilisateur y accède avec cette demande. Il s'agit de la manière la plus courante d'identifier l'utilisateur qui utilise l'application Web.
Le type d'attaque suivant est appelé scriptage intersite, XSS. L'idée derrière cette attaque est qu'un attaquant force un site Web à afficher du code malveillant, généralement sous la forme de JavaScript, qui est ensuite exécuté dans le navigateur de l'utilisateur. Une telle attaque peut poursuivre n'importe quel but, mais est le plus souvent utilisée pour obtenir l'identifiant de session de la victime. La valeur de l'ID de session est qu'il peut être considéré comme un mot de passe, car il vous identifie. En capturant l'identifiant de session, un attaquant peut se déguiser en utilisant un serveur proxy pour communiquer avec le serveur cible. Les objectifs d'une telle attaque peuvent être le désir de parler en votre nom, d'automatiser certaines actions, par exemple le spamming, en votre nom ou d'introduire un virus.
Lorsque vous recherchez une vulnérabilité de script intersite XSS dans une application Web, vous recherchez un champ de saisie où vous pouvez mettre des informations, les envoyer au serveur et voir quel résultat sera affiché dans la fenêtre du navigateur.
J'entre par erreur l'emplacement du bâtiment, indiquant Plachy Hall, l'adresse de la salle de l'équipe de basket de notre université. Le serveur web reçoit ces informations et comprend que le professeur d'informatique est un "nerd" qui ne peut pas vivre sur le site d'une équipe sportive et donne un message d'erreur: "Plachy Hall a tort"!
Les zones de recherche sont les plus vulnérables à cet égard, où vous pouvez entrer des termes plutôt obscurs et voir ce que vous obtenez en retour. Le plus souvent, vous obtenez un indice répertoriant les options correctes possibles dont un attaquant pourrait profiter.
La prochaine chose que vous devez faire est de vérifier si vous pouvez injecter votre code malveillant, puis l'exécuter. Nous allons essayer d'organiser une attaque XSS en utilisant JavaScript.
Le code JavaScript se distingue toujours en ouvrant et en fermant la balise de script, ainsi que l'opérateur OR. Les développeurs d'applications ne sont pas complètement stupides, ils ont donc mis en place un mécanisme de filtrage appelé «désinfection». Il s'intègre dans le code, vérifie s'il y a des caractères dangereux et les supprime chaque fois que possible. Le test de désinfection JavaScript le plus simple ressemble à ceci:
<script>alert(“Testing”)</script>
Mais les pirates sont un peu plus intelligents, ils ont donc
ha.ckers.org/xss.html . Je n'ai pas le temps de vous montrer ce site, mais vous y trouverez les moyens les plus sophistiqués de contourner les contrôles que les développeurs d'applications ont essayé d'insérer dans leurs programmes pour supprimer les caractères dangereux. Il existe donc des moyens assez intelligents qui permettent à un pirate d'accéder à l'application.
Parlons donc du déroulement de l'attaque XSS. Nous avons un serveur Web pour les «pages facultaires», où nous allons saisir le code malveillant. Nous avons Eve, qui va pirater, mais nous avons raté quelque chose sur cette diapositive - nous avons oublié la victime. Ce qui est bien avec une attaque XSS, c'est que vous n'avez pas besoin d'embaucher quelqu'un pour le faire. Je veux dire, cette fois, je ne vais pas être une victime, car Eva a mon mot de passe et elle peut faire tout ce qu'elle veut avec mon compte. Par conséquent, Eve quitte le grand jeu et ne poursuit plus les petits garçons. Emmenons notre victime sur scène (rires du public, car une photo d'un des professeurs apparaît sur la diapositive).
Maintenant que la victime a pris sa place, voyons comment se développe l'attaque. Supposons qu'Eve ait réussi à héberger le code JavaScript malveillant sur le serveur où notre victime va entrer en utilisant son compte.
C'est important, car dès que la victime se connecte au serveur, elle recevra un identifiant de session qu'Eva tentera d'intercepter, c'est une partie très importante de l'attaque. Ainsi, la victime demande une page Web contenant du code JavaScript malveillant, ce code s'exécutera dans le navigateur de la victime et enverra à Eva l'identifiant de session.
Après avoir reçu l'identifiant de session, Eve peut utiliser son serveur proxy et faire tout ce qu'elle veut, se déguisant en victime. La seule pièce manquante de la mosaïque est le JavaScript malveillant lui-même, que le pirate doit insérer dans la page et qui doit capturer notre ID de session victime et le transmettre à l'attaquant.
C'est très simple. Nous avons du code JavaScript qui commence et se termine par l'ouverture et la fermeture de la balise:
<script>
La première ligne de code crée une image de la même manière qu'en JavaScript, une image est créée dynamiquement pour n'importe quelle page. Vous savez qu'au cœur de toute image se trouve un fichier qui contient l'image, nous devons donc indiquer au navigateur où aller pour obtenir cette image. Cela est indiqué dans la deuxième ligne, où se trouve le lien vers le site du pirate, mais le navigateur pense que c'est exactement l'endroit où se trouve l'image souhaitée. Il ira sur le site Web d'Eve et demandera document.cookie, car il pense que c'est le fichier image dont il a besoin.
Mais ce n'est pas du tout un fichier image, mais un identifiant de session que nous essayons de capturer en utilisant JavaScript. Comme vous pouvez le voir, obtenir un ID de session est assez simple. La troisième ligne, qui n'est pas utilisée dans le code pour effectuer une attaque XSS, contient une alarme qui déclenche une fenêtre contextuelle dans le navigateur avec un message d'attaque. Ceci est fait spécifiquement pour notre exemple, car une véritable attaque XSS se produit complètement inaperçue par la victime.
Alors, invitons Eve et voyons comment elle attaquera les scripts intersites.
Eve Hacker: Merci Dr Loveland! La première chose que je dois faire est de fermer certaines choses dont nous n'avons pas besoin. Nous n'avons plus besoin du proxy Burp Suit, donc je le ferme. Deuxièmement, je dois reconfigurer le navigateur Web et le basculer pour utiliser les paramètres du système proxy par défaut.
Passons maintenant à la page de connexion du site Web du Dr Loveland, car si vous vous en souvenez, j'ai son mot de passe et je peux accéder au site à tout moment à sa place. Comme je l'ai mentionné, le Dr Loveland est assez paresseux, elle utilise un certificat SSL expiré, je dois donc confirmer les exceptions de sécurité pour accéder à la page de connexion. Puisque je connais le mot de passe, je peux éditer sa page Web. Comme nous le savons déjà, sur la page d'édition des informations personnelles, il existe une vulnérabilité dans la ligne Building Location, "Building Location", et c'est ici que je vais saisir mon code JavaScript malveillant.
J'ai simplifié cette attaque, donc en réalité je n'enverrai pas le code au serveur, mais à la place j'appellerai une fenêtre pop-up avec un message que quelqu'un essaie de m'attaquer. Maintenant que j'ai préparé le terrain pour l'attaque, je vais revenir à la page d'autorisation et me déconnecter. Il ne vous reste plus qu'à attendre qu'une victime apparaisse qui souhaite utiliser cette application.
(Eve met une casquette de baseball, se faisant passer pour le professeur Stephen Eldridge)
Je reviens tout juste d'une réunion fascinante où, pendant les heures creuses, nous avons discuté de la voiture à accorder en priorité sur le parking - une Subaru ou une Jeep, puis il nous est apparu que la différence pouvait être un toit ouvrant dans la voiture. Alors maintenant, je dois me connecter et vérifier mes coordonnées, car je ne voudrais pas manquer la prochaine réunion «hors classe» car mes données n'étaient pas disponibles. Je me connecte donc à mon application web sous le login saldrich et mon mot de passe.
Donc, tout semble comme d'habitude, je ne vois rien de mal sur ma page en tant que professeur de mathématiques, toutes les coordonnées sont en ordre.
Oh mon dieu, ma montre montre qu'il ne reste que 2 minutes avant la prochaine réunion! Maintenant, je vais rencontrer le Dr Loveland, donc je dois aller sur sa page et voir si je peux creuser un peu de saleté sur elle pour le mentionner lors de la réunion. Alors, je clique sur le lien Susan Loveland, j'arrive à sa page et ... Dr. Eldridge, votre page est piratée!
(Le professeur Eldridge enlève sa casquette de baseball, se transformant en Eve)
Maintenant que j'ai votre identifiant de session, je peux utiliser mon serveur proxy et me déguiser en vous, Dr Eldridge, en faisant ce que je veux en votre nom. Je vous donne la parole, Dr Loveland!
Susan Loveland: merci, Eve! Je voulais mentionner que notre application de page de faculté a été développée sur la base de l'un des plus récents frameworks Web - Python Django Web Framework, qui dispose d'un excellent système de désinfection des données d'entrée qui supprime les caractères dangereux du code JavaScript. Par conséquent, afin qu'Eve puisse mener son attaque, j'ai exclu de vérifier la valeur du champ Emplacement du bâtiment pour la présence de tels personnages.
Quelle est la réussite des attaques de script intersite? Environ 80 à 90% des sites Web disposent d'un mécanisme de gestion des vulnérabilités côté client. Le fait de ne pas résister aux attaques XSS est la vulnérabilité la plus courante des applications Web 2.0 qui interagissent davantage avec les utilisateurs finaux.
Vous avez probablement entendu parler d'un des scripts de cross-site Samy les plus célèbres, dont l'auteur Sami Kamkar a inventé en 2005, comment contourner le filtrage d'entrée du réseau social MySpase. Il a placé JavaScript sur sa page, tout comme Eve l'a fait avec ma page. Ce script a fait 2 choses: a ajouté Samy comme ami à la victime et s'est copié sur la page de profil de la victime. Au début, cette attaque s'est déroulée très lentement, car seules quelques personnes sont allées sur la page de Samy et sont devenues amies, mais progressivement le virus s'est propagé de plus en plus et l'infection a commencé à se développer comme une avalanche. Cet exemple était illustratif en termes de capacités de l'attaque XSS, car plus d'un million de demandes d'amis en quelques heures ont fait planter MySpase. Ainsi, les conséquences de ces attaques peuvent être assez graves.
Le dernier type d'attaque dont je veux parler aujourd'hui est les attaques de contrôle d'accès, ou attaques d'accès. Avec une telle attaque, le pirate souhaite obtenir des informations auxquelles il n'a pas accès. Il existe plusieurs vulnérabilités ciblées par le vecteur d'attaque d'accès.
Souvent, les développeurs d'applications oublient qu'ils ont laissé des fichiers dans le répertoire racine d'un document sur un serveur Web, et si vous pouvez détecter leur existence, vous pourrez voir ces fichiers, qui contiennent souvent des informations confidentielles.
Une autre façon de trouver la vulnérabilité est de regarder très attentivement l'URL. Par exemple, si vous voyez une adresse de ce formulaire
app.com/ViewDoc.php?docid=1280149120 , vous pouvez facilement rechercher les numéros à la fin du lien pour obtenir un document qui n'est pas destiné à vos yeux.
De nombreuses applications sont conçues pour différents niveaux d'utilisateurs et elles disposent d'un mécanisme d'accès intégré qui est souvent basé sur des demandes avec les paramètres suivants
app.com/login/home.jsp?admin=false , vous pouvez donc essayer d'entrer sur le site en utilisant le remplacement d'adresse dans la ligne à admin = true.
En fait, la vulnérabilité de contrôle d'accès la plus courante est l'implémentation incorrecte de la fonction d'autorisation. Maintenant, Eve va le démontrer.
Eve Hacker: Merci, docteur Loveland. Pour effectuer la dernière attaque, il vous suffit de regarder très attentivement l'URL de notre application web. Maintenant, je vais agrandir la fenêtre de l'application afin que la ligne avec l'adresse sur la page du Dr Loveland s'adapte complètement à l'écran. Je dois me débarrasser de ce JavaScript ennuyeux que j'ai installé.
Nous voyons que l'adresse de la page du Dr Loveland est
localhost / SampleSite / Faculty / index-1.html , et si nous passons à la page du Dr Eldridge, alors l'adresse sera
localhost / SampleSite / Faculty / index-2.html .
Ne pensez-vous pas que le même modèle est utilisé ici? Cependant, ces lignes d'adresse ne m'intéressent pas, car elles n'ont pas la possibilité de saisir des informations. Je souhaite donc accéder au formulaire de connexion du Dr Loveland. Si je me connecte sous son nom, je peux modifier ses informations personnelles. Mais regardons l'URL de la page, à la fin de laquelle se trouve IndexForm-1, et vous pouvez deviner qu'il est peut-être possible d'accéder au formulaire de données du Dr Eldridge.
Donc, la question est de savoir si nous pouvons accéder à son formulaire sans vous connecter en son nom. Essayons. Je change l'unité en deux pour que l'adresse prenne la forme
localhost / SampleSite / Faculty / indexForm-2.html ,
appuyez sur Entrée et une page contenant les informations personnelles du Dr Eldridge apparaît.
Devant nous se trouve un bogue que les étudiants du Dr Loveland ont oublié de corriger - l'application a une vulnérabilité qui lui permet de pénétrer la page de quelqu'un d'autre sans entrer le login de la victime.
Le Dr Eldridge est une personne très gentille, je ne voudrais pas l’ennuyer, je n’ai rien contre lui, mais pour rire, je vais laisser quelque chose sur sa page. Permettez-moi de déformer son nom et son prénom, et en même temps de corriger la position de "Professeur" à "Professeur débutant".
Maintenant, j'enverrai les informations personnelles corrigées au serveur, et si maintenant j'entre dans la page Eldridge, alors vous pouvez voir les corrections que j'ai apportées.
Donc, Dr Loveland, si vous avez des problèmes avec le Dr Eldridge quand il décide de vous détenir après les conférences, dites-le moi et je supprimerai toutes ses informations!
Susan Loveland: Merci pour le soutien, Eve! Je veux parler de la vulnérabilité de contrôle d'accès pendant une seconde. Pour les personnes qui, comme moi, aiment se plonger dans le code, je vais vous expliquer ce qui s'est passé lors de cette attaque.
Cette diapositive montre comment remplir un formulaire avec des informations personnelles. La dernière ligne est exactement ce qui a intéressé Eve. Cette classe protège form_index des fonctions rapides @ login-required et @authUser et vérifie que toute personne qui souhaite modifier les valeurs dans les champs du formulaire doit se connecter au système pour cela. Cependant, les développeurs ont oublié cela et n'ont pas ajouté la mention obligatoire de ces fonctions rapides dans le cadre du remplissage du formulaire.
Le code affiché vérifie si le formulaire demandé correspond à la personne qui s'est connectée au système, mais comme il n'a pas été utilisé correctement, Eve a pu détecter cette vulnérabilité dans l'application.
Je note que 78% de tous les sites ont des vulnérabilités d'accès. En avril dernier, certains pirates ont découvert une vulnérabilité sur le campus universitaire de Berkeley - il s'agissait de fichiers cachés que les développeurs ont laissés sur le serveur de documents du serveur Web. Les pirates ont pu consulter ces fichiers et obtenir des numéros de sécurité sociale et des informations médicales confidentielles pour plus de 160 000 personnes. Vous voyez donc à quel point les conséquences d'une attaque de contrôle d'accès peuvent être graves.
Je voudrais mentionner quelques faits plus intéressants dans le contexte du sujet de notre conversation d'aujourd'hui. Récemment, l'attention du gouvernement à la cybersécurité a fortement augmenté. Ainsi, rien qu'en 2008, le ministère de la Défense a enregistré plus de 360 millions de tentatives de piratage. Environ 75,8 milliards de dollars devraient être consacrés à l'amélioration du système de cybersécurité dans le domaine des technologies de l'information en 2010, soit 7,2% de plus que ce qui a été dépensé pour ces objectifs en 2009. Selon CNN Money Magazine, aux États-Unis, en 2009, les spécialistes de la sécurité Internet figuraient parmi les professions les plus recherchées. Le revenu annuel moyen des consultants dans le domaine de la sécurité informatique s'élève à 99,7 milliers de dollars, le maximum - 152 milliers de dollars. Selon les prévisions, le besoin de tels spécialistes de 2006 à 2016 augmentera de 27%.
Je tiens à dire que la Faculté des sciences informatiques a récemment eu la possibilité d'obtenir un diplôme d'associé en informatique Internet et sécurité des réseaux, c'est donc un excellent point de départ pour commencer une carrière dans ce domaine.
(met un chapeau noir)
Eve Hacker: Je veux vous interrompre un instant, Dr Loveland! Pour les futurs enseignants présents dans ce public, je note que si vous maîtrisez cette spécialité et que vous vous retrouvez un jour dans une situation où vous ne recevez pas l'augmentation de salaire promise, vous pouvez toujours vous tourner vers la mafia et effectuer un hack de contrat pour eux. Ce sera une excellente augmentation du salaire d'un professeur d'informatique.
(enlève son chapeau)
Susan Loveland: Je tiens à remercier les personnes qui ont apporté une contribution sérieuse à la création de la présentation d'aujourd'hui, les développeurs des «pages facultaires». Je pense que grâce à leur travail acharné, je pourrai quitter ce public sans les menottes et l'escorte de la police du campus. Le seul membre "survivant" de ce groupe est Ryan Goldsworthy, qui a joué un rôle important dans le développement de ces pages. Je tiens à remercier le Dr Stephen Eldridge pour son sens de l'humour et pour avoir soumis une page personnelle pour démontrer les attaques, pour remercier les chefs de département qui ont généreusement contribué à mon projet Faculty Pages, et aussi pour remercier le campus Computer Computing Service de nous avoir protégés de telles des gens comme Eve.
Merci de votre attention.
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'au printemps gratuitement lors du paiement pendant
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?