Pendant que je lisais des articles de détournement de la session, j'ai appris qu'il serait agréable de chiffrer la valeur d'identification de session qui est stockée dans un cookie.
Aussi loin que je sache, lorsque je démarre une session en appelant Comment crypter la valeur d'identification de session puis initialiser la session avec elle? session_start () , php ne chiffre pas la valeur d'identification de session dans un cookie.
8 Réponses :
En supposant que votre cookie de session est un GUID, il n'y a aucun point crypté. Il suffirait de remplacer une chaîne pseudo-aléatoire avec une autre.
cryptage ne vous aidera pas. Le cookie de session n'est qu'un chiffre magique quand même. Crypter cela signifie simplement qu'il y a un numéro magique différent pour détourner. Selon ce que vous avez à l'esprit les scénarios de détournement, il existe d'autres mesures d'atténuation possibles. Par exemple, vous pouvez limiter des sessions à une seule adresse IP. Cela pose des problèmes cependant, par exemple personnes qui passent des points sans fil.
Juste pour (espérons-le), clarifiez pour l'OP - la Session dans laquelle le cookie est transféré doit toujours être crypté et que le drapeau de cookie httponly doit être défini pour empêcher son transfert sur des canaux non cryptés. Cryptage correctement le canal de communication sur lequel le cookie de session est transporté rend plus difficile pour un attaquant d'intercepter le cookie.
La question était de crypter le cookie lui-même, c'est-à-dire la valeur stockée par le navigateur. Je suis d'accord cryptant le trafic vaut la peine pour certaines applications. Je pense que vous voulez dire le drapeau sécurisé, pas (juste) httponly.
Merci. Cette réponse a contribué à comprendre le domaine problématique. Maintenant, j'ai une solution dans HTTPS et où l'ID de session est remplacé pour chaque demande.
Il empêchera de deviner des identités de session aléatoire.
@Wout, devinant aléatoirement, un identifiant de session active est extrêmement improbable. Quoi qu'il en soit, crypter ça n'aide pas. Ensuite, ils doivent juste deviner le ciphertext correct.
Le cryptage rendra plus difficile, car il y a plus de bits à deviner, mais sur le côté serveur, plus de bits doivent être stockés lorsque l'ID de session reste la même taille. Un cryptage si efficacement vous permet d'avoir un identifiant de session un peu plus petit.
Malheureusement, le cryptage de l'ID de session n'augmentera pas beaucoup la sécurité, car l'attaquant peut simplement utiliser la forme cryptée (qui est la seule chose visible de toute façon).
La seule chose que cela pourrait empêcher, c'est l'astuce où vous envoyez quelqu'un un lien avec? phpsessid = foo de cela, ce qui causera PHP pour créer cette session. Vous pouvez l'empêcher d'utiliser le cryptage et la validation, mais vous devez plutôt désactiver le transfert d'identification de la session dans l'URL complètement.
Je crois que garder la session.use_trans_sid ( php.net/manual/fr/... ) désactivé suffit pour l'empêcher.
Oui c'est le cas. Heureusement, il est désactivé par défaut.
Il est plus important que vos identifiants de session soient aléatoires (c'est-à-dire que quelqu'un ne peut pas utiliser son identifiant de session pour deviner une autre personne), car le danger réel est quelqu'un d'avoir la main sur un autre identifiant de session d'utilisateur. Tant que vous les gardez vraiment au hasard, il n'y a aucune raison ou utilitaire pour le crypter
Faites ce script, accédez à un navigateur Web, puis vérifiez vos cookies.
Site Cookie Value mysite.com PHPSESSID 6fktilab3hldc5277r94qh2204
Cela ne traite pas du tout à la question de l'affiche?
@zombat, je venais de démontrer que php ne génère pas de phpsessid de 5 ou quelque chose de complètement faible comme si l'OP était peut-être pensé.
C'est toujours une bonne idée de ne jamais dépendre uniquement d'un seul cookie ou d'un élément pour valider votre (s) utilisateur (connecté). Comme mentionné ci-dessus, c'est une bonne idée de stocker également la propriété intellectuelle et de vérifier cela. Un bon ajout serait de stocker l'utilisateur_agent.
Nauvegile à l'esprit que si votre application est ouverte, vous êtes tout aussi bon avec une carte d'identité de session seule, car le pirate informatique pourrait facilement identifier ce que vous validez contre.
L'ID de la session est relativement dépourvu, ce n'est pas vraiment le problème.
Il y a des choses que vous pouvez faire liées à cela pour contrer les attaques:
Il y a aussi peu d'autres choses aussi. Je recommande toujours d'étudier le Guide de rails sur ces problèmes-- offre une explication très accessible des problèmes connus et des contre-mesures - tout aussi applicable au code PHP.
Il est logique de chiffrer les données de cookie lorsque vous utilisez des cookies pour stocker des informations sensibles. que seul le serveur doit lire (déchiffrer).
Il n'y a aucune raison de chiffrer la session ID, puisque le pirate informatique peut utiliser cet ID de session crypté pour imiter sa victime.
Quelqu'un peut-il supprimer la balise Session-crypt-chiffrer?
@smotchkiss // J'y pensais aussi. Désolé pour le nom de tag vague.
Je sais que cela ne répond pas à votre question par dites. Mais avez-vous envisagé de stocker la propriété intellectuelle avec l'ID de la session et de vérifier la propriété intellectuelle lors de la lecture de la session. De cette façon, vous pouvez être raisonnablement sûr que l'ordinateur fournissant l'ID de la session est la même que vous avez émis la session.
Ce serait une mauvaise chose si l'utilisateur est derrière un proxy (TOR, par exemple) qui provoque la modification de leur IP tout le temps. L'attaquant pourrait également être sur la même adresse IP également (considérer les pare-feu de la société, etc.)
@ Matti Virkkunen Merci de me donner droit. Je n'ai pas beaucoup d'expérience dans des sessions sécurisées, alors j'étais sorta tire de la hanche.
@Matti La possibilité de faiblesse ne peut être aucune raison de refuser une défense! Oui. L'attaquant pourrait également être derrière la même adresse IP. Mais pour les autres est toujours utile. Pourquoi ne pas utiliser? Où est la logique? Et combien vous avez vu des proxies aussi rotatifs? Pour vérifier que les utilisateurs IP sont toujours une bonne idée.
@Col. Shrapnel: Utiliser votre logique, il convient parfaitement à votre propre camp, car il augmente la sécurité - bien sûr, avec l'inconvénient de probablement avoir vos propres gars-là. J'utiliserais plutôt une bonne défense qu'une demi-arsed une montée avec de faux positifs car il y a beaucoup de bonnes disponibles. Régénérez les identifiants de session sur la connexion, n'utilisez aucun identifiant de session dans les URL, httponly cookies, aucun trous XSS et si vous avez peur de renifler, utilisez HTTPS. C'est une très bonne défense contre le détournement et la fixation de la session.