Le service Web HTTPS est passé à HTTP. Qu'est-ce qui peut mal tourner?
J'ai récemment visité un site Web qui avait une connexion HTTPS. Maintenant, il a juste une connexion HTTP simple, et la méthode d'authentification est passée de utilisateur + mot de passe à "authentifier avec un compte Google".
Je les ai contactés et leur ai demandé pourquoi ils avaient abandonné le HTTPS, et ils m'ont dit "car maintenant l'authentification est sécurisée avec Google, donc ce n'est plus nécessaire".
Eh bien, je ne suis pas un expert en sécurité, mais avant de leur répondre, je voudrais savoir: qu'est-ce qui pourrait mal tourner?
Donc, avec mon peu de connaissances, je dirais (corrigez-moi si je me trompe):
- Perte de confidentialité dans les communications entre le client et le serveur (l'attaquant peut lire toutes les informations échangées, y compris les informations personnelles que le client peut publier sur le serveur).
- Un attaquant pourrait modifier les requêtes du client, peut-être avec des intentions malveillantes.
- Un attaquant pourrait lire le cookie et l'utiliser pour accéder au service comme s'il s'agissait du client qui s'était authentifié à l'origine à l'aide des services de Google.
Ai-je raison? Quoi d'autre pourrait mal tourner?
Vous avez raison, la régression vers HTTP est inutile.
Notez que tous vos points s'appliquent à un type d'attaque particulier, où l'adversaire peut accéder au transport de données entre le client et le serveur. Cela pourrait être le propriétaire d'un hotspot WiFi ou votre FAI agissant en tant que homme au milieu , qui siège entre vous et le serveur. Cela peut être difficile à réaliser pour un attaquant distant, mais c'est particulièrement facile sur un WiFi public.
Ce que [~ # ~] https [~ # ~] ajoute à HTTP est un transport de données sécurisé . L'application Web elle-même peut être parfaitement adaptée - si vous communiquez sur un canal non chiffré, l'attaquant pourra lire, modifier et injecter des données arbitraires dans vos demandes et les réponses du serveur. Avec un cookie de session capturé, il sera également possible de vous faire passer pour aussi longtemps que le cookie est valide.
Ce que l'attaquant ne peut pas faire, c'est reprendre votre compte Google ou se réauthentifier auprès de Google ultérieurement. En effet, l'authentification avec Google se produit toujours via SSL et le jeton accordé expire après un certain temps.
La situation est donc un peu meilleure que de saisir immédiatement vos informations d'identification. Cependant, comme vous l'avez dit, un attaquant pourrait toujours reprendre la session et effectuer n'importe quelle action en votre nom.
Je voudrais poser la question suivante:
Quel est l'intérêt d'avoir une authentification dans l'application?
Si tout le contenu de la page est un contenu public et vérifiable de manière externe (par exemple, un miroir Debian, où les paquets sont avec PGP) et vos utilisateurs ne le font pas ' Si un tiers examine attentivement ce qu'il visite, la page n'a peut-être pas besoin de https. Mais pas un login non plus.
Les raisons courantes pour lesquelles une authentification est requise incluent:
Il y a des données que l'utilisateur ne peut lire que lorsqu'il est connecté
Un utilisateur enregistré peut envoyer des messages à d'autres personnes
Il permet à l'utilisateur de gagner en réputation, en conservant une identité qui n'est utilisée que par lui
Le compte peut bénéficier de certains avantages obtenus à l'extérieur (comme l'accès à du contenu payant)
Tous sont vaincus en utilisant http au lieu de https dans la communication, ainsi que presque toute autre raison pour insérer un identifiant. Indépendamment du fait que le mot de passe ne soit pas exposé (ce qui serait encore pire).
Il y a quelque temps, le prix d'achat des certificats a été discuté, mais de nos jours, plusieurs autorités de certification fournissent des certificats gratuitement.
† Le coin de Nitpicker, il y a quelques cas extrêmement rares où la sécurité n'est pas compromise par cela. Un exemple est Mega, qui a chargé certains javascripts courants via http, mais un script chargé par https a vérifié leurs hachages avant de les exécuter. Fragile et plus complexe que de configurer https partout. N'essayez pas cela à la maison, les enfants.
Vos informations d'identification sont en sécurité, mais le détournement de session peut se produire
Une possibilité aurait pu être qu'un attaquant ait effectué une attaque SSL Strip en agissant en tant qu'homme au milieu. Si cela se produit, le site Web HTTPS sera servi en HTTP à la victime. Mais comme vous avez confirmé sur le site Web qu'ils l'ont fait intentionnellement, cette possibilité est donc supprimée.
Maintenant, Google utilise oAuth2, donc la prise de contact avec Google se fera via HTTPS et vous serez redirigé vers votre site Web via HTTP après cela (cela se passe de la même manière avec https://security.stackexchange.com/ lorsque vous utilisez votre compte Google). Votre site Web aurait généré un jeton de session après oAuth. Le risque que HTTP présente dans ce cas est qu'un attacheur peut très facilement détourner votre session et surfer sur le site en se faisant passer pour vous
Tu as complètement raison. En excluant les informations de connexion Google, un attaquant peut effectuer une attaque MITM et intercepter toutes les demandes des victimes. Je vous propose de leur communiquer les risques et de réimplémenter le protocole SSL.
"Ce qui peut mal tourner": si vous le faites avec une API, toutes les applications iOS conçues pour iOS 9 et fonctionnant sur iOS 9 utilisant cette API cesseront de fonctionner.
Cela s'appelle "App Transport Security", et à moins que le développeur ne crée une exception pour votre domaine, http n'est pas accepté et https avec des connexions pas suffisamment sécurisées n'est pas accepté. Étant donné que votre API utilisait https, les applications existantes n'auront pas d'exception pour votre domaine, elles cesseront donc de fonctionner.