“업그레이드 비보안 요청”HTTP 헤더 란 무엇입니까?

220

HTTP (비 HTTPS) 사이트에 POST 요청을하고 Chrome 개발자 도구에서 요청을 검사 한 후 서버에 보내기 전에 자체 헤더를 추가 한 것을 발견했습니다.

Upgrade-Insecure-Requests: 1

에서 검색을 수행 한 후 Upgrade-Insecure-Requests, 나는 오직 찾을 수있는 정보를 전송하는 서버에 대한 이 헤더를 :

Content-Security-Policy: upgrade-insecure-requests

이것은 관련이 있지만 내 경우 CLIENT가 Request 에서 헤더를 보내고 있기 때문에 여전히 매우 다릅니다. 내가 찾은 모든 정보는 Response 에서 관련 헤더를 보내는 서버에 관한 것 입니다.

Chrome (44.0.2403.130m) Upgrade-Insecure-Requests이 내 요청에 추가 되는 이유는 무엇입니까?

2016-08-24 업데이트 :

이 헤더는 이후 W3C 후보 추천 으로 추가되었으며 공식적으로 인정됩니다.

이 질문을 겪고 혼란스러워하는 사람들에게는 Simon East 의 훌륭한 답변 이 잘 설명되어 있습니다.

Upgrade-Insecure-Requests: 1헤더로 사용 HTTPS: 1 이전 W3C 작업 초안에 와 개명되었다 조용히 변화가 공식적으로 승인되기 전에 크롬으로.

(이 질문은이 헤더에 공식 문서가없고 Chrome이이 헤더를 보낸 유일한 브라우저 일 때이 전환 중에 질문되었습니다.)

— 사용자 193130
소스

Firefox도 마찬가지입니다.

— dakab

새로운 것이어야한다. 나는 Firefox에서 먼저 개발을하고 작년 에이 헤더가 Firefox에서 보내지지 않았습니다.

— user193130

답변:

274

짧은 대답 : Content-Security-Policy: upgrade-insecure-requests응답 헤더 와 밀접한 관련 이 있으므로 브라우저가 지원한다는 것을 나타냅니다 (사실 선호합니다).

Google 검색에 30 분이 걸렸지 만 마침내 W3 사양에 묻혔습니다.

사양의 헤더 HTTPS: 1가 Chromium에서 구현 한 방식 이기 때문에 혼란이 생겼지 만 Chromium 은 코드가 잘못 코딩 된 (특히 WordPress 및 WooCommerce) 많은 웹 사이트를 중단 한 후 Chromium 팀이 사과했습니다.

"파손에 대해 사과드립니다. 개발 및 베타 기간 동안의 피드백을 바탕으로 영향을 과소 평가했습니다."
— Mike West, Chrome 문제 501842

수정은로 이름을 바꾸는 것이 었으며 Upgrade-Insecure-Requests: 1이후 사양이 일치하도록 업데이트되었습니다.

어쨌든 여기 에 W3 사양 의 설명이 있습니다 (당시 나타난대로) ...

HTTPSHTTP 요청 헤더 필드는 서버에 신호를 보내 고객의 취향을 표현 암호화 및 인증 응답을하고 있음을 성공적 업그레이드 - 불안 - 요청이 지시어를 처리 할 수 있습니다 제공하기 위해 가능한 한 원활으로 그 선호도를 만들기 위해.

...

서버가 HTTP 요청의 헤더에서이 기본 설정을 발견하면 사용자를 요청중인 리소스의 안전한 보안 표시로 리디렉션해야합니다.

서버가 HTTPS 요청의 헤더에서이 기본 설정을 만나면 Strict-Transport-Security요청의 호스트가 HSTS 안전하거나 조건부 HSTS 안전 인 경우 응답에 헤더를 포함 해야합니다 [RFC6797].

— 사이먼 이스트
소스

나는 그것을 이해하지 못한다. 난 a.com과로 리디렉션 b.com이 헤더를 제공하면서, b.com일부 정보를 전송. 의 보안 채널을 사용하지 않는 경우 요청과 함께 b.com데이터를 보냈으므로 스니핑 공격이 이미 발생할 수 있습니다 b.com. 사용자에게보다 안전한 연결을 제공하는 간단한 시나리오를 안내해 줄 수 있습니까?

— Saeed Neamati

@SaeedNeamati 매우 엄격한 관점에서 더 안전한 것은 없습니다. 정상적인 보안 요구 사항이있는 경우 먼저 HTTPS를 통해 연결해야하며 이에 의존하지 않아야합니다. 존재가 말했다, 나는 "의 아이디어의 맥락에서이 기술 할 것 처음 사용할 때 신뢰 ", 않습니다 수동적으로 도움을.

— tne

나는 이것을 보안 도구보다 고객의 요구로 더 본다. "DNT"헤더와 비슷하지만 서버는이를 무시할 수 있지만 클라이언트의 의지를 표현합니다.

— DUzun

내 대답은 실제로 클라이언트와 서버가 어떻게 협상하는지 올바르게 설명하기 위해 향상 될 수 있습니다. 원하는 경우 개선 사항을 제안하십시오.

— Simon East

이것은 모든 것을 설명합니다 :

CSP (HTTP Content-Security-Policy) 업그레이드 안전하지 않은 요청 지시문은 사용자 에이전트가 모든 사이트의 안전하지 않은 URL (HTTP를 통해 제공되는 URL)을 보안 URL (HTTPS를 통해 제공되는 URL)로 교체 한 것처럼 처리하도록 지시합니다. 이 지시문은 다시 작성해야하는 안전하지 않은 기존 URL이 많은 웹 사이트를위한 것입니다.

upgrade-unsecure-requests 지시어는 모든 콘텐츠를 혼합하기 전에 평가되며, 설정되어 있으면 후자는 사실상 무 작동입니다. 하나의 지시어 또는 다른 지시어를 설정하는 것이 좋지만 둘다는 아닙니다.

upgrade-insecure-requests 지시문은 타사 사이트의 링크를 통해 사이트를 방문하는 사용자가 최상위 탐색을 위해 HTTPS로 업그레이드 될 것을 보장하지 않으므로 HSTS (Strict-Transport-Security) 헤더를 대체하지 않습니다. 사용자가 SSL 제거 공격을받지 않도록 적절한 최대 연령으로 설정해야합니다.

출처 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

— 바질 무사
소스