비행 전 CORS 요청을 도입한 동기는 무엇입니까?

비행 전 CORS 요청을 도입한 동기는 무엇입니까?

크로스 오리진 자원 공유는 웹 페이지가 (Wikipedia에서) 다른 도메인에 XMLHttpRequests를 만들 수 있는 메커니즘입니다.

나는 지난 며칠간 CORS를 만지작거렸고 나는 모든 것이 어떻게 돌아가는지 꽤 잘 알고 있다고 생각한다.

그래서 제 질문은 CORS/Pre-flight가 어떻게 작동하느냐가 아니라 새로운 요청 유형으로 Pre-flight를 생각해 낸 이유에 관한 것입니다.서버 A가 실제 요구(RR)의 수용 여부를 확인하기 위해 서버 B에 프리플라이트(PR)를 송신할 필요가 있는 이유를 알 수 없습니다.B가 사전 PR 없이 RR을 수락/거부하는 것은 분명 가능합니다.

꽤 검색한 결과, 다음의 정보를 www.w3.org(7.1.5)에서 찾았습니다.

이 사양이 존재하기 전에는 특정 사용자 에이전트에서 발신할 수 없었던 크로스 오리진 요구로부터 리소스를 보호하기 위해 리소스가 이 사양을 인식하고 있는지 확인하기 위한 프리플라이트 요청이 이루어집니다.

나는 이것이 지금까지 가장 이해하기 어려운 문장이라고 생각한다.제 해석으로는 ('최상의 추측'이라고 부르는 것이 좋을 것 같습니다)스펙을 인식하지 못하는 서버 C로부터의 요구에 대해서 서버 B를 보호하는 것입니다.

PR + RR이 RR 단독보다 더 잘 해결되는 시나리오를 설명/보여줄 수 있나요?

비행 전 요청의 목적에 대해 잠시 혼란스러웠지만 이제 알 것 같습니다.

중요한 통찰력은 비행 전 요청은 보안 문제가 아니라는 것입니다.오히려 규칙을 바꾸지 않는 것입니다.

비행 전 요청은 보안과는 무관하며 CORS를 의식하여 현재 개발 중인 애플리케이션과는 관계가 없습니다.오히려 프리플라이트 메커니즘은 CORS를 인식하지 않고 개발된 서버에 도움이 되며, 클라이언트와 서버 간의 건전성 체크로서 기능합니다.CORS의 개발자는, 예를 들면, 양쪽이 옵트인 할 수 있도록 프리플라이트 메카니즘을 발명한 크로스 도메인 DELETE 요구 등, 결코 수신할 수 없다는 가정에 의존하는 서버가 충분히 있다고 느끼고 있었습니다.이들은 단순히 교차 도메인 호출을 활성화하는 대안으로 기존 애플리케이션을 너무 많이 손상시킬 수 있다고 생각했습니다.

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

1. 더 이상 개발이 진행되지 않고 CORS 이전에 개발된 오래된 서버입니다.이러한 서버는 교차 도메인 삭제 요청을 수신하지 못할 것으로 가정할 수 있습니다.이 시나리오는 비행 전 메커니즘의 주요 수혜자이다.네, 이러한 서비스는 이미 악의적인 사용자 에이전트나 부적합 사용자 에이전트에 의해 악용될 수 있습니다(또한 CORS는 이를 변경하기 위해 아무것도 하지 않습니다).그러나 CORS를 사용하는 세계에서는 클라이언트와 서버가 웹의 기본 규칙이 변경되어도 파손되지 않도록 하기 위해 프리플라이트 메커니즘에 의해 추가적인 '온전성 검사'가 제공됩니다.

2. 아직 개발 중이지만 오래된 코드가 다수 포함되어 있어 오래된 코드를 모두 감사하여 크로스 도메인 환경에서 정상적으로 동작하도록 하는 것이 바람직하지 않은 서버입니다.이 시나리오에서는 서버가 「Now Illow this specific header」, 「Now Illow this specific HTTP verbe」, 「Now Illlow this specific allow this specific HTTP verbe」, 「Now Ilow Ilow I allow I allow I allow this perve this cookie/auth information to specificate transmitation to sending이 시나리오는 비행 전 메커니즘으로부터 이익을 얻는다.

3. CORS를 인식하여 작성된 새로운 서버.표준 보안 관례에 따라 서버는 들어오는 요청 시 리소스를 보호해야 합니다. 서버는 클라이언트가 악의적인 작업을 수행하지 않도록 신뢰할 수 없습니다.이 시나리오는 프리플라이트 메커니즘의 이점을 얻을 수 없습니다.프리플라이트 메커니즘은 리소스를 적절하게 보호한 서버에 추가 보안을 제공하지 않습니다.

비행 전 요청을 도입한 동기는 무엇이었습니까?

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

이것이 원래 사양의 이 파트의 의미입니다.「이 사양이 존재하기 전에는 특정의 유저 에이전트로부터 발신할 수 없었던 크로스 오리진 요구로부터 자원을 보호하기 위해서, 리소스가 이 사양을 인식하고 있는 것을 확실히 하기 위해서, 비행전의 요구가 행해집니다.」

예를 하나 들어볼래?

브라우저 사용자가 은행 사이트에 로그인했다고 가정해 보겠습니다.A.com악성 사이트로 이동했을 때B.com, 이 페이지에는, 송신하려고 하는 Javascript 가 포함되어 있습니다.DELETE에 요청하다A.com/account사용자가 로그인하고 있기 때문에A.com이 요구는 송신된 경우 사용자를 식별하는 쿠키가 포함됩니다.

CORS 이전에는 브라우저의 Same Origin Policy에 의해 이 요청의 송신이 차단되었습니다.하지만 CORS의 목적은 단지 이런 종류의 이종간 통신을 가능하게 하는 것이기 때문에, 그것은 더 이상 적절하지 않습니다.

브라우저는 단순히 전송만 할 수 있습니다.DELETE서버가 처리 방법을 결정하도록 합니다.하지만 만약A.comCORS 프로토콜을 모르나요?앞으로 나아가서 위험한 일을 실행할지도 모른다.DELETE브라우저의 같은 오리진정책으로 인해 이러한 요구를 수신할 수 없다고 가정했을 가능성이 있습니다.따라서 이러한 공격에 대해 강화되지 않았을 수도 있습니다.

따라서 이러한 비 CORS 인식 서버를 보호하려면 먼저 브라우저에서 사전 실행 요청을 전송해야 합니다.이 새로운 종류의 요구는 CORS 대응 서버만이 적절히 응답할 수 있기 때문에 브라우저는 실제 데이터를 전송해도 안전한지 여부를 확인할 수 있습니다.DELETE.

왜 이렇게 브라우저에 대해 소란을 피우는 거죠? 공격자는 그냥 메시지를 보낼 수 없나요?DELETE자신의 컴퓨터에서 요청했을까요?

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

사이트 간 요청 위조처럼 들리는데요, 사이트에 있는 양식이B.com에 제출할 수 있다A.com사용자의 쿠키를 사용하여 피해를 입힙니다.

맞아요.다른 방법으로 말하면, 비 CORS 인식 서버의 CSRF 공격면이 증가하지 않도록 프리플라이트 요구가 작성되어 있는 것입니다.

그렇지만POST사전 비행이 필요하지 않은 방법으로 나열됩니다.이 기능을 사용하면 다음과 같이 상태를 변경하고 데이터를 삭제할 수 있습니다.DELETE!

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

좋아, 마지못해 비행 전 요청의 필요성을 받아들이겠어그런데 왜 서버상의 모든 자원(URL)에 대해 이 작업을 수행해야 합니까?서버가 CORS를 처리하거나 처리하지 않습니다.

그거 확실한 거니?여러 서버가 단일 도메인에 대한 요청을 처리하는 것은 드문 일이 아닙니다.예를 들어 다음과 같은 요구가 있을 수 있습니다.A.com/url11종류의 서버 및 요구에 의해 처리됩니다.A.com/url2다른 종류의 서버에 의해 처리됩니다.일반적으로 단일 리소스를 처리하는 서버가 해당 도메인의 모든 리소스에 대해 보안을 보장할 수 있는 것은 아닙니다.

좋아, 타협하자서버가 발언 가능한 자원을 정확하게 기술할 수 있도록 하는 새로운 CORS 헤더를 작성하여 이러한 URL에 대한 추가 프리플라이트 요구를 회피합니다.

좋은 생각이야!사실, 헤더는Access-Control-Policy-Path바로 이 목적을 위해 제안되었습니다.단, 최종적으로는 사양에서 제외되었습니다.이는 일부 서버가 URI 사양을 잘못 구현했기 때문에 브라우저에서 안전하다고 생각되는 경로에 대한 요구는 실제로 파손된 서버에서는 안전하지 않기 때문입니다.

퍼포먼스보다 보안을 우선시하여 브라우저가 기존 서버를 위험에 빠트리지 않고 즉시 CORS 사양을 구현할 수 있도록 한 신중한 결정이었습니까?아니면 특정 시간에 특정 서버의 버그를 수용하기 위해 인터넷을 대역폭 낭비와 레이텐시 2배로 만든 것은 근시안적이었습니까?

의견이 다르다.

적어도 브라우저는 하나의 URL을 위해 프리플라이를 캐시할 수 있습니까?

네, 아마 오래 걸리진 않을 거예요WebKit 브라우저에서는 현재 최대 비행 전 캐시 시간은 10분입니다.

서버가 CORS를 인식하고 있기 때문에 비행 전 요청에 의한 보호가 필요하지 않은 경우, 서버를 피할 수 있는 방법은 없습니까?

유일한 실제 옵션은 요청 시 CORS 안전한 메서드와 헤더를 사용하는 것입니다.즉, 커스텀헤더는 생략할 수 있습니다(예:X-Requested-With)의 변경Content-Type, 또는 그 이상.

CORS는 안전하지 않은 요구를 모두 차단하는 것은 아니기 때문에 무엇을 하든 적절한 CSRF 보호가 확립되어 있는지 확인해야 합니다.원래 사양대로 "단순한 요청이 검색 이외의 중요성을 갖는 리소스는 교차 사이트 요청 위변조로부터 스스로를 보호해야 합니다.

CORS 이전에 교차 도메인 요청의 세계를 고려하십시오.표준 폼 POST를 실행하거나script또는image태그를 지정하여 GET 요청을 발행합니다.GET/POST 이외에는 다른 요청 유형을 만들 수 없으며 이러한 요청에 대해 커스텀헤더를 발행할 수 없습니다.

CORS의 등장으로, 스펙 저자들은 웹의 기존 의미론을 깨지 않고 새로운 교차 도메인 메커니즘을 도입해야 하는 과제에 직면했습니다.이들은 서버에 새로운 요청 유형을 선택할 수 있는 방법을 제공함으로써 이를 수행하기로 했습니다.이 옵트인은 비행 전 요청입니다.

따라서 커스텀 헤더가 없는 GET/POST 요청은 CORS 이전에 이미 가능했기 때문에 사전 전송이 필요하지 않습니다.단, 커스텀헤더가 있는 요구나 PUT/DELETE 요구는 CORS 사양에 새로 포함되어 있기 때문에 프리플라이가 필요합니다.서버가 CORS에 대해 아무것도 모르는 경우, CORS 고유의 헤더를 사용하지 않고 응답해, 실제의 요구는 행해지지 않습니다.

프리플라이트 요구가 없으면 서버는 브라우저로부터의 예기치 않은 요구를 수신하기 시작할 수 있습니다.서버가 이러한 유형의 요청에 대해 준비되지 않은 경우 보안 문제가 발생할 수 있습니다.CORS 프리플라이트에서는 도메인 간 요구를 안전한 방법으로 웹에 도입할 수 있습니다.

CORS를 사용하면 이전에 크로스 오리진에서 가능했던 것보다 더 많은 헤더 및 메서드 유형을 지정할 수 있습니다.<img src>또는<form action>.

일부 서버에서는 브라우저가 할 수 없는 것을 전제로 (부실하게) 보호되고 있을 가능성이 있습니다(예: 크로스 오리진).DELETE요구 또는 교차 요구X-Requested-With따라서 이러한 요청은 "수정"됩니다.

서버가 랜덤한 요구에 응답할 뿐만 아니라 실제로 CORS를 지원하는지 확인하기 위해 사전 비행이 실행됩니다.

다른 답변들은 전투 전에 보안이 강화되는 이유에 초점을 맞추고 있지 않다고 생각합니다.

시나리오:

1) 프리플라이트 포함.공격자는 사용자가 safe-bank.com에 대해 인증되는 동안 사이트 dummy-forums.com에서 요청을 위조합니다.
서버가 오리진을 확인하지 않고 결함이 있는 경우 브라우저는 OPTION 메서드인 사전 실행 요청을 발행합니다.서버는 브라우저가 응답으로 기대하는 CORS를 인식하지 않으므로 브라우저는 진행되지 않습니다(무해).

2) 비행 전 미포함.공격자가 위와 같은 시나리오에서 요청을 위조하면 브라우저가 POST 또는 PUT 요청을 즉시 발행하고 서버가 요청을 수락하여 처리할 수 있습니다. 이로 인해 일부 피해가 발생할 수 있습니다.

공격자가 임의의 호스트에서 요청을 직접 크로스 오리진(cross origin)으로 전송하는 경우 인증이 없는 요청을 생각할 가능성이 높습니다.이 요청은 위조된 요청이지만 xsrf 요청은 아닙니다.따라서 서버는 자격 증명을 확인하고 실패합니다.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는 이렇게 동작합니다).a를 가진 요소가 있으면src속성을 사용하면 크로스 오리진 GET를 트리거할 수 있으며, 프리플라이가 필요 없기 때문에 "단순한" XHR에 대한 사전 전투를 요구해도 보안상의 이점은 없습니다.

또한 사용자 데이터에 부작용을 일으킬 수 있는HTTP 요청 방식(특히 GET 이외의 HTTP 방식 또는 특정 MIME 유형에서의 POST 사용)에 대해서는 브라우저가 요청을 "사전 전송"하도록 규정되어 있습니다.

원천

CORS를 지원하는 브라우저에서는읽기 요구(GET 등)는 이미 같은 발신기지 정책에 의해 보호되고 있습니다.예를 들어, 인증된 교차 도메인 요구를 작성하려고 하는 악의적인 웹 사이트는 은행 또는 라우터가 반환된 데이터를 읽을 수 없습니다.Access-Control-Allow-Originheader를 클릭합니다.

다만, 기입 요구(POST 등)에서는, 요구가 Web 서버에 도착했을 때에 파손이 발생합니다.* 웹 서버는 다음을 체크할 수 있습니다.Origin헤더는 요구가 정당한지를 판별합니다만, 이 체크는, 대부분의 경우 실장되지 않습니다.이는 웹 서버가 CORS를 필요로 하지 않거나 웹 서버가 CORS보다 오래된 것이기 때문입니다.따라서 도메인 간 POST는 같은 발신기지 정책에 의해 완전히 금지되어 있다고 가정하고 있기 때문입니다.

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

_{* 기본적으로 CSRF의 AJAX 버전입니다.}

사전에 전달된 요청은 퍼포먼스에 관한 것 아닌가요?사전 전송 요청을 통해 클라이언트는 PUT 메서드를 사용하여 JSON에서 대량의 데이터를 전송하기 전에 작업이 허용되는지 여부를 빠르게 알 수 있습니다.또는 유선 경유로 인증 헤더의 기밀 데이터를 전송하기 전에.

사용자 지정 헤더 외에 PUT, DELETE 및 기타 메서드는 기본적으로 허용되지 않습니다('Access-Control-Request-Methods' 및 'Access-Control-Request-Headers'와 같은 명시적 권한이 필요합니다). 이러한 작업은 사용자 데이터에 더 많은 영향을 미칠 수 있으므로 GET 요청을 대신합니다.그 소리는 다음과 같습니다.

"http://foo.example에서 사이트 간 요청을 허용하는 것을 보았습니다만, DELETE 요청을 허용하시겠습니까?이러한 요구가 사용자 데이터에 미칠 수 있는 영향을 고려했습니까?"

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

언급URL : https://stackoverflow.com/questions/15381105/what-is-the-motivation-behind-the-introduction-of-preflight-cors-requests