Cookies de connexion / session, Ajax et sécurité

1. le cookie doit être généré côté serveur parce que la session lie le client au serveur, et donc l'échange de tokens doit passer du serveur au client à un moment donné. Il ne serait pas vraiment utile de générer le cookie côté client, car le client est la machine distante non fiable.

   il est possible d'avoir le cookie activé lors d'un appel AJAX. Vers le serveur (et le réseau) un appel AJAX est tout 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 faire la journalisation en cours dans le même était que vous auriez pu juste compter sur un POST à partir d'un formulaire sur la page. Le serveur les verra de la même façon, et si le serveur place un cookie, le navigateur le stockera.

   Fondamentalement, Javascript côté client N'a jamais besoin 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é en utilisant l'extension du cookie "httponly" honorée par les navigateurs récents). Notez que d'autres appels HTTP du client vers le serveur, qu'il s'agisse de requêtes de page normales ou de requêtes AJAX, incluront automatiquement ce cookie, même s'il est marqué httponly et que le navigateur honore cette extension. Votre script n'a pas besoin d'être "conscient" de du cookie.

   que vous avez mentionné en utilisant HTTPS (HTTP sur SSL) - qui empêche les autres d'être en mesure de lire des informations en transit ou de se faire passer pour le serveur, il est donc très pratique pour empêcher la transmission de texte simple du mot de passe ou d'autres informations importantes. Il peut également aider à se prémunir contre les attaques réseau, bien qu'il ne vous rend pas immunisé contre tout ce que CSRF peut vous jeter, et il ne vous protège pas du tout contre les goûts de la fixation de session ou XSS. J'éviterais donc de considérer HTTPS comme une solution-all si vous l'utilisez: vous still avez besoin d'être vigilant sur les scripts cross-site et la falsification de requêtes cross-site.

2. (voir 1. J'ai combiné)

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. Cependant, pour le rendre compatible avec tous les navigateurs, vous devez vous assurer que la connexion est possible quand AJAX n'est pas disponible. Cela peut nécessiter la mise en œuvre 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 du navigateur pour AJAX ).

4. cela ne changerait pas la sécurité. Il n'y aurait pas besoin de cela, sauf que j'ai vu des iframes cachées utilisées auparavant pour "simuler" AJAX avant-c'est-à-dire faire des appels asyncrones vers serveur. Fondamentalement, peu importe comment vous le faites, c'est le serveur qui configure le cookie, et le client acceptera et retournera le cookie qu'il le fasse par AJAX ou non.

pour la plupart, que vous utilisiez AJAX ou non n'affecte pas la sécurité autant que toute la sécurité réelle se produit du côté du serveur, et pour le serveur un appel AJAX est tout comme un appel non-AJAX: ne pas faire confiance. Par conséquent, vous aurez besoin d'être conscient des problèmes comme fixation de session et connexion CSRF ainsi que les questions affectant la session dans son ensemble comme CSRF et XSS autant que vous le feriez si vous utilisiez no AJAX. Les problèmes ne changent pas vraiment lorsque vous utilisez AJAX, sauf, je suppose, que vous pouvez faire plus d'erreurs avec une technologie si vous êtes moins familier avec elle ou il est plus compliqué.

Réponse mise à jour en septembre 2014