Cette réponse concerne plus la déclaration de Chris Dixon que la réponse "Combien d'attaques proviennent de MiTM".
Si nous affirmons la manière différente dont on pourrait devenir MiTM et les conséquences données, je pense que nous pouvons tirer des conclusions pour savoir si nous nous soucions ou non de la prévalence des attaques MiTM.
Si nous examinons certains risques pour les différentes situations, nous pourrions avoir quelque chose comme:
- Quelqu'un vole la base de données en exploitant l'application Web elle-même?
- Quelqu'un qui attaque un utilisateur / administrateur via une attaque MiTM
Je dirais que le premier a un impact beaucoup plus important (généralement) et devrait à bien des égards être atténué le plus et traité le premier.
Donc, pour que le point 2 l'emporte sur le point 1, je pense que MiTM devrait vraiment être fou pour que nous le valorisions aussi haut qu'un obstacle de sécurité que le point 1 (comme Chris l'indique dans la citation)!
Maintenant, si nous voyons les différents vecteurs d'attaque. D'abord pour MiTM. Pour devenir MiTM, on pourrait par exemple:
- Posséder un point d'accès sans fil non autorisé. C'est trivial, mais pour une attaque ciblée, vous devez être au même emplacement physique que la victime en utilisant votre application Web.
- Sniffer les données sans fil non chiffrées ou les données transitant par un HUB (elles existent même plus?)
- Utilisez l'empoisonnement ARP pour attaquer les utilisateurs. Pas anodin, sauf si vous êtes sur le même réseau que les utilisateurs ciblés utilisant votre application Web.
- Empoisonnement du cache DNS. Pour que cela fonctionne, vous devez empoisonner le DNS utilisé par les utilisateurs ciblés. Si le DNS n'est pas correctement configuré, cette attaque devient quelque peu triviale à effectuer, mais il y a beaucoup de choses sur lesquelles compter pour que cela fonctionne.
- Attaques de phishing. Ceux-ci trompent toujours les utilisateurs naïfs et sans méfiance, mais une grande partie de la responsabilité incombe à l'utilisateur.
Tout cela pour attaquer juste un ou un petit sous-ensemble d'utilisateurs. Même dans ce cas, attaquer ces utilisateurs leur donnera un avertissement dans leurs navigateurs (il existe également des moyens d'attaquer cela, mais je ne parle pas ici). Ce n'est qu'en compromettant une autorité de certification racine ou en trouvant une faille dans l'algorithme utilisé pour générer les certificats que vous seriez autorisé à vous faire passer pour un émetteur de certificats de confiance.
Si, d'un autre côté, nous examinons tous les méchants potentiels des choses que nous pouvons voir si nous n'investissons pas suffisamment dans la sécurité de l'application Web elle-même, nous voyons des vecteurs d'attaque comme:
- Injection SQL - triviale et facile à exploiter et à découvrir. Impact des dégâts très élevé.
- XSS (Cross Site Scripting) - facile à découvrir, plus difficile à exploiter. Je pense que cela aura un impact de plus en plus important sur les utilisateurs à l'avenir. Je prévois que cela devient la "nouvelle tendance d'injection SQL" que nous avons vue dans le passé.
- CSRF (Cross Site Request Forgery) - Modéré à découvrir, modéré à exploiter. Cela exigerait que les utilisateurs accèdent à un site déjà possédé, déclenchant une demande à votre application Web qui ferait une transaction au nom de l'utilisateur.
Donc, en mentionnant simplement ces quelques méthodes, mais populaires, à la fois pour attaquer une application Web et devenir MiTM, je laisserais le soin à une analyse spécifique des risques / conséquences de l'organisation donnée que vous essayez de sécuriser , que vous deviez ou non défendre vos utilisateurs directement en implémentant SSL ou en défendant l'application Web dans son ensemble (qui comprend également la propriété intellectuelle, les données utilisateur, les données sensibles, les données potentielles qui pourraient violer d'autres applications, etc.).
Donc, à mon humble avis, je suis tout à fait d'accord avec la déclaration de Chris Dixon. Donnez la priorité à la sécurisation de l'application Web autant que vous le pouvez avant de commencer à penser à sécuriser la couche de transport.
Modifier :
Sur une note latérale: des pages comme Facebook, Gmail et d'autres ont subi de lourdes attaques MiTM au lendemain de Firesheep. Cela ne pouvait être atténué que par SSL et la sensibilisation.
Cependant, si vous y réfléchissez, renifler le trafic sans fil avec Firesheep et détourner les sessions exigerait que le LAN sans fil auquel vous êtes connecté ne dispose d'aucun cryptage.
Quand je fais la guerre aujourd'hui, cela a considérablement réduit le nombre de points d'accès sans fil ouverts et également le nombre de points d'accès compatibles WEP. Nous voyons de plus en plus de points d'accès cryptés WPA2 qui, dans la plupart des cas, nous fournissent une sécurité suffisante.
Maintenant, quel est le risque que quelqu'un crée un outil simple et pratique pour renifler et détourner les sessions de vos utilisateurs? Quel est l'impact pour ces utilisateurs? Cela pourrait également être atténué de différentes manières (ré-authentifier l'utilisateur lorsqu'il provient de différentes empreintes en même temps, avertir l'utilisateur lorsque quelque chose ne va pas (gmail en est un bon exemple)).