Ik heb een POST-verzoek ingediend bij een HTTP-site (niet-HTTPS), het verzoek gecontroleerd in de ontwikkelaarstools van Chrome en vastgesteld dat het een eigen header heeft toegevoegd voordat het naar de server wordt verzonden:
Upgrade-Insecure-Requests: 1
Na een zoekopdracht op Upgrade-Insecure-Requests, kan ik alleen informatieover de server die ditkop:
Content-Security-Policy: upgrade-insecure-requests
Dit lijkt gerelateerd, maar is nog steeds heel anders, aangezien in mijn geval de KLANT de header verzendt in het Request, terwijl alle informatie die ik heb gevonden betrekking heeft op de SERVER die de gerelateerde header verzendt een Reactie.
Dus waarom voegt Chrome (44.0.2403.130 m) Upgrade-Insecure-Requeststoe aan mijn verzoek en wat doet het?
Update 24-08-2016:
Deze kop is sindsdien toegevoegd als een W3C Kandidaataanbevelingen is nu officieel erkend.
Voor degenen die deze vraag net zijn tegengekomen en in de war zijn, het uitstekende antwoordvan Simon East legt het goed uit.
De Upgrade-Insecure-Requests: 1header was vroeger HTTPS: 1in de vorige W3C Working Draften werd door Chrome omgedoopt tot stilvoordat de wijziging officieel werd geaccepteerd.
(Deze vraag werd gesteld tijdens deze overgang toen er geen officiële documentatie over deze header was en Chrome de enige browser was die deze header heeft verzonden.)
Antwoord 1, autoriteit 100%
Kort antwoord: het hangt nauw samen met de Content-Security-Policy: upgrade-insecure-requestsresponsheader, wat aangeeft dat de browser dit ondersteunt (en er zelfs de voorkeur aan geeft).
Het kostte me 30 minuten Googlen, maar ik vond het uiteindelijk begraven in de W3-specificatie.
De verwarring komt omdat de header in de specificatie HTTPS: 1was, en dit is hoe Chromium het heeft geïmplementeerd, maar daarna heeft veel websites kapot gemaakt die slecht gecodeerd waren(met name WordPress en WooCommerce) het Chromium-team verontschuldigde zich:
“Mijn excuses voor de breuk; ik heb blijkbaar de impact onderschat op basis van de feedback tijdens de ontwikkeling en bèta.”
— Mike West, in Chrome-uitgave 501842
Hun oplossing was om het te hernoemen naar Upgrade-Insecure-Requests: 1, en de specificatie is sindsdien bijgewerkt om overeen te komen.
Hoe dan ook, hier is de uitleg van de W3-specificatie(zoals het er toen uitzag)…
Het veld
HTTPSHTTP-verzoekheader stuurt een signaal naar de server met de voorkeur van de klantvoor een versleuteld en geverifieerd antwoord, en dat het met succes de upgrade-insecure-requests-richtlijnom die voorkeur zo naadloos mogelijk te kunnen bieden.…
Als een server deze voorkeur tegenkomt in de headers van een HTTP-verzoek, MOET deze de gebruiker omleiden naar een mogelijk veilige weergave van de resource die wordt aangevraagd.
Als een server deze voorkeur tegenkomt in de headers van een HTTPS-verzoek, MOET deze een
Strict-Transport-Security-header opnemen in het antwoord als de host van het verzoek HSTS-safe of voorwaardelijk HSTS-safe is [RFC6797 ].
Antwoord 2, autoriteit 3%
Dit verklaart het geheel:
De HTTP Content-Security-Policy (CSP) upgrade-insecure-requests
richtlijn instrueert user agents om alle onveilige URL’s van een site te behandelen
(die via HTTP worden aangeboden) alsof ze zijn vervangen door secure
URL’s (die worden aangeboden via HTTPS). Deze richtlijn is bedoeld voor web
sites met grote aantallen onveilige verouderde URL’s die moeten worden
herschreven.De richtlijn upgrade-insecure-requests is eerder geëvalueerd
block-all-mixed-content en als het is ingesteld, is de laatste effectief een
nee-op. Het wordt aanbevolen om de ene of de andere richtlijn in te stellen, maar niet
beide.De richtlijn upgrade-insecure-requests zal er niet voor zorgen dat gebruikers
het bezoeken van uw site via links op sites van derden wordt geüpgraded naar
HTTPS voor de navigatie op het hoogste niveau en vervangt dus niet de
Strict-Transport-Security (HSTS) header, die nog moet worden ingesteld
met een geschikte maximumleeftijd om ervoor te zorgen dat gebruikers niet worden onderworpen aan:
SSL-stripping-aanvallen.