CORS는 교차 도메인 AJAX 요청을 수행하는 안전한 방법입니까?

CORS는 교차 도메인 AJAX 요청을 수행하는 안전한 방법입니까?

---

CORS (Cross-Origin Resource Sharing)에 대해 읽은 후 보안을 향상시키는 방법을 이해하지 못합니다. 올바른 ORIGIN 헤더가 전송되면 교차 도메인 AJAX 통신이 허용됩니다. 예를 들어 내가 보내면

원산지 : http://example.com

서버는이 도메인이 화이트리스트에 있는지 확인하고 있다면 헤더 :

Access-Control-Allow-Origin : [여기에 수신 된 URL]

응답과 함께 다시 전송됩니다 (간단한 경우이며 사전 요청도 있지만 질문은 동일합니다).

정말 안전한가요? 누군가가 정보를 받고 싶다면 ORIGIN 헤더를 위조하는 것은 정말 사소한 작업처럼 보입니다. 또한 표준은 정책이 브라우저에서 시행되어 Access-Control-Allow-Origin이 올바르지 않은 경우 응답을 차단한다고 말합니다. 누구든지 해당 정보를 얻으려고하면 표준 브라우저를 사용하여 차단하지 않을 것입니다.

---

사람들이 데이터를 얻는 것을 막도록 설계되지 않았습니다. 사람들이 그것을 얻지 않고는 그것을 드러 낼 수 없습니다.

다음과 같이 설계되었습니다.

• Ajax를 통해 액세스 할 수 있도록 설계된 API를 제공하는 Alice
• 웹 브라우저 사용자 Bob
• 자체 웹 사이트를 운영하는 제 3 자 Charlie

Bob이 Charlie의 웹 사이트를 방문하면 Charlie는 JS를 Bob의 브라우저로 보낼 수 없으므로 Alice의 웹 사이트에서 데이터를 가져와 Charlie에게 보냅니다.

위의 상황은 Bob이 댓글 게시 또는 데이터 삭제와 같은 작업을 수행 할 수있는 Alice의 웹 사이트에 사용자 계정을 가지고있는 경우 더욱 중요해집니다. 찰리는 보호없이 Bob의 브라우저에서 Bob의 뒤에서이를 수행하도록 할 수 있기 때문입니다.

권한이없는 사람이 데이터를 보지 못하도록하려면 비밀번호, SSL 클라이언트 인증서 또는 기타 신원 기반 인증 / 승인 수단으로 보호해야합니다.

---

목적은 이것을 방지하는 것입니다.

• 웹 사이트 X로 이동합니다.
• 웹 사이트 X의 작성자가 귀하의 브라우저로 전송되는 사악한 스크립트를 작성했습니다.
• 브라우저에서 실행되는 스크립트는 은행 웹 사이트에 로그인하여 악의적 인 작업 을 수행하며 브라우저에서 실행되는 것처럼 실행되기 때문에 그렇게 할 수 있는 권한이 있습니다.

아이디어는 은행의 웹 사이트에서 웹 사이트 X의 스크립트가 은행의 페이지에 액세스하는 데 신뢰할 수 있는지 여부를 브라우저에 알리는 방법이 필요하다는 것입니다.

---

@jcoder의 대답을 추가 Origin하기 위해 헤더 의 전체 요점은 서버에서 요청한 리소스를 보호하는 것이 아닙니다. 공격자가 적절한 도구를 사용하여이 헤더를 스푸핑 할 수 있기 때문에이 작업은 다른 수단을 통해 서버 자체에 달려 있습니다.

Origin헤더 의 요점은 사용자를 보호하는 것입니다. 시나리오는 다음과 같습니다.

• 공격자가 악성 웹 사이트를 생성 M

• 사용자 Alice는 실제로 CORS를 지원하는 서버 B에서 CORS를 통해 일부 작업을 수행하려는 스크립트를 포함하는 M에 연결하도록 속임수를 사용합니다.

• B는 Access-Control-Allow-Origin헤더에 M이 없을 것입니다. 왜 그렇습니까?

• 핵심은 M이 Origin헤더 를 스푸핑하거나 덮어 쓸 수단이 없다는 것입니다 . 요청은 Alice의 브라우저에서 시작되기 때문입니다. 따라서 그녀의 브라우저는 (정확한) OriginM Access-Control-Allow-Origin을 B에 없는 M으로 설정 하므로 요청이 실패합니다.

앨리스는 Origin헤더를 직접 변경할 수 있지만, 자신이 해를 끼치고 있다는 것을 의미하는 이유는 무엇입니까?

요약 : Origin헤더는 무고한 사용자를 보호합니다. 서버의 리소스를 보호하지 않습니다. 공격자가 자신의 컴퓨터에서 스푸핑 할 수 있지만 자신이 제어하지 않는 컴퓨터에서는 스푸핑 할 수 없습니다.

일치하는 Origin헤더가 승인 된 액세스를 의미하지 않기 때문에 서버는 여전히 리소스를 보호해야 합니다. 그러나 Origin일치하지 않는 헤더는 무단 액세스를 의미합니다.

---

동일한 출처 정책의 목적은 사람들이 일반적으로 웹 사이트 콘텐츠에 액세스하는 것을 막는 것이 아닙니다. 누군가 그렇게하고 싶다면 브라우저도 필요하지 않습니다. 요점은 필요한 액세스 권한없이 다른 도메인의 콘텐츠에 액세스하는 클라이언트 스크립트 를 중지 하는 것입니다. 동일한 출처 정책에 대한 Wikipedia 항목을 참조하십시오 .

---

CORS에 대해 읽은 후 보안을 향상시키는 방법을 이해하지 못합니다.

CORS는 보안을 향상시키지 않습니다. CORS는 서버가 외부 도메인에서 액세스하는 방법을 브라우저에 알리는 메커니즘을 제공하며 CORS 이전에 존재했던 브라우저 보안 모델 (즉, 동일한 출처 정책 ) 과 일치하는 방식으로이를 시도합니다 .

그러나 동일 출처 정책 및 CORS는 범위가 제한됩니다. 특히 CORS 사양 자체에는 요청을 거부하는 메커니즘이 없습니다. 헤더를 사용하여 외부 도메인의 페이지가 응답을 읽지 못하도록 브라우저에 알릴 수 있습니다. 또한 프리 플라이트 요청의 경우 외부 도메인에서 특정 요청을 보내지 않도록 브라우저에 요청할 수 있습니다. 그러나 CORS는 서버가 실제 요청을 거부 (즉, 실행하지 않음)하는 수단을 지정하지 않습니다.

Let's take an example. A user is logged in to site A via a cookie. The user loads malicious site M, which tries to submit a form that does a POST to A. What will happen? Well, with or without CORS, and with or without M being an allowed domain, the browser will send the request to A with the user's authorization cookie, and the server will execute the malicious POST as if the user initiated it.

This attack is called Cross-Site Request Forgery, and CORS itself does nothing to mitigate it. That's why CSRF protections are so important if you allow requests to change data on behalf of users.

Now, the use of the Origin header can be an important part of your CSRF protection. Indeed, checking it is part of the current recommendation for multi-pronged CSRF defense. But that use of the Origin header falls outside the CORS specification.

In sum, CORS is a useful specification for extending the existing Same Origin Policy security model to other accepted domains. It doesn't add security, and sites need the same kinds of defense mechanisms that they did before CORS.

---

I am late to answer but I don't think any post here really provides the sought answer. The biggest takeaway should be that the browser is the agent that is writing the origin header value. An evil script cannot write the origin header value. When the server responds back with a Access-Control-Allow-Origin header, the browser tries to ensure that this header contains the origin value sent earlier. If not, it triggers an error and does not return the value back to the requesting script. The other answers to this question present a good scenario to when you would like to deny an answer back to the evil script.

@daniel f also provides a good answer to the question

참고URL : https://stackoverflow.com/questions/4850702/is-cors-a-secure-way-to-do-cross-domain-ajax-requests