CORS-프리 플라이트 요청 도입의 동기는 무엇입니까?

출처 간 리소스 공유 는 웹 페이지가 wikipedia 에서 다른 도메인으로 XMLHttpRequests를 만들 수있게하는 메커니즘입니다 .

나는 지난 며칠 동안 CORS를 다루었 고 모든 것이 어떻게 작동하는지 잘 이해하고 있다고 생각합니다.

따라서 제 질문은 CORS / 프리 플라이트 작동 방식에 관한 것이 아니라 프리 플라이트를 새로운 요청 유형으로 제공하는 이유 에 관한 것 입니다. 실제 요청 (RR)이 수락되는지 여부를 찾기 위해 서버 A가 서버 B에 프리 플라이트 (PR)를 보내야하는 이유를 알 수 없습니다. 이전 PR.

꽤 많이 검색 한 후 www.w3.org (7.1.5) 에서이 정보를 찾았습니다 .

이 사양이 존재하기 전에 특정 사용자 에이전트에서 시작할 수없는 교차 출처 요청으로부터 리소스를 보호하기 위해 리소스가이 사양을 인식하도록 사전 요청이 수행됩니다.

나는 이것이 문장을 이해하기가 가장 어렵다는 것을 안다. 내 해석 ( '최고의 추측'이라고 부르는 것이 좋습니다)은 사양을 모르는 서버 C의 요청으로부터 서버 B를 보호하는 것에 관한 것입니다.

PR + RR이 RR보다 더 잘 해결되는 시나리오를 설명하고 문제를 보여 줄 수 있습니까?

프리 플라이트 요청의 목적과 관련하여 약간의 시간이 소요되었지만 지금 당장받은 것 같습니다.

주요 통찰력은 프리 플라이트 요청이 보안 이 아니라는 것입니다. 오히려 그것들은 규칙을 바꾸지 않는 것입니다.

프리 플라이트 요청은 보안과 관련이 없으며 CORS에 대한 인식으로 현재 개발중인 애플리케이션과 관련이 없습니다. 오히려 프리 플라이트 메커니즘 은 CORS에 대한 인식 없이 개발 된 서버에 도움이 되며 클라이언트와 서버가 둘 다 CORS를 인식하는지 확인하는 기능을합니다. CORS 개발자는 수신 할 수 없다는 가정에 의존하는 서버가 충분하다고 느꼈습니다. 예를 들어 양측이 옵트 인 할 수 있도록 프리 플라이트 메커니즘을 발명 한 도메인 간 DELETE 요청이있었습니다. 그들은 단순히 도메인 간 호출을 가능하게하는 대안이 너무 많은 기존 응용 프로그램을 손상했을 것이라고 생각했습니다.

여기에는 세 가지 시나리오가 있습니다.

1. 이전 서버는 더 이상 개발 중이 아니며 CORS 이전에 개발되었습니다. 이러한 서버는 예를 들어 도메인 간 삭제 요청을 수신하지 않을 것이라고 가정 할 수 있습니다. 이 시나리오는 프리 플라이트 메커니즘의 주요 수혜자입니다. 예, 이러한 서비스는 악의적이거나 부적합한 사용자 에이전트에 의해 이미 악용 될 수 있지만 CORS는이를 변경하지 않습니다. 그러나 CORS가있는 세계에서는 프리 플라이트 메커니즘이 추가 '신성 검사'를 제공하여 클라이언트와 서버가 웹의 기본 규칙이 변경되었으므로 중단됩니다.

2. 아직 개발 중이지만 많은 이전 코드가 포함되어 있고 모든 이전 코드를 감사하여 교차 도메인 환경에서 제대로 작동하는지 확인할 수없는 서버입니다. 이 시나리오에서는 서버가 점진적으로 CORS를 옵트 인 할 수 있습니다 (예 : "이 특정 헤더를 허용하겠습니다", "이제 특정 HTTP 동사를 허용합니다", "이제 쿠키 / 인증 정보를 허용합니다") "전송 등 프리 플라이트 메커니즘에서이 시나리오 혜택을 제공합니다.

3. CORS를 인식하여 작성된 새 서버 표준 보안 방식에 따르면, 서버의 얼굴에 자사의 자원을 보호하는 어떤 들어오는 요청 - 서버가 없습니다에 대한 신뢰하지 클라이언트가 악의적 인 일을 할 수있다. 이 시나리오는 프리 플라이트 메커니즘의 이점이 없습니다 . 프리 플라이트 메커니즘은 리소스를 올바르게 보호 한 서버에 추가 보안을 제공하지 않습니다.

프리 플라이트 요청을 도입 한 동기는 무엇입니까?

프리 플라이트 요청이 도입되어 브라우저가 특정 요청을 보내기 전에 CORS 인식 서버를 처리하고 있는지 확인할 수 있습니다. 이러한 요청은 잠재적으로 위험하고 (상태 변경) 새로운 요청으로 정의되었습니다 ( 동일한 출처 정책 으로 인해 CORS 이전에는 불가능 ). 프리 플라이트 요청을 사용한다는 것은 서버가 CORS가 수행 할 수있는 잠재적으로 위험한 새 유형의 요청에 대해 프리 플라이트에 적절히 응답하여 옵트 인해야한다는 것을 의미합니다.

이는 이 사양의이 부분의 의미입니다 . "이 사양이 존재하기 전에 특정 사용자 에이전트에서 생성 할 수없는 출처 간 요청으로부터 리소스를 보호하기 위해 리소스가이 사양을 인식 할 수 있도록 프리 플라이트 요청이 수행됩니다."

예를 들어 주시겠습니까?

브라우저 사용자가의 은행 사이트에 로그인했다고 가정 해 보겠습니다 A.com. 악의있는 사용자를 탐색하면 B.com해당 페이지에 DELETE요청을 보내려는 일부 Javascript가 포함 됩니다 A.com/account. 사용자가에 로그인 했으므로 A.com해당 요청에는 전송 된 경우 사용자를 식별하는 쿠키가 포함됩니다.

CORS 이전에는 브라우저의 동일한 오리진 정책이이 요청을 보내는 것을 차단했습니다. 그러나 CORS의 목적은 이러한 종류의 교차 출처 통신을 가능하게하는 것이므로 더 이상 적합하지 않습니다.

브라우저 는 단순히를 보내고 DELETE서버가 처리 방법을 결정하도록 할 수 있습니다. 그러나 A.comCORS 프로토콜을 모르는 경우 어떻게해야 합니까? 계속해서 위험 할 수 DELETE있습니다. 브라우저의 동일한 출처 정책으로 인해 그러한 요청을받을 수 없으므로 그러한 공격에 대해 강화 된 적이 없다고 가정했을 수도 있습니다.

이러한 비 CORS 인식 서버를 보호하려면 프로토콜에 따라 브라우저가 먼저 비행 전 요청을 보내야합니다 . 이 새로운 종류의 요청은 CORS를 인식하는 서버 만 제대로 응답 할 수있어 브라우저가 실제를 전송하는 것이 안전한지 여부를 알 수 DELETE있습니다.

왜이 모든 것이 브라우저에 대한 소란을 불러 일으킬 수 DELETE있습니까? 공격자 는 자신의 컴퓨터에서 요청을 보낼 수 없습니까?

물론 그러한 요청에는 사용자의 쿠키가 포함되지 않습니다. 이를 방지하기위한 공격은 브라우저가 요청과 함께 다른 도메인에 대한 쿠키 (특히 사용자의 인증 정보)를 전송한다는 사실에 의존합니다.

같은 그 소리 크로스 사이트 요청 위조 사이트에서 양식, B.com캔 POST에 A.com사용자의 쿠키가 피해를.

맞습니다. 이것을 넣는 또 다른 방법은 CORS를 인식하지 않는 서버에 대한 CSRF 공격 영역을 늘리지 않기 위해 프리 플라이트 요청이 생성 된 것입니다.

그러나 프리 플라이트가 필요없는 "단순한"요청 에 대한 요구 사항 을 살펴보면 POST여전히 허용됩니다. 그것은 상태를 변경하고 DELETE! 처럼 데이터를 삭제할 수 있습니다 !

사실입니다! CORS는 CSRF 공격으로부터 사이트를 보호하지 않습니다. 다시 CORS가 없으면 CSRF 공격으로부터 보호되지 않습니다. 프리 플라이트 요청의 목적은 CSRF 노출을 CORS 이전의 세계에 이미 존재하는 것으로 제한하는 것입니다.

한숨. 프리 플라이트 요청의 필요성을 간절히 받아들입니다. 그러나 서버의 모든 리소스 (URL)에 대해 왜해야합니까? 서버가 CORS를 처리하거나 처리하지 않습니다.

확실합니까? 여러 서버가 단일 도메인에 대한 요청을 처리하는 것은 드문 일이 아닙니다. 예를 들어, A.com/url1한 종류의 서버가 요청을 A.com/url2처리하고 다른 종류의 서버가 요청을 처리하는 경우가 있습니다. 일반적으로 단일 리소스를 처리하는 서버가 해당 도메인의 모든 리소스에 대한 보안을 보장 할 수있는 것은 아닙니다.

좋아. 타협하자. 서버가 말할 수있는 리소스를 정확하게 명시 할 수있는 새로운 CORS 헤더를 만들어 해당 URL에 대한 추가 프리 플라이트 요청을 피할 수 있습니다.

좋은 생각! 실제로 헤더 Access-Control-Policy-Path는이 목적으로 만 제안되었습니다. 궁극적으로, 그러나, 그것은, 사양에서 제외되었다 분명히 일부 서버가 잘못 브라우저에 안전 보였다 경로에 대한 요청이 실제로 문제가있는 서버에 안전하지 않을 것 등의 방법으로 URI 사양을 구현하기 때문이다.

이는 성능보다 보안에 우선 순위를 두어 브라우저가 기존 서버를 위험에 빠뜨리지 않고 CORS 사양을 즉시 구현할 수있게 해주는 신중한 결정입니까? 아니면 특정 시간에 특정 서버의 버그를 수용하기 위해 인터넷을 대역폭을 낭비하고 대기 시간을 두 배로 늘리는 것이 근시입니까?

의견이 다릅니다.

글쎄, 최소한 브라우저는 단일 URL에 대한 프리 플라이트를 캐시합니까?

예. 아마 그리 오래되지는 않았지만. WebKit 브라우저에서 최대 프리 플라이트 캐시 시간은 현재 10 분 입니다.

한숨. 글쎄, 내 서버가 CORS를 인식하고 사전 비행 요청에 의해 제공되는 보호가 필요하지 않다는 것을 알면이를 피할 수있는 방법이 있습니까?

유일한 옵션은 "간단한"요청에 대한 요구 사항 을 충족시키는 것 입니다. 이는 (예를 들어 X-Requested-With) 포함 Content-Type하거나, 그 이상 에 대해 거짓말 을 할 사용자 정의 헤더를 생략하는 것을 의미 할 수 있습니다 .

CORS 사양은 unsafe를 포함하여 "간단한"요청 거부를 다루지 않으므로 적절한 CSRF 보호 기능을 갖추어야합니다 POST. 사양에서 알 수 있듯이 "단순한 요청이 검색 이외의 의미를 갖는 자원은 사이트 간 요청 위조로부터 자신을 보호해야합니다".

CORS 이전의 도메인 간 요청 세계를 고려하십시오. 표준 양식 POST를 수행하거나 script또는 image태그를 사용 하여 GET 요청을 발행 할 수 있습니다. GET / POST 이외의 다른 요청 유형을 만들 수 없으며 이러한 요청에 대해 사용자 지정 헤더를 발급 할 수 없습니다.

CORS가 등장하면서 스펙 작성자는 웹의 기존 의미를 손상시키지 않으면 서 새로운 교차 도메인 메커니즘을 도입해야하는 과제에 직면하게되었습니다. 이들은 서버에 새로운 요청 유형을 옵트 인 할 수있는 방법을 제공함으로써이를 수행하기로 결정했습니다. 이 옵트 인은 프리 플라이트 요청입니다.

따라서 사용자 정의 헤더가없는 GET / POST 요청은 프리 플라이트가 필요하지 않습니다. 이러한 요청은 CORS 이전에 이미 가능했기 때문입니다. 그러나 사용자 정의 헤더 또는 PUT / DELETE 요청이있는 요청 은 프리 플라이트 가 필요합니다. 이러한 요청 은 CORS 사양에 새로운 것이기 때문입니다. 서버가 CORS에 대해 아무 것도 모른다면 CORS 특정 헤더없이 응답하고 실제 요청은 수행되지 않습니다.

프리 플라이트 요청이 없으면 서버가 브라우저에서 예기치 않은 요청을 볼 수 있습니다. 서버가 이러한 유형의 요청에 대해 준비되지 않은 경우 보안 문제가 발생할 수 있습니다. CORS 프리 플라이트를 사용하면 도메인 간 요청을 안전하게 웹에 도입 할 수 있습니다.

CORS를 사용하면 이전에 cross-origin <img src>또는로 가능한 것보다 많은 헤더 및 메소드 유형을 지정할 수 있습니다 <form action>.

일부 서버는 브라우저가 출처 DELETE간 요청 또는 X-Requested-With헤더가있는 출처 간 요청과 같이 브라우저를 만들 수 없다는 가정으로 (잘못) 보호되었을 수 있으므로 이러한 요청은 "신뢰할 수 있습니다".

서버가 실제로 CORS를 지원하고 무작위 요청에 응답하는 것이 아니라는 것을 보장하기 위해 프리 플라이트가 실행됩니다.

코드를 사용하여 보는 다른 방법이 있습니다.

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

CORS 이전의 위의 악용 시도는 동일한 출처 정책을 위반하기 때문에 실패합니다. 이러한 방식으로 설계된 API는 브라우저의 기본 보안 모델에 의해 보호되므로 XSRF 보호가 필요하지 않았습니다. 사전 CORS 브라우저가 교차 출처 JSON POST를 생성하는 것은 불가능했습니다.

이제 CORS가 등장합니다. 사전 비행을 통해 CORS를 옵트 인 할 필요가없는 경우 갑자기이 사이트는 자체 결함없이 큰 취약점을 갖게됩니다.

일부 요청이 프리 플라이트를 건너 뛸 수있는 이유를 설명하기 위해 스펙에 의해 응답됩니다.

간단한 교차 출처 요청은이 사양을 준수하지 않는 현재 배포 된 사용자 에이전트가 생성 할 수있는 요청과 일치하는 것으로 정의되었습니다.

이를 풀기 위해 GET은 7.1.5에 정의 된 "간단한 방법"이기 때문에 미리 비행하지 않습니다. 사전 비행을 피하려면 헤더도 "단순"해야합니다. 이에 대한 타당성은 "간단한"교차 출처 GET 요청이 예를 들어 이미 수행 될 수 있다는 것입니다 <script src="">(JSONP의 작동 방식). src속성이 있는 요소는 사전 비행없이 교차 출처 GET을 트리거 할 수 있기 때문에 "단순한"XHR에 대한 사전 싸움을 요구할 경우 보안 이점이 없습니다.

다른 답변은 사전 싸움이 보안을 강화하는 이유에 초점을 맞추지 않는다고 생각합니다.

시나리오 :

1) 비행 전 . 공격자가 사용자가 safe-bank.com에 인증 된 상태에서 사이트 dummy-forums.com의 요청을 위조합니다
. 서버가 출처를 확인하지 않고 결함이있는 경우 브라우저 는 비행 전 요청을 발행합니다. OPTION 방법. 서버는 브라우저가 응답으로 기대하는 CORS를 전혀 모르므로 브라우저 가 진행되지 않습니다 (아무것도)

2) 비행 전없이 . 공격자는 위와 동일한 시나리오에서 요청을 위조하고, 브라우저는 즉시 POST 또는 PUT 요청을 발행하고, 서버가이를 승인하고 처리 할 수 ​​있습니다.

침입자가 임의의 임의의 호스트에서 직접 교차 출처로 요청을 보내는 경우 인증 이 없는 요청에 대해 생각할 가능성이 높습니다 . 위조 된 요청이지만 xsrf 요청은 아닙니다. 서버가 자격 증명을 확인하고 실패합니다. CORS는 자격 증명이있는 공격자가 요청을 발행하는 것을 막으려 고 시도하지 않지만 허용 목록이 이러한 공격의 벡터를 줄이는 데 도움이 될 수 있습니다.

프리 플라이트 메커니즘은 클라이언트와 서버간에 안전성과 일관성을 추가합니다. 캐싱을 사용할 수 없기 때문에 이것이 모든 요청에 ​​대해 추가 핸드 셰이크의 가치가 있는지는 모르겠지만 작동 방식입니다.

또한 사용자 데이터에 부작용 을 유발할 수있는 HTTP 요청 방법 (특히 GET 이외의 HTTP 방법 또는 특정 MIME 유형의 POST 사용)의 경우 사양에서 브라우저가 요청을 "사전"해야합니다.

출처

서버의 상태를 변경할 수있는 요청에는 비행 전 요청이 필요합니다. 요청에는 두 가지 유형이 있습니다.

1) 서버의 상태를 변경할 수없는 호출 (예 : GET) -사용자가 요청에 대한 응답을받을 수 있지만 (서버가 원점을 확인하지 않은 경우) 요청 도메인이 응답 헤더에 추가되지 않은 경우 Allow-Origin, 브라우저는 사용자에게 데이터를 표시하지 않습니다. 즉, 요청은 브라우저에서 전송되지만 사용자는 응답을 보거나 사용할 수 없습니다.

2) 서버에서 상태를 변경할 수있는 호출 (예 : POST, DELETE) -1) 이후 브라우저는 요청을 차단하지 않지만 응답, 상태 변경 호출은 사전 확인 없이는 허용되지 않아야합니다. . 브라우저에 대한 응답이 실패하더라도 이러한 호출은 호출의 출처를 확인하지 않는 트러스트 서버 (사이트 간 요청 위조라고 함)를 변경할 수 있습니다. 이러한 이유로, 상태 변경 호출을 서버로 보내기 전에 OPTIONS 호출을 수행하는 비행 전 요청 개념이 있습니다.

성능 에 대한 사전 요청이 아닙니까? 프리 플라이트 요청을 통해 클라이언트는 대량의 데이터를 전송하기 전에 (예 : PUT 메소드를 사용하는 JSON) 작업이 허용되는지 신속하게 알 수 있습니다. 또는 유선을 통해 인증 헤더의 민감한 데이터를 이동하기 전에.

PUT, DELETE 및 기타 사용자 정의 헤더 외에 다른 방법은 기본적으로 허용되지 않습니다 ( "Access-Control-Request-Methods"및 "Access-Control-Request-Headers"를 사용하여 명시적인 권한이 필요함). 이러한 작업은 GET 요청 대신 사용자 데이터에 더 많은 영향을 미칠 수 있기 때문에 이중 확인과 같습니다. 따라서 다음과 같이 들립니다.

" http : //foo.example 에서 교차 사이트 요청을 허용하는 것을 보았습니다 . DELETE 요청을 허용 하시겠습니까? 이러한 요청이 사용자 데이터에 미치는 영향을 고려 했습니까?"

사전 비행 요청과 이전 서버 혜택 간의 인용 상관 관계를 이해하지 못했습니다. CORS 이전에 또는 CORS 인식없이 구현 된 웹 서비스는 응답에 "Access-Control-Allow-Origin"헤더가 없기 때문에 사이트 간 요청을받지 않습니다.

CORS를 지원하는 브라우저에서 읽기 요청 (예 : GET)은 이미 동일한 출처 정책으로 보호됩니다. 인증 된 도메인 간 요청을 시도하는 악의적 인 웹 사이트 (예 : 피해자의 인터넷 뱅킹 웹 사이트 또는 라우터의 구성 인터페이스) 은행이나 라우터가 Access-Control-Allow-Origin헤더를 설정하지 않았기 때문에 반환 된 데이터를 읽을 수 있습니다 .

그러나으로 작성 피해는 요청이 웹 서버에 도착할 때 *는 웹 서버가 확인할 수 있습니다. 완료 (POST 등) 요청을 Origin웹 서버 중 하나가 필요가 없기 때문에 요청이 합법적인지 확인하기 위해 헤더를하지만,이 검사는 종종 구현되지 않습니다 CORS의 경우 또는 웹 서버가 CORS보다 오래되었으므로 도메인 간 POST가 동일한 출처 정책에 의해 완전히 금지되었다고 가정합니다.

그렇기 때문에 웹 서버는 도메인 간 쓰기 요청 수신 을 옵트 인 할 수 있습니다 .

_{* 본질적으로 CSJA의 AJAX 버전.}