Pourquoi les URL de fichier sont-elles marquées comme non sécurisées alors que les URL HTTPS sont marquées comme sécurisées dans les navigateurs?
Je comprends que les protocoles HTTPS modernes sont suffisamment sécurisés pour un utilisateur moyen.
Cependant, étant donné que ces protocoles doivent récupérer des fichiers sur le serveur tandis que le protocole de fichier indique simplement au navigateur de trouver le fichier sur votre ordinateur, je pense que les protocoles de fichier sont plus sécurisés que les protocoles HTTPS.
Ainsi, pourquoi les navigateurs marquant les protocoles HTTPS sont-ils sécurisés alors que les protocoles de fichiers ne sont pas sécurisés?
Le Connection is secure le badge concerne les informations transmises via le réseau/Internet. Comme vous l'avez correctement observé, le file:// Le protocole n'utilise aucune connexion réseau, ni aucun mécanisme pour le sécuriser (car il n'y en a pas), d'où le badge absent.
Notez que le navigateur ne nomme pas le file:// protocole as in secure. Le navigateur n'a tout simplement aucune raison de signaler la présence de mécanismes de sécurité fournis par TLS.
Je pense que les protocoles de fichiers sont plus sécurisés que les protocoles https.
Vous auriez raison, si le fichier provient du stockage local.
Que faire si vous chargez un fichier à partir d'un montage FTP (le protocole FTP n'a pas de sécurité, même les mots de passe sont envoyés en texte brut)? Ou à partir d'un service distant (non sécurisé) via le wifi non crypté? Un point d'accès client avec un lecteur connecté peut être configuré comme ceci.
Le navigateur n'a aucun moyen de savoir si l'une de ces connexions est en fait sécurisée. Et même s'il était possible de déterminer si les liens directs du système de fichiers étaient sécurisés, nous ne pouvons pas savoir si la prochaine étape de la chaîne l'est.
Ainsi, le navigateur ne garantit tout simplement pas ce qu'il ne sait pas.
En fait, file: // n'est pas aussi sécurisé qu'on pourrait le penser.
Supposons que nous soyons dans une session de connexion avec un tas de processus d'arrière-plan exécutés en tant qu'utilisateur, il n'y a aucune garantie à l'épreuve des balles que certains de ces processus pourraient modifier le fichier qu'un utilisateur pourrait ouvrir dans son navigateur.
Rappelez-vous que la tempête de virus WannaCry 2017 a été exécutée sur une mauvaise SMB. Qui peut dire que quelqu'un sur le LAN n'exploitera pas l'exécution de code à distance pour modifier les fichiers d'autres personnes?