Je faisais une recherche de sécurité sur le stockage de l'ID de session dans le stockage local au lieu de le stocker dans des cookies. Je comprends qu'il n'est pas possible de baliser les valeurs du stockage local en tant que HttpOnly et qu'il peut donc être vulnérable aux attaques XSS. Étant donné que toutes les entrées sont correctement validées, je suis libre de ce problème.
Mais l'autre problème que j'ai trouvé est la falsification des données lors du transfert vers le serveur. Étant donné que mon ID de session de stockage local ne peut pas être balisé sous Secure
, il est possible qu'il puisse être transmis via un canal non chiffré (HTTP). Pour atténuer cela, je veux savoir s'il est possible d'accéder à une page via HTTP sécurisée par SSL.
Une page sécurisée avec SSL (ou TLS d'ailleurs) n'est pas accessible via HTTP, car cela signifierait que la page n'est plus sécurisée.
Si je reformule la question: Est-il possible d'accéder à une page particulière d'un site Web sécurisé HTTPS via HTTP, alors je dirais que c'est possible, mais très INsecure. De plus, le cookie avec l'ID de session devra probablement être envoyé avec chaque demande de page, car vous devez suivre la session sur plusieurs pages. Cela impliquerait que vous devez diffuser presque toutes les pages via HTTP, ce qui rend votre site non sécurisé.
Dans le cas où vous avez besoin du cookie de session sur une seule page, vous pouvez dire au client d'effectuer une requête HTTP sur cette page, qui enverra ensuite tous les cookies qui n'ont pas l'indicateur `` sécurisé '' défini. Cependant, cela signifie que tous ces cookies sont vulnérables à une attaque MITM et peuvent être lus par toute personne écoutant votre communication.
Mon conseil: ne diffusez jamais consciemment une page d'un site HTTPS sur HTTP.
Donc, la question que vous devez vous poser est pourquoi mon ID de session ne peut-il pas être étiqueté de manière sécurisée uniquement. Est-ce la paresse, ou y a-t-il une autre raison pour laquelle vous ne pouvez pas marquer ce cookie comme étant sécurisé?
Soit dit en passant, pour forcer un navigateur à toujours utiliser HTTPS pour un site Web (et ne pas s'appuyer sur des redirections 302 pour visiter la version HTTPS), HTTP Strict Transport Security peut être utilisé. Veuillez vous référer à OWASP pour plus d'informations.
Oui, bien sûr.
Exemple pour ce dernier: connectez-vous à https://www.Amazon.com et vous atterrirez sur une page sans aucune protection SSL.
Je pense que vous demandez à chiffrer vos données avec SSL tout en accédant à votre serveur via le protocole http: //. Je suppose que ce serait une bonne solution pour éviter toutes sortes d'avertissements SSL tout en sécurisant les données importantes.
J'ai trouvé cette question très intéressante et je vais essayer de l'essayer sur mon propre serveur.
Mais, à propos de la question, le serveur ne le fera pas par défaut. Même si vous pouvez envoyer des données ssl via l'interface d'écoute du serveur http, le navigateur ne traitera pas correctement les données demandées. Pensez au fait que le processus de décryptage des données SSL est lorsque vous atteignez un contenu https: // url, donc cela va sûrement se bloquer de quelque manière que ce soit en récupérant le crypté car il ne comprendra pas les demandes, par conception.
Si le but est de laisser les gens normaux (avec un navigateur normal) près de 100% sûr que le navigateur ne fonctionnera pas avec vos demandes.
Si l'objectif est d'envoyer des données SSL à l'aide d'une connexion http procotol, vous devez pirater/modifier le serveur bot et le navigateur, et, sur une analyse du trafic, vous serez reconnu comme une connexion http avec des données chiffrées SSL "illisibles".
Question très intéressante. J'ai commencé une petite recherche à ce sujet.