CORS (Cross-Origin Resource Sharing)에 대해 읽은 후 보안을 향상시키는 방법을 이해하지 못합니다. 올바른 ORIGIN 헤더가 전송되면 교차 도메인 AJAX 통신이 허용됩니다. 예를 들어 내가 보내면
원산지 : http://example.com
서버는이 도메인이 화이트리스트에 있는지 확인하고 있다면 헤더 :
Access-Control-Allow-Origin : [여기에 수신 된 URL]
응답과 함께 다시 전송됩니다 (간단한 경우이며 사전 요청도 있지만 질문은 동일합니다).
정말 안전한가요? 누군가 정보를 받고자한다면 ORIGIN 헤더를 위조하는 것은 정말 사소한 작업처럼 보입니다. 또한 표준은 정책이 브라우저에서 시행되어 Access-Control-Allow-Origin이 올바르지 않은 경우 응답을 차단한다고 말합니다. 누구든지 해당 정보를 얻으려고하면 표준 브라우저를 사용하여 차단하지 않을 것입니다.
답변:
웹 브라우저에서 JavaScript로 Origin 헤더를 위조 할 수 없습니다. CORS는이를 방지하도록 설계되었습니다.
웹 브라우저 외부에서는 중요하지 않습니다. 사람들이 대중이 사용할 수있는 데이터를 얻지 못하도록 설계되지 않았습니다. 대중이 그것을 얻지 않고는 대중에게 공개 할 수 없습니다.
다음과 같이 설계되었습니다.
Bob이 Charlie의 웹 사이트를 방문하면 Charlie는 JS를 Bob의 브라우저로 보낼 수 없으므로 Alice의 웹 사이트에서 데이터를 가져와 Charlie에게 보냅니다.
위의 상황은 Bob이 Alice의 웹 사이트에 댓글 게시, 데이터 삭제 또는 일반 대중이 사용할 수 없는 데이터를 볼 수있는 사용자 계정을 가지고있는 경우 더욱 중요해집니다 . 찰리의 JS는 보호없이 Bob의 브라우저에 알릴 수 있기 때문입니다. Bob의 등 뒤에서이를 수행하고 결과를 Charlie에게 보냅니다.
권한이없는 사람이 데이터를 보지 못하도록하려면 암호, SSL 클라이언트 인증서 또는 기타 신원 기반 인증 / 승인 수단으로 데이터를 보호해야합니다.
목적은 이것을 방지하는 것입니다.
아이디어는 은행 웹 사이트에서 웹 사이트 X의 스크립트가 은행의 페이지에 액세스 할 수 있도록 신뢰할 수 있는지 여부를 브라우저에 알리는 방법이 필요하다는 것입니다.
Access-Control-Allow-Origin기원은 (에 지정된 헤더 지정 Origin헤더)는 리소스에 대한 액세스가 허용된다. 일반적으로 출처가 동일한 요청 만 그렇게 할 수 있습니다. 여기서 가장 중요한 부분은 허용 / 거부가 서버가 아닌 브라우저에 의해 시행된다는 것입니다. 이것은 Access-Control-Allow-Origin서버 나 서버 자체의 리소스가 아닌 브라우저를 보호 한다는 것을 의미 합니다.
@jcoder의 답변에 추가하기 위해 Origin 하기 위해 헤더 서버에서 요청한 리소스를 보호하는 것이 아닙니다. 공격자가 적절한 도구로이 헤더를 스푸핑 할 수 있기 때문에이 작업은 다른 수단을 통해 서버 자체에 달려 있습니다.
포인트 Origin헤더 사용자를 보호하는 것입니다. 시나리오는 다음과 같습니다.
공격자가 악성 웹 사이트를 생성 M
사용자 Alice는 실제로 CORS를 지원하는 서버 B에서 CORS를 통해 일부 작업을 수행하려는 스크립트를 포함하는 M에 연결하도록 속임수를 사용합니다.
B는 Access-Control-Allow-Origin헤더에 M이 없을 것입니다. 왜 그렇습니까?
핵심은 M이 Origin헤더 를 스푸핑하거나 덮어 쓸 수단이 없다는 것입니다 . 요청이 Alice의 브라우저에서 시작되기 때문입니다. 따라서 그녀의 브라우저는 B에 Origin없는 M으로 (정확한) 값 을 설정 Access-Control-Allow-Origin하므로 요청이 실패합니다.
앨리스는 Origin헤더를 직접 변경할 수 있지만, 자신이 자신을 해치고 있다는 것을 의미하는 이유는 무엇입니까?
TL; DR : Origin 헤더는 무고한 사용자를 보호합니다. 서버의 리소스를 보호하지 않습니다. 공격자가 자신의 컴퓨터에서 스푸핑 할 수 있지만 자신이 제어하지 않는 컴퓨터에서는 스푸핑 할 수 없습니다.
일치하는 Origin헤더가 승인 된 액세스를 의미하지 않기 때문에 서버는 여전히 리소스를 보호해야 합니다. 그러나 Origin일치하지 않는 헤더는 무단 액세스를 의미합니다.
동일한 출처 정책의 목적은 사람들이 일반적으로 웹 사이트 콘텐츠에 액세스하는 것을 막는 것이 아닙니다. 누군가 그렇게하고 싶다면 브라우저도 필요하지 않습니다. 요점은 필요한 액세스 권한없이 다른 도메인의 콘텐츠에 액세스하는 클라이언트 스크립트 를 중지 하는 것입니다. 동일한 출처 정책에 대한 Wikipedia 항목을 참조하십시오 .
CORS에 대해 읽은 후 보안을 향상시키는 방법을 이해하지 못합니다.
CORS는 보안을 향상시키지 않습니다. CORS는 서버가 외부 도메인에서 액세스하는 방법을 브라우저에 알리는 메커니즘을 제공하며 CORS 이전에 존재했던 브라우저 보안 모델 (즉, 동일한 출처 정책) 과 일치하는 방식으로이를 시도합니다. ) .
그러나 동일 출처 정책 및 CORS는 범위가 제한됩니다. 특히 CORS 사양 자체에는 요청을 거부하는 메커니즘이 없습니다. 헤더를 사용하여 외부 도메인의 페이지가 응답을 읽지 못하도록 브라우저에 알릴 수 있습니다. 또한 프리 플라이트 요청의 경우 외부 도메인에서 특정 요청을 보내지 않도록 브라우저에 요청할 수 있습니다. 그러나 CORS는 서버가 실제 요청을 거부 (즉, 실행하지 않음)하는 수단을 지정하지 않습니다.
예를 들어 보겠습니다. 사용자가 사이트에 로그인되어 있습니다.A 쿠키를 통해 . 사용자 M가를 수행하는 양식을 제출하려고하는 악성 사이트를로드 POST합니다 A. 무슨 일이 일어날 것? CORS의 유무 M에 관계없이 , 허용 도메인 유무 에 관계없이 브라우저는 A사용자의 인증 쿠키와 함께 요청을 보내고 서버는 악성 프로그램을 실행합니다.POST 사용자가 시작한 것처럼 을 합니다.
이 공격을 Cross-Site Request Forgery라고합니다. 하며 CORS 자체는이를 완화하기 위해 아무것도하지 않습니다. 그렇기 때문에 사용자를 대신하여 데이터 변경 요청을 허용하는 경우 CSRF 보호가 매우 중요합니다.
이제 Origin헤더 사용은 CSRF 보호의 중요한 부분이 될 수 있습니다. 실제로이를 확인하는 것은 다각적 인 CSRF 방어에 대한 현재 권장 사항의 일부입니다 . 그러나 그 사용Origin 헤더의 CORS 사양을 벗어납니다.
요컨대 CORS는 기존의 동일 출처 정책 보안 모델을 다른 허용 도메인으로 확장하는 데 유용한 사양입니다. 보안을 추가하지 않으며 사이트에는 CORS 이전과 동일한 종류의 방어 메커니즘이 필요합니다.
나는 대답하기 늦었지만 여기에 어떤 게시물도 실제로 원하는 대답을 제공한다고 생각하지 않습니다. 가장 중요한 점은 브라우저가 origin헤더 값을 쓰는 에이전트라는 것입니다 . 악의적 인 스크립트는 origin헤더 값을 쓸 수 없습니다 . 서버가 Access-Control-Allow-Origin헤더로 응답 하면 브라우저는이 헤더에origin 이전에 보낸 값 . 그렇지 않은 경우 오류를 트리거하고 값을 요청하는 스크립트로 반환하지 않습니다. 이 질문에 대한 다른 답변은 악의적 인 스크립트에 대한 답변을 거부하고 싶을 때 좋은 시나리오를 제시합니다.
@daniel f는 또한 질문에 대한 좋은 대답을 제공합니다.