Peut-être que le titre est mal formulé mais ne pouvait pas penser à une meilleure façon de le dire.
Je travaille sur un système de connexion pour le moment (rien de formel, juste expérimenter) et prévoyait d'utiliser PHPLIVEX (une bibliothèque Ajax) pour certaines fonctionnalités. Fondamentalement, vous créez des fonctions PHP qui sont ensuite appelées via JavaScript. Vous pouvez ajouter des paramètres (GetElementyID) au JavaScript qui sont transférés sur la fonction PHP.
Ce que je voulais vraiment savoir, c'est qu'il est prudent de simplement appeler la fonction de JavaScript sans crypter le mot de passe en premier, laissez la fonction PHP le chiffrer (SHA256 dans ce cas). Les données peuvent-elles être transférées via AJAX être interceptées? Si oui, quelle est la probabilité que cela?
13 Réponses :
Les appels Ajax sont simplement une requête http simple.
Il se comporte comme une demande HTTP ordinaire et vient également avec tout l'avantage et l'inconvénient de celui-ci. Ce n'est pas plus sûr.
Pour faire en sécurité vos appels Ajax, vous pouvez essayer de plusieurs façons:
-1: réponse trompeuse. Ajax fait la même demande que la même forme ancienne.
Et quelle partie de ma réponse qui dit "Ajax ne fait pas la même demande que" une forme unique "?
@Adrian: En fait, ce sont les informations manquantes qui rendent quelqu'un qui n'a pas cette connaissance à supposer que c'est d'une manière ou d'une autre.
Il a dit "trompeur", pas "flairement incorrect". Et je suis d'accord avec lui, bien que je ne vais pas vous -1, vous pour cela. Je vais juste commenter à la place.
@JOSH: Merci. Amélioré ma réponse.
@Adrian - votre n ° 2 ne fonctionne pas car quiconque qui peut renifler le trafic verra le mot de passe haché et pourrait facilement le replayer. Le seul avantage à la hachage est que (s'il est correctement salé), il sera très difficile de recevoir un mot de passe pré-haché
@Josh Yep, il est sujet à rejouer une attaque. Mettez un jeton de temps dans.
Pas plus de sécurité ou moins qu'une demande de post HTTP normale émise par un navigateur (comme dans un Le "correction" pour cela est le même "correction" pour les demandes non AJAX - utilisez SSL.
Bonne réponse, merci. Donc, il n'y a pas de trous de sécurité reliant uniquement à Ajax?
Ou problème de défi, voyez ma réponse.
@ Briggins5 comme Peter dit, Ajax est simplement des demandes de post HTTP qui se produisent hors de tour ou «asynchronement». Donc, d'une manière de parler, vous êtes correct. Mais, étant donné que Ajax est asynchrone, les changements d'état dans le navigateur du client sont plus difficiles à comprendre, il est donc plus facile de gâcher la sécurité.
Si vous envoyez le mot de passe via AJAX ou via une forme normale, il est toujours envoyé via un message HTTP Le seul moyen d'empêcher que quelqu'un d'intercepter votre mot de passe consiste à utiliser SSL (via AJAX ou non). POST (espérons-le). Donc, vous n'ayez pas d'ajouter ou de supprimer quoi que ce soit de sécurité.
Le mot de passe du texte brut transmis via AJAX sera aussi sécurisé que le même mot de passe transmis via un post HTTP normal. C'est-à-dire que Ajax utilise HTTP et peut donc être intercepté et reniflé. Votre meilleur pari est d'utiliser HTTPS (SSL).
Pour la lecture supplémentaire sur Ajax et Security, je recommanderais les lectures suivantes
Ceci est tout aussi sûr que d'avoir une forme de connexion qui n'est pas sécurisé SSL SECUT SE SE SE SONT SONT SONT SUR LE FIL, comme presque toutes les forums de travail.
Ce n'est pas sûr. N'envoyez pas de mots de passe non cryptés. Il est très probable qu'ils soient interceptés à un moment donné, vous aurez un problème majeur.
Voici un Exemple vidéo de capturer un mot de passe Telnet. Telnet envoie en texte brut et cela illustre bien le problème majeur que vous avez si vous pensez même à faire cela. Tout script de deux bits kiddie peut accrocher un mot de passe texte clair plus rapidement que vous le pouvez "oh mon Dieu, où est allée ma base de données?"
Soins pour fournir à tous les faits qui sont de votre avis?
Assurez-vous que la cible de votre appel AJAX est une page HTTPS approuvée: // page et vous l'avez effectuée chaque bit aussi sécurisé que l'un des autres envois des mêmes informations que le reste de votre application effectue. La plupart des bibliothèques / frameworks ne vous limitent pas à http: // pour vos appels AJAX.
Vous l'envoyez dans la claire, donc tout le monde avec renifler / écouter / etc. Le réseau du client pourra facilement voir le mot de passe. L'appel AJAX est juste un ancien message HTTP uni. Si vous voulez voir cela en action, déposez une copie de Wireshark et faites-la votre demande. Vous pourrez voir le mot de passe dans le paquet HTTP.
Oui, il peut être lu. Tout comme tout le reste sans une sorte de couche de sécurité (voir SSL)
Pour le voir vous-même, exécutez un outil comme Wireshark comme vous faites vos commandes Ajax.
Quelle est la probabilité? Pas très, mais le mot de passe de l'utilisateur sera probablement enregistré dans les fichiers journaux de quelqu'un en texte brut. Si quelqu'un a finalement trouvé cela, alors cela pourrait être une mauvaise nouvelle. De retour au collège, ma classe de réseautage avait accès à des routeurs (semi) fantaisie. Nous avions des missions où nous nous sommes inscrits pour des comptes sur des sites Web aléatoires. Comme nous l'avons fait cela, nous avons remarqué des choses très effrayantes sur les fichiers journaux des routeurs. C'était un ouvre-yeux pour que je pense que chaque communication est suivie et probablement connectée quelque part.
Comme d'autres personnes ont mentionné, ce n'est plus dangereux que d'envoyer un message HTTP d'un formulaire. En fait, c'est la même chose.
Mais si HTTPS n'est pas une option, vous pouvez toujours utiliser un schéma de défi / réponse sur une connexion non cryptée. Fondamentalement, cela fonctionne comme ceci:
C'est en fait assez simple à configurer une fois que vous avez eu l'idée. Wikipedia a quelques informations supplémentaires sur elle.
Cela ressemble à une bonne méthode. J'aimerais que les opinions des personnes de la manière dont cela soit sécurisé par rapport à l'authentification traditionnelle (comparant simplement le nom d'utilisateur et le mot de passe)?
Quelle est la sécurité que cela est comparé à juste envoyer à la fois le nom d'utilisateur et le mot de passe comme texte brut? Eh bien, si vous attachez la valeur de 0 à cette méthode, et mon approche est une n> 0 (par exemple .0005 Même, pour l'argument) Ma méthode est> 1 000 000 000 000 000 fois plus sûre.
J'ai posé cette même question il y a longtemps. Voici un autre lien qui le décrit (avec quelques bizarreries supplémentaires): gamedev.net /Community/forums/vieweply.asp?id=3353014
Il est beaucoup plus facile de rompre cela qu'il ne s'agit de casser SSL. Si vous ne saluez pas le mot de passe, vous pouvez probablement le casser en quelques minutes avec des tables arc-en-ciel téléchargées. Si vous salageez le mot de passe, l'attaquant peut toujours capturer le mot de passe haché et tenter de le deviner - SHA1 est très rapide, les ordinateurs modernes peuvent essayer des millions de mots de passe une seconde. (Ne réinventez pas SSL!)
@Jrockway: Tout d'abord, cela ne réinvente pas SSL. Challenge / Réponse n'est valable que pour déterminer lorsque deux parties connaissent les mêmes informations. Deuxièmement, les sels ne sont pas secrets et une méthode de salage acceptable pour la défense contre les tables arc-en-ciel est la suivante: Hash = SHA (SHA (mot de passe). Sel). Dans cette mise en place, le sel est le défi et le but devient deux fois que Hash = SHA (SHA (mot de passe). Défi). Troisièmement, j'utilisais SHA1 à titre d'exemple. Il y a beaucoup de régimes plus grands disponibles si vous avez besoin de sécurité supplémentaire.
Comme déjà mentionné, SSL est la meilleure solution ici. Cependant, vous pouvez avoir récupéré le mot de passe du côté du client. Si vous avez Google pour cela, vous trouverez de nombreuses implémentations JavaScript de MD5.
DAMN vous vous inquiétez. SSL ne protège pas contre l'attaque MITM d'intoxication ARP. Il serait fatal d'adorer SSL que vous les gars. Vous devez avoir un moyen de chiffrer le mot de passe du côté du client avant qu'il ne produise même qu'un hop ou même un pirate informatique novice sera en mesure d'intercepter le mot de passe en clairexuel
Je pense que cela serait mieux adapté comme un commentaire.
On devrait également être très conscient des vulnérabilités de sécurité potentielles lors de la création d'une application qui utilise Ajax.
Le site suivant a une très bonne information sur les attaques Ajax et XSS ou XSRF http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf
N'oubliez pas que lorsque vous faites une fonction distante accessible à un appel JavaScript, un utilisateur pourrait simplement deviner l'appel de la fonction et la modifier pour faire ses enchères.
Quelle est la meilleure façon de le sécuriser, alors que d'utiliser SSL? S'il était possible de hacher un mot de passe en JavaScript, c'est une solution reseignable?
Si vous haussez le mot de passe en JavaScript, il sera toujours visible pour que quiconque reniflant le trafic (il sera simplement haché!) Un attaquant pouvait tritive rejouer cette demande avec le mot de passe haché
Et SSL résoudra ce problème?
SSL cryptera toute la demande de poste (et réponse à ce sujet). Alors oui, ça va résoudre ce problème.
Si vous ne comprenez pas déjà intimement les implications de sécurité ici, vous ne devez pas vraiment concevoir un système d'autorisation. Il y a beaucoup de solutions prêtes à l'emploi, comme Auth.
Bonjour, la raison pour laquelle je fais cela est de mieux comprendre. Je ne mettant pas en œuvre cela pour quelque chose de grave ou formel du tout.
Solution: Transférer un "défi" (nombre aléatoire cryptographiquement sécurisé) au client liés à la session . Demandez au client le mot de passe, puis hachage dans le défi, puis envoyez-le. Un attaquant reniflant le résultat devrait également avoir détourné la session pour pouvoir utiliser le résultat.
Ouais, réimplément SSL dans JavaScript et dans votre application. C'est beaucoup plus facile que de basculer un commutateur dans votre serveur Web Config!
Arrête ça! Je vais utiliser OpenID.