2009-03-19 9 views
41

J'essaie de déterminer la méthode la plus sûre pour un formulaire de connexion basé sur ajax pour authentifier et définir un cookie côté client. J'ai vu des choses sur les attaques XSS, comme ceci:Cookies de connexion/session, Ajax et sécurité

How do HttpOnly cookies work with AJAX requests?

et

http://www.codinghorror.com/blog/archives/001167.html

Donc, je suppose que mes questions fondamentales sont ...

1) utilise pur ajax pour sécuriser les cookies, si oui, quelle est la méthode la plus sécurisée (httpOnly + SSL + valeurs cryptées, etc.)?

2) Est-ce qu'une méthode ajax pure implique la définition du côté client cookie? Est-ce sécurisé?

3) Le paramétrage des cookies est-il si fiable dans tous les principaux navigateurs/systèmes d'exploitation?

4) L'utilisation d'un IFrame caché serait-elle plus sûre (appel d'une page Web pour configurer les cookies)?

5) Si possible, quelqu'un at-il du code pour cela (PHP est mon backend)?

Mon but est de définir les cookies et de les rendre disponibles pour le prochain appel au serveur sans naviguer loin de la page.

Je veux vraiment définir le consensus, le moyen le plus sûr de le faire. Finalement, ce code est prévu d'effectuer Open Source, donc s'il vous plaît pas de code commercial (ou rien qui ne résiste pas à l'examen du public)

Merci, -Todd

Répondre

68
  1. Le cookie a besoin de être généré côté serveur car la session lie le client au serveur, et par conséquent l'échange de jetons doit passer du serveur au client à un certain stade. Il ne serait pas vraiment utile de générer le cookie côté client, car le client est l'ordinateur distant non approuvé.

    Il est possible d'avoir le jeu de cookies lors d'un appel AJAX. Pour le serveur (et le réseau), un appel AJAX est simplement un appel HTTP, et toute réponse HTTP par le serveur peut définir un cookie. Donc oui, il est possible d'initier une session en réponse à un appel AJAX, et le cookie sera stocké par le client comme d'habitude. Ainsi, vous pouvez utiliser AJAX pour effectuer la procédure de connexion de la même manière que vous auriez pu vous fier à un POST à ​​partir d'un formulaire sur la page. Le serveur les verra de la même manière, et si le serveur définit un cookie, le navigateur le stockera. Fondamentalement, le Javascript côté client n'a jamais besoin d'être capable de connaître la valeur du cookie (et c'est mieux pour la sécurité si ce n'est pas le cas, ce qui peut être réalisé avec l'extension de cookie "httponly" honorée par les récents navigateurs).). Notez que d'autres appels HTTP du client au serveur, qu'il s'agisse de demandes de pages normales ou de requêtes AJAX, incluent automatiquement ce cookie, même s'il est marqué httponly et que le navigateur respecte cette extension. Votre script n'a pas besoin d'être "conscient" du cookie.Vous avez mentionné l'utilisation de HTTPS (HTTP sur SSL), qui empêche les autres utilisateurs de lire les informations en transit ou d'usurper l'identité du serveur. Il est donc très pratique pour empêcher la transmission du mot de passe ou d'autres informations importantes. Il peut également vous protéger contre les attaques réseau, même s'il ne vous immunise pas contre tout ce que CSRF peut vous envoyer, et il ne vous protège pas du tout contre les attaques de type fixation de session ou XSS. Donc, j'éviterais de penser à HTTPS comme une solution-tout si vous l'utilisez: vous devez toujours être vigilant sur les scripts inter-sites et la falsification de requêtes inter-sites.

  2. (voir 1. Je sorte de les combinés)

  3. Étant donné que le cookie est défini par le serveur dans ses en-têtes de réponse HTTP, oui il est fiable. Toutefois, pour le rendre compatible avec plusieurs navigateurs, vous devez vous assurer que la connexion est possible lorsque AJAX est indisponible. Cela peut nécessiter l'implémentation d'une alternative qui n'est visible que s'il n'y a pas de Javascript ou si AJAX n'est pas disponible. (Note: maintenant en 2014, vous n'avez plus besoin de vous soucier du support navigateur pour AJAX).

  4. Cela ne changerait pas la sécurité. Cela ne serait pas nécessaire, sauf que j'ai déjà vu des iframes cachées utilisées auparavant pour "simuler" AJAX - c'est-à-dire faire des appels asynchrones au serveur. Fondamentalement, peu importe ce que vous faites, c'est le serveur qui configure le cookie, et le client accepte et retourne le cookie, qu'il le fasse par AJAX ou non.

Pour la plupart, si vous utilisez AJAX ou non ne porte pas atteinte à la sécurité tant que ça que tout le véritable sécurité passe sur le côté serveur et au serveur un appel AJAX est comme un non Appel AJAX: à ne pas faire confiance. Par conséquent, vous devez être conscient des problèmes tels que session fixation et login CSRF ainsi que les problèmes affectant la session dans son ensemble comme CSRF et XSS autant que vous le feriez si vous n'utilisiez pas AJAX. Les problèmes ne changent pas vraiment lorsqu'on utilise AJAX sauf, à part, je suppose, que vous pouvez faire plus d'erreurs avec une technologie si vous êtes moins familier ou plus compliqué.

Réponse mise à jour Septembre 2014

+6

Merci, cette réponse était exactement ce que je cherchais - réfléchi et rien de génial. Je vous en suis reconnaissant. - Todd – supertodda

Questions connexes