Co to jest nagłówek HTTP „Niepewne żądania”?


220

Wysłałem żądanie POST do strony HTTP (nie HTTPS), sprawdziłem to żądanie w Narzędziach programisty Chrome i stwierdziłem, że dodało własny nagłówek przed wysłaniem go na serwer:

Upgrade-Insecure-Requests: 1

Po przeprowadzeniu wyszukiwania Upgrade-Insecure-Requestsmogę znaleźć tylko informacje o serwerze wysyłającym ten nagłówek:

Content-Security-Policy: upgrade-insecure-requests

Wydaje się to powiązane, ale nadal bardzo różne, ponieważ w moim przypadku KLIENT wysyła nagłówek w żądaniu , podczas gdy wszystkie informacje, które znalazłem, dotyczą SERWERA wysyłającego powiązany nagłówek w odpowiedzi .


Dlaczego więc Chrome (44.0.2403.130 m) dodaje się Upgrade-Insecure-Requestsdo mojego żądania i co robi?


Aktualizacja 24.08.2016:

Nagłówek ten został dodany jako rekomendacja dla kandydatów W3C i jest teraz oficjalnie uznawany.

Dla tych, którzy właśnie natknęli się na to pytanie i są zdezorientowani, doskonała odpowiedź Simon East dobrze to wyjaśnia.

Upgrade-Insecure-Requests: 1Nagłówek kiedyś HTTPS: 1 w poprzednim projekcie W3C roboczej i został przemianowany cicho przez Chrome przed zmianą stało się oficjalnie zaakceptowane.

(To pytanie zostało zadane podczas tego przejścia, gdy nie było oficjalnej dokumentacji tego nagłówka, a Chrome była jedyną przeglądarką, która wysłała ten nagłówek).


1
Firefox też to robi.
dakab

Musi być nowy; Najpierw pracuję nad Firefoksem, a ten nagłówek zdecydowanie nie został wysłany z Firefoksa w zeszłym roku.
user193130,

Odpowiedzi:


274

Krótka odpowiedź: jest ściśle związana z Content-Security-Policy: upgrade-insecure-requestsnagłówkiem odpowiedzi, co oznacza, że ​​przeglądarka obsługuje ją (i tak naprawdę woli).

Zajęło mi to 30 minut Googling, ale w końcu znalazłem go pochowany w specyfikacji W3.

Pomyłka pojawia się, ponieważ nagłówek w specyfikacji był HTTPS: 1i tak Chromium go zaimplementował, ale po tym złamał wiele stron internetowych, które zostały źle zakodowane (szczególnie WordPress i WooCommerce) zespół Chromium przeprosił:

„Przepraszam za złamanie; najwyraźniej nie doceniłem wpływu opartego na informacjach zwrotnych podczas tworzenia i beta”.
- Mike West, w numerze Chrome 501842

Ich rozwiązaniem była zmiana nazwy na Upgrade-Insecure-Requests: 1, a specyfikacja została zaktualizowana, aby pasowała.

Tak czy inaczej , oto wyjaśnienie ze specyfikacji W3 (jak się wtedy pojawiło) ...

Pole HTTPSnagłówka żądania HTTP wysyła do serwera sygnał wyrażający preferencje klienta dotyczące zaszyfrowanej i uwierzytelnionej odpowiedzi oraz że może on z powodzeniem obsłużyć dyrektywę w sprawie żądań uaktualnienia niepewnych , aby zapewnić jak najbardziej płynne tej preferencji.

...

Gdy serwer napotka tę preferencję w nagłówkach żądania HTTP, POWINIEN przekierować użytkownika do potencjalnie bezpiecznej reprezentacji żądanego zasobu.

Gdy serwer napotka tę preferencję w nagłówkach żądania HTTPS, POWINIEN zawrzeć Strict-Transport-Securitynagłówek w odpowiedzi, jeśli host żądania jest bezpieczny dla HSTS lub warunkowo bezpieczny dla HSTS [RFC6797].


1
Nie rozumiem tego. Jestem a.comi przekierowuję cię b.com, podając ten nagłówek b.comi wysyłając pewne informacje. Jeśli nie masz bezpiecznego kanału b.com, atak wąchania może się już zdarzyć, ponieważ wysłałem dane do b.commojej prośby. Czy możesz poprowadzić nas do prostego scenariusza, w jaki sposób zwiększa bezpieczeństwo połączeń dla użytkowników?
Saeed Neamati,

@SaeedNeamati Pod bardzo ścisłą perspektywą nic nie czyni bezpieczniejszego. Jeśli masz normalne wymagania bezpieczeństwa, musisz najpierw upewnić się, że łączysz przez HTTPS i nie polegaj na tym. Mając na uwadze powyższe, chciałbym opisać to w kontekście idei „ Trust, przy pierwszym użyciu ”, co czyni pomoc biernie.
tne

1
Widzę to bardziej jako pragnienie klienta niż narzędzie bezpieczeństwa. To jest jak nagłówek „DNT”, serwer może go zignorować, ale wyraża wolę klienta.
DUzun,

Moja odpowiedź może być poprawiona, aby właściwie wyjaśnić, w jaki sposób klient i serwer to negocjują. Jeśli chcesz, możesz zaproponować ulepszenia.
Simon East,

5

To wszystko wyjaśnia:

Dyrektywa HTTP Content-Security-Policy (CSP) uaktualnienia-niezabezpieczone-żądania instruuje agentów użytkowników, aby traktowali wszystkie niepewne adresy URL witryny (te obsługiwane przez HTTP) tak, jakby zostały zastąpione bezpiecznymi adresami URL (tymi obsługiwanymi przez HTTPS). Niniejsza dyrektywa jest przeznaczona dla stron internetowych z dużą liczbą niepewnych starszych adresów URL, które wymagają przepisania.

Dyrektywa dotycząca niezabezpieczonych żądań aktualizacji jest oceniana przed blokowaniem wszystkich mieszanych treści, a jeśli jest ustawiona, ta ostatnia jest faktycznie nie możliwa. Zaleca się ustawienie jednej lub drugiej dyrektywy, ale nie obu.

Dyrektywa w sprawie niezabezpieczonych żądań uaktualnienia nie zapewni, że użytkownicy odwiedzający Twoją witrynę za pośrednictwem łączy w witrynach stron trzecich zostaną uaktualnieni do HTTPS w celu nawigacji na najwyższym poziomie, a zatem nie zastąpią nagłówka Strict-Transport-Security (HSTS), który należy nadal ustawić na odpowiedni maksymalny wiek, aby zapewnić, że użytkownicy nie będą podlegać atakom polegającym na usuwaniu SSL.

Źródło: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.