Een cookie heeft de vlag "beveiligd" als dat zo is. Theoretisch verhindert niets dat een "veilige" cookie wordt aangeboden door een HTTP-server (niet-HTTPS); maar uw serversoftware kan problemen ondervinden, aangezien, vanuit zijn oogpunt, het protocol HTTP is en een veilige cookie weinig zin heeft als deze via HTTP wordt overgedragen. Uw server weet niet dat deze zich achter een HTTPS-naar-HTTP-gateway bevindt. Aan de andere kant ziet de klant een HTTPS-verbinding, en het zal hem helemaal niet verbazen dat hij via een dergelijke verbinding een beveiligde cookie krijgt.

Het probleem met een niet-beveiligde cookie is dat de klant graag verzendt het naar elke server die er net uitziet als de oorspronkelijke server. Als er een actieve aanvaller aanwezig is, moet u ervan uitgaan dat een niet-beveiligde cookie door de aanvaller kan worden gekaapt. Afhankelijk van uw exacte situatie kan dit een grote, kleine of onbestaande bedreiging zijn.

De; secure flag van sessiecookies is belangrijk, omdat de cookie anders via http wordt verzonden. Een aanvaller kan het slachtoffer misschien misleiden om een ​​http-verbinding te openen, zelfs als u alle links en bronnen naar https verwijst.

Normaal gesproken werkt het om de; secure-vlag op de applicatieserver in te stellen. De loadbalancer stuurt het antwoord gewoon terug naar de https-verbinding en alles is in orde voor de klant. Het belangrijkste probleem is om de load balancer te vertellen dat hij de cookie moet opnemen in zijn http-verbinding met de applicatieserver. Het hangt af van de concrete implementatie van de load balancer of deze dit automatisch doet of wat configuratie nodig heeft.

Ja, het is belangrijk. Als de beveiligde vlag niet op die cookies is ingesteld, bent u kwetsbaar voor Firesheep-achtige aanvallen, wat slecht is en een negatieve invloed kan hebben op gebruikers (bijv. Vooral gebruikers die verbinding maken via een open draadloze verbinding). Daarom raad ik u aan ervoor te zorgen dat de beveiligde vlag op die cookies is ingesteld.

Van wikipedia

Een beveiligde cookie wordt alleen gebruikt wanneer een browser een server bezoekt via HTTPS, die ervoor zorgt dat de cookie altijd wordt gecodeerd bij verzending van client naar server, en daardoor minder waarschijnlijk worden blootgesteld aan cookiediefstal via afluisteren.

Dus het antwoord is eigenlijk: maakt u zich zorgen over de inhoud van die cookies die via http worden verzonden of zijn de gegevens gevoelig en moet altijd via https worden verzonden.

Als ik het goed lees, vraag je je of de HTTP-cookies compatibel zijn met HTTPS-verzoeken? Het maakt wel uit, maar HTTP-cookies en HTTPS-cookies verwijzen naar dezelfde directory of host. Dus als je kijkt naar de ingestelde cookiecode

  GET /index.html HTTP / 1.1Host: www.example.org  

, zou ik proberen te specificeren a http: // versie en https: // versie