CORS (Cross Origin Resource Sharing) 작동 방식에 대한 혼란

Question

내가 CORS에 대해 이해하는 바로는 이것이 작동 방식입니다. X. X 페이지를 제공하는 사이트 foo.com이 있습니다. X는 다른 도메인 표시 줄에 데이터를 게시하려고합니다. com. bar.com이 CORS를 사용하는 경우 (헤더에서 Access-Control-Allow-Origin foo.com을 생성 한 경우) 이제 X 페이지는 bar.com으로 데이터를 보낼 수 있습니다.

CORS를 작동 시키려면 bar.com에서 설정하는 것이 좋으며 foo.com과는 관련이 없습니다. bar.com이 이전 도메인의 요청을 허용하지 않도록하는 것이 중요합니다.

그러나이 은 실제로이 아닙니다. 나는 CORS가 foo.com이 누구와 통신 할 수 있는지를 지시 할 수 있도록 설계되었다고 생각했습니다. 앞의 예제로 돌아가지만 이번에는 X가 dodgy 스크립트에 의해 손상되어 evil.com에 비밀리에 데이터를 보내면 어떻게 CORS가이를 ​​멈추게할까요? evil.com은 CORS가 활성화되어 있으며 *로 설정되어 있으므로 어떤 요청도 수락합니다. 사용자가 사이트 foo.com을 사용한다고 생각하는 그런 식으로 무의식적으로 데이터를 evil.com에 보냅니다.

바코드 자체에 대한 모든 것이 사실이라면 브라우저가 정책을 적용하는 이유는 무엇입니까? foo.com을 가장하여 bar.com으로 데이터를 보내려고하는 Y 페이지를 제공하는 evil.com을 가지고있는 경우 이것이 당연한 생각할 수있는 상황입니다. 하지만 CORS는 브라우저에 의해 시행되며, evil.com을 bar.com에 가짜 요청을 보내는 프록시로 만듭니다 (데이터는 Y에서 evil.com으로, evil.com은 foo로 설정 됨). 그런 다음 bar.com으로 보냅니다.)

다른 방식으로 작동하는 경우 나에게 의미가 있습니다. foo.com은 CORS가 사용 가능하며 해당 헤더는 Access-Control-Allow-Origin bar.com으로 설정됩니다. 그렇게하면 루즈 스크립트는 브라우저에서 evil.com에 액세스하지 못하게됩니다. 그런 다음 스크립트가 실행되기 때문에 브라우저가 정책을 시행하는 것이 좋습니다. 루즈 사이트가 루즈 데이터를 bar.com에 보내지 못하도록 막지는 않지만 bar.com은 사용자 이름/암호로 자신을 보호 할 수 있습니다. foo.com에 X에서 데이터가 반환 될 것으로 예상되는 엔드 포인트가있는 경우 evil.com이 대신 데이터를 보내지 않도록 X에 토큰을 포함 할 수 있습니다.

나는 여기에서 근본적으로 중요한 것을 이해하지 못한다고 생각합니다. 도움을 정말로 바랄 것입니다.

Answer 1

그러나 이것은 실제로 나에게 이해가 가지 않습니다. 나는 CORS가 foo.com이 누구와 통신 할 수 있는지를 지시 할 수 있도록 설계되었다고 생각했습니다.

아니요, 약 bar.com 콘텐츠 사용을 제어합니다.

그러나 CORS가 브라우저에 의해 적용됩니다, 당신이해야 할 것 모두가 bar.com ...

그래로 원점 요청을 위조 전송하는 프록시를 evil.com 할 것입니다. 그렇게한다면 bar.com의 사람들은주의를 기울이고주의를 기울이며 서버의 요청을 허용하지 않습니다. 당신이 그것을 옮기면, 그들은 새로운 것을 허용하지 않습니다. 고약한 시간. 그러나 괴롭힘의 게임만큼이나 고통 스럽다. 요청이 foo.com의 각 개인 의 데스크탑에서 직접 온 것보다 훨씬 덜 고통 스럽다.

foo.com이 시행 할 수있는 일을 시행하는 것이 타당하지 않습니다. foo.com 이미은 foo.com의 콘텐츠와 스크립트를 제공하는 foo.com이기 때문에 foo.com이 할 수있는 일을 시행합니다.

Answer 2

Foo.com이나 Bar.com에 관한 정보가 아닙니다. 그것은 사용자에 관한 것입니다.

CORS가 보호하는 두 가지 사항이 있습니다. 첫 번째는 방화벽 뒤의 리소스에 대한 액세스입니다. 두 번째는 인증이나 기타 중요한 데이터 쿠키가있는 브라우저에서 요청을 보내지 않는 한 일반적으로 보호되는 리소스입니다.

CORS는 브라우저 기술이며, 서버의 지원을 통해 foo의 제한된 자유가 도메인 외부로 전화 할 수 있습니다. 이것은 크로스 도메인 스크립팅 (cross domain scripting)에 대한 제한에서 천공 된 제한된 구멍입니다.

누군가가 ORIGIN 헤더를 가짜로 만들어 CORS 프리 플라이트 또는 간단한 요청을 만들 수 있습니다. 물론 CORS를 사용하지 않고도 누구나 직접 Bar 서버에 직접 연결하여 요청할 수 있습니다. 모든 브라우저는 bar.com에 직접 연결하여 데이터를 가져올 수 있습니다. 그러나 현대적인 브라우저는 foo.com에서 bar.com 리소스에 액세스하는 스크립트를 실행하지 않습니다. 웹 사이트를 방문하는 사람들은 쿠키를 사용하도록 설계된 사이트 또는 브라우저가 회사 방화벽 뒤에 있다는 사실을 알지 못합니다.

허용되는 대답은 잘못된 것입니다. bar.com이 리소스를 보호하는 것이 아니라 인증 및 승인을 통해이를 수행합니다. CORS 요청을 보내려면 프록시를 만들 필요가 없습니다. CORS 요청을 제거하는 프록시를 만듭니다 (자동으로 프리 플라이트 요청에 응답하고 브라우저에 적절한 헤더를 반환하지만 바에 대한 일반 요청을 보냅니다). com). 그러나 bar.com의 리소스를 얻으려면 여전히 인증이 필요하며 foo.com은 CORS가 보호하는 크로스 도메인 스크립팅 구멍을 악용하기 위해 프록시를 설치해야합니다.

하지만 결론 문장은 정확합니다. foo.com은 자원을 제어하지 않습니다. 브라우저라고하며, bar.com으로 신속하게 확인하여 의도 한 것이 있는지 물어 봅니다. 영업에서

:

그 자체 보호 정말로 bar.com에 대한 경우, 왜 브라우저가 정책을 시행 할 않습니다? 생각할 수있는 유일한 상황 인 은 이 foo.com을 가장하여 bar.com으로 데이터를 보내려고하는 Y 페이지를 제공하는 evil.com을 가지고있는 경우에 의미가 있습니다. 하지만 CORS가 브라우저에 의해 시행되는 CORS는 입니다. evil.com은 프록시에서 가짜 요청을 bar.com으로 전송하는 입니다 (데이터는 Y에서 evil.com으로 이동하고 evil.com은 가짜로 설정 함). 출처가 foo.com 인 경우 bar.com으로 전송합니다.

evil.com은 이미 bar can (또는 curl 또는 wget 등)을 사용하는 사람과 마찬가지로 bar.com에 연결할 수 있습니다. 문제는 evil.com이 브라우저를 bar.com에 연결하도록 강제 할 수 있습니다. bar.com에는 IP 필터, 쿠키, 방화벽 등을 보호 할 수있는 bar.com이 연결되어 있지만 javascript는 브라우저를 사용하여 연결할 수 있습니다. 따라서 브라우저는 사용자를 보호합니다. 도메인 간 스크립팅 금지. 그러나 때로는 교차 도메인 스크립트에 유용합니다 (예 : google apis 또는 청구서 지불 서비스에 연결하는 은행 등). CORS는이 인스턴스에서 브라우저가 OK임을 알립니다.

구멍이 없거나 표준이 가장 좋거나 브라우저에 구현에 구멍이 없거나 사이트가 너무 관대하다는 것은 아닙니다. 그러나 그들은 다른 질문입니다 ...