Les données sensibles doivent-elles jamais être transmises dans la chaîne de requête?
Si des données sensibles devaient être transmises via la chaîne de requête par opposition à la requête POST? Je me rends compte que la chaîne de requête sera cryptée , mais y a-t-il d'autres raisons pour éviter de transmettre des données dans la chaîne de requête, comme le surf sur l'épaule?
Si la chaîne de requête est la cible d'un lien cliquable par l'utilisateur (par opposition à une URL utilisée à partir de Javascript), elle apparaîtra dans la barre d'URL du navigateur lorsque la page correspondante sera chargée. Il présente les problèmes suivants:
- L'URL sera affichée. Les surfeurs d'épaule peuvent le voir et en tirer des leçons (par exemple, un mot de passe).
- L'utilisateur peut le mettre en signet. Cela peut être une fonctionnalité; mais cela signifie également que les données sont écrites sur le disque.
- De la même manière, l'URL arrivera dans "l'historique" donc elle sera de toute façon écrite sur le disque; et il pourrait être récupéré par la suite. Par exemple, si le navigateur est Chrome, un attaquant à l'heure du déjeuner n'a qu'à taper Ctrl + H pour ouvrir "l'onglet historique" et obtenir toutes les chaînes de requête.
- Si la page est imprimée, l'URL sera imprimée, y compris toute information sensible.
- Les URL, y compris les chaînes de requête, sont également fréquemment enregistrées sur le serveur Web, et ces journaux peuvent ne pas être sécurisés de manière appropriée.
- Il existe des limitations de taille sur la chaîne de requête, qui dépendent du navigateur et du serveur (il n'y a rien de vraiment standard ici, mais attendez-vous à des problèmes au-delà d'environ 4 Ko).
Par conséquent, si la chaîne de requête est une simple cible de lien dans une page HTML, les données sensibles doivent être transmises dans le cadre d'un formulaire POST, not encodé dans l'URL Avec les téléchargements programmatiques (la manière AJAX), c'est beaucoup moins un problème.
En plus des autres réponses ici, la chaîne de requête est également stockée dans les fichiers journaux du serveur Web, HTTP Proxies, et peut même être vue si SSL est utilisé en conjonction avec un outil de surveillance SSL comme Bluecoat.
Non , les données sensibles ne doivent pas être envoyées via un HTTP "GET" et doit toujours être envoyé via "POST"
Éditer:
Une autre raison pour laquelle vous devriez utiliser un POST est parce que les GET sont plus susceptibles de attaques CSRF
Les données sensibles doivent être transmises soit:
- Cookies sécurisés HTTP uniquement (sécurisé signifiant SSL uniquement; et HTTP uniquement signifiant que javascript n'est pas accessible) (par exemple, un jeton aléatoire identifiant que vous vous êtes connecté), ou
- Variables POST (sur SSL).
Trois raisons:
- Par défaut, votre ordinateur enregistre généralement la chaîne de requête (dans l'historique du navigateur),
- Par défaut, le serveur Web à l'autre extrémité enregistre la chaîne de requête. Cela est mauvais si les mots de passe sont transmis que le serveur Web ne stocke intelligemment que des hachages cryptographiques renforcés par des clés avec des sels aléatoires (par exemple, bcrypt) pour empêcher que les mots de passe soient obtenus par inadvertance par des attaquants. Évidemment, ce n'est pas difficile à enregistrer POST variables si vous en avez besoin, mais ce n'est généralement pas fait.
- Les données sensibles ne doivent généralement être transmises que lorsqu'une action quelconque est effectuée sur la base de ces données sensibles; et dans les cas où vous effectuez une sorte d'action (comme vous connecter; transmettre des données sécurisées à stocker/agir dans une base de données), vous devez utiliser POST versus GET.
Généralement, les règles qui empêchent les falsifications de requêtes intersites (CSRF également connu sous le nom de XSRF) ne sont déclenchées que pour les requêtes POST. GET est la méthode de requête HTTP prévue pour récupérer les données d'un serveur Web qui n'a pas de autre effet (en plus de choses bénignes comme le remplissage d'un fichier journal indiquant que cette page a été demandée); POST est le protocole pour qu'un utilisateur envoie des données pour effectuer une action (par exemple, comme commander quelque chose à partir d'un site Web) ; transférer de l'argent à partir de votre compte bancaire; changer votre mot de passe). C'est un jeton CSRF aléatoire généralement requis par la plupart des frameworks pour les demandes GET, mais sera souvent requis pour les POST requêtes.
(Et tandis que Thomas Pornin et makerofthings7 ont abordé respectivement 1 et 2, j'ai mentionné les deux précédemment dans une question quelque peu similaire .)
Si cela peut être évité, je l'évite toujours. C'est juste une surface d'attaque de plus qui devrait rester fermée à moins qu'il n'y ait un besoin légitime pour permettre le passage des données dans la requête chaîne.
Il y a également toujours la possibilité que vous ou un futur développeur ne filtriez/désinfectiez pas correctement les données et n'ouvrirez pas la surface d'attaque encore plus largement. Même dans une application non sécurisée, si vous autorisez accidentellement une injection, un attaquant malveillant et injectez un script XSS et XSRF dans votre base de données et utilisez votre application non sensible pour attaquer les autres, il est donc préférable de la jouer en toute sécurité.
Le surf sur les épaules est une autre préoccupation légitime, selon l'environnement. Si votre application doit être utilisée dans un endroit où cela est possible (une bibliothèque, une cabine dans laquelle quelqu'un peut regarder et un bureau avec un bureau orienté dans la mauvaise direction, etc.), c'est un problème potentiel. Si les personnes qui utilisent votre application sont toutes dans des pièces où le bureau est pointé pour que le surf à l'épaule ne soit pas un problème, ne vous en faites pas. mais si vous ne le savez pas avec certitude, et vous ne savez pas que ce sera toujours être de cette façon, c'est une préoccupation.
Basé sur OWASP REST Security Cheat Sheet https://owasp.org/www-project-cheat-sheets/cheatsheets/REST_Security_Cheat_Sheet
Dans les demandes GET, les données sensibles doivent être transférées dans un en-tête HTTP.