Cas d'utilisation de la défense CSRF
Vous disposez d'un appareil intégré qui prend en charge l'interface utilisateur Web basée sur HTTP sur une adresse IP privée.
Est-il judicieux d'implémenter la défense CSRF sur HTTP (et non HTTPS) ?
Réponses
Si une requête HTTP est capable de changer d'état, elle peut avoir besoin d'une protection CSRF. Que la demande soit chiffrée ou non au niveau de la couche de transport n'a que peu ou pas de rapport avec cela.
Sans protection CSRF, un attaquant qui vous convainc de visiter son site Web ou même une seule ressource peut être en mesure d'envoyer des requêtes à votre appareil intégré et d'en prendre le contrôle, si le navigateur de la victime est correctement autorisé ou si l'authentification est insuffisante ou cassée. Cela se produit indépendamment du fait que HTTP ou HTTPS soient utilisés.
Oui, idéalement tout serait sur HTTPS. Cependant, la "meilleure" option pour la plupart des fournisseurs à l'heure actuelle est d'expédier des appareils intégrés avec des certificats auto-signés qui, en plus d'être bons pour la confiance lors de la première utilisation et de contrecarrer le reniflage passif, ne sont pas beaucoup mieux que le HTTP simple dans de nombreux scénarios. Souvent, l'utilisateur recevra toujours un avertissement de certificat et cliquera dessus. Jusqu'à ce que ce problème soit résolu, les perspectives HTTPS sur les appareils intégrés sont toujours lamentables.
(En ce qui concerne vos modifications maintenant supprimées) En effet, XSS contourne les atténuations CSRF. Cependant, le modèle de menace semble un peu différent ici, car il est moins probable qu'un adversaire puisse exploiter un XSS dans votre appareil intégré qu'un problème CSRF, puisqu'il devrait accéder à l'appareil dans le premier cas.
Sans la défense CSRF, un attaquant pourrait falsifier un e-mail (peut-être avec une adresse falsifiée correctement ciblée) avec une alerte de surveillance, vous demandant de vérifier car il y a un problème critique. Dans l'e-mail, il pourrait y avoir un lien vers http://yourswitch/factory_reset.
Les vecteurs d'attaque peuvent varier.
À moins que vous n'utilisiez un nom de domaine complet ou une adresse IP par défaut (par exemple, l'omniprésent 192.168.1.1) pour cet appareil, ce type d'attaque spécifique serait assez ciblé. Un attaquant devrait créer une demande au commutateur qui fait réellement quelque chose "d'intéressant" (cela nécessite de connaître le FQDN/IP et le fournisseur/modèle pour obtenir un chemin utile) et vous envoyer ce lien d'une manière qui ne soulève pas trop vos sourcils (un e-mail provenant d'Internet serait étrange. Peut-être quelque chose forgeant un e-mail de surveillance sans réponse que vous utilisez ?).
Comme d'habitude, il s'agit de comprendre votre modèle de menace et le rapport coût/bénéfice de vos contre-mesures.
Oui.
Dans le cas d'un commutateur réseau ou d'un routeur, les attaques typiques qu'il pourrait subir seraient la reconfiguration de l'appareil (comme le transfert d'un port interne vers l'extérieur), le changement du DNS qu'il fournit en un DNS malveillant, etc. Ces actions devraient nécessiter l'authentification, mais vous devez tenir compte du fait qu'il peut également utiliser un mot de passe par défaut inchangé.
(et oui, ce genre de choses arrive dans la nature)
Le fait qu'il soit basé sur une adresse privéehttp://192.168.1.1ne fournit aucune protection, car l'attaque se ferait par une page Web malveillante, envoyant via le navigateur d'un utilisateur à l'intérieur du réseau une requête malveillante qui, acceptée en raison de l'absence de protection CSRF, configurerait mal le commutateur.
Mozilla Firefox a le bogue 354493 ouvert depuis 14 ans, ce qui éviterait les attaques d'adresses non RFC-1918 vers RFC 1918, mais jusqu'à présent, il n'a pas été implémenté.