CORS(Cross-Origin Resource Sharing) - 여기에 누락된 내용이 있습니까?

CORS(Cross-Origin Resource Sharing) - 여기에 누락된 내용이 있습니까?

저는 CORS에 대해 읽고 있었는데, 구현이 간단하면서도 효과적이라고 생각합니다.

하지만 제가 빠진 것이 아니라면 스펙에서 빠진 부분이 크다고 생각합니다.요청의 출처(및 선택적으로 자격 증명 포함)에 따라 리소스에 대한 액세스를 허용할지 여부를 결정하는 것은 외부 사이트인 것으로 알고 있습니다.이것으로 괜찮습니다.

하지만 페이지의 악성 코드가 사용자의 민감한 정보를 외국 사이트에 게시하려면 어떻게 해야 합니까?외국 사이트에서 분명히 요청을 인증할 것입니다.따라서, 제가 놓친 것이 없다면, CORS는 실제로 민감한 정보를 더 쉽게 훔칠 수 있게 해줍니다.

원래 사이트에서 페이지가 액세스할 수 있는 불변의 서버 목록도 제공할 수 있었다면 훨씬 더 말이 되었을 것이라고 생각합니다.

따라서 확장된 순서는 다음과 같습니다.

1. 허용 가능한 CORS 서버 목록(abc.com , xyz.com 등)을 페이지에 제공합니다.
2. 페이지가 abc.com 에 XHR 요청을 하려고 합니다. 허용 목록에 있고 인증이 정상적으로 진행되기 때문에 브라우저에서 이를 허용합니다.
3. 페이지가 malicious.com 에 XHR 요청을 작성하려고 합니다. 서버가 목록에 없기 때문에 로컬(브라우저에 의해) 거부된 요청입니다.

악성 코드가 여전히 JSONP를 사용하여 더러운 작업을 수행할 수 있다는 것을 알고 있지만, CORS를 완벽하게 구현하면 스크립트 태그 다중 사이트 허점이 닫히는 것을 의미한다고 생각했을 것입니다.

저는 또한 공식 CORS 스펙(http://www.w3.org/TR/cors) 을 확인했는데 이 문제에 대한 어떠한 언급도 찾을 수 없었습니다.

하지만 페이지의 악성 코드가 사용자의 민감한 정보를 외국 사이트에 게시하려면 어떻게 해야 합니까?

그게 어쨌단 말이에요?당신은 이미 CORS 없이도 그것을 할 수 있습니다. 2만큼 간단한 인터페이스로 및 을 통해 타사 를 전송할 수 .form.submit(),new Image 또는설정정을 설정window.location.

악성 코드가 중요한 정보에 액세스할 수 있는 경우 이미 완전히 손실되었습니다.

페이지가 malicious.com 에 XHR 요청을 하려고 합니다. 요청이 로컬에서 거부되었습니다.

페이지가 아직 화이트리스트에 포함되지 않은 사이트에 XHR 요청을 하려는 이유는 무엇입니까?

XSS 취약성으로 인해 주입된 악의적인 스크립트의 작업으로부터 보호하려는 경우 원인이 아니라 증상을 수정하려는 것입니다.

당신의 걱정은 전적으로 타당합니다.

그러나 더 우려되는 것은 이를 이용하기 위해 악성 코드가 존재할 필요가 없다는 사실입니다.공격자는 사용자가 설명한 문제를 이용하여 취약한 웹 페이지에 악의적인 JavaScript를 삽입할 수 있는 DOM 기반 사이트 간 스크립팅 취약성이 있습니다.문제는 단순히 데이터를 보낼 수 있는 곳이 아니라 데이터를 받을 수 있는 곳입니다.

여기서 이에 대해 더 자세히 설명하겠습니다.

• http://isisblogs.poly.edu/2011/06/22/cross-origin-resource-inclusion/
• http://files.meetup.com/2461862/Cross-Origin%20Resource%20Inclusion%20-%20Revision%203.pdf

제가 보기에 CORS는 순전히 가능한 것을 확장하고 안전하게 하려고 노력하는 것 같습니다.저는 이것이 분명히 보수적인 움직임이라고 생각합니다.보안을 강화하면서 다른 태그(스크립트/이미지)에 대해 보다 엄격한 교차 도메인 정책을 만들면 기존 코드가 많이 깨지고 새로운 기술을 채택하는 것이 훨씬 더 어려워집니다.그 보안 구멍을 막기 위해 뭔가 조치가 취해지기를 바라지만, 저는 그들이 먼저 쉬운 전환을 확실히 해야 한다고 생각합니다.

저는 또한 공식적인 CORS 스펙을 확인했지만 이 문제에 대한 언급을 찾을 수 없었습니다.

맞습니다. CORS 사양은 전혀 다른 문제를 해결하고 있습니다.문제를 더 악화시키는 것으로 잘못 알고 있습니다. 문제를 더 악화시키거나 악화시키지 않습니다. 악성 스크립트가 페이지에서 실행되면 이미 데이터를 어디로든 보낼 수 있기 때문입니다.

하지만 좋은 소식은 이 문제를 해결하기 위해 널리 구현된 사양이 있다는 것입니다. 바로 콘텐츠-보안-정책입니다.페이지에서 수행할 수 있는 작업을 제한하도록 브라우저에 지시할 수 있습니다.

예를 들어 브라우저에 인라인 스크립트를 실행하지 않도록 지시하면 많은 XSS 공격이 즉시 실패합니다.또는 여기서 요청한 대로 페이지가 접속할 수 있는 도메인을 브라우저에 명시적으로 알릴 수 있습니다.

문제는 사이트가 이미 액세스한 다른 사이트 리소스에 액세스할 수 있다는 것이 아닙니다.문제는 도메인 중 하나입니다. 회사에서 브라우저를 사용하고 있는데 Ajax 스크립트가 악의적으로 10.0.0.1(잠재적으로 내 게이트웨이)을 시도하기로 결정한 경우, 요청이 현재 내 컴퓨터(아마도 10.0.0.2)에서 오기 때문에 액세스할 수 있습니다.

그래서 해결책은 코르스입니다.그게 최선이라고 말하는 것은 아니지만, 그가 이 문제를 해결했습니다.

게이트웨이가 'bobthehacker.com '에서 수락한 오리진 헤더를 반환할 수 없는 경우 브라우저에서 요청을 거부합니다.이렇게 하면 오래되거나 준비되지 않은 서버를 처리할 수 있습니다.

게이트웨이가 myinternaldomain.com 도메인의 항목만 허용하는 경우 'bobthehacker.com '의 오리진을 거부합니다.SIMPLE CORS의 경우에도 실제로 결과를 반환합니다.기본적으로 서버를 구성하여 이 작업을 수행할 수 있습니다.그러면 결과가 브라우저에 로드되지 않고 삭제됩니다.

마지막으로, 특정 도메인을 허용하더라도 해당 사이트의 요청이 특정 모양을 준수하도록 허용 및 거부되는 헤더를 제어할 수 있습니다.

주 - 오리진 및 OPTIONS 헤더는 요청자에 의해 제어됩니다. 자신의 HTTP 요청을 작성하는 사용자는 원하는 모든 것을 입력할 수 있습니다.그러나 최신 CORS 호환 브라우저에서는 그렇지 않습니다.상호 작용을 제어하는 것은 브라우저입니다.브라우저로 인해 bobthehacker.com 에서 게이트웨이에 액세스할 수 없습니다.그것이 당신이 놓치고 있는 부분입니다.

저는 David의 걱정을 공유합니다.보안은 한 층씩 구축되어야 하며 오리진 서버에서 제공하는 화이트리스트가 좋은 접근 방식인 것 같습니다.

또한 이 화이트리스트는 기존의 허점(양식, 스크립트 태그 등)을 차단하는 데 사용될 수 있으므로 화이트리스트를 제공하는 서버가 역호환성 문제를 방지하도록 설계되었다고 가정해도 무방합니다.

언급URL : https://stackoverflow.com/questions/2533049/cross-origin-resource-sharing-cors-am-i-missing-something-here