웹 서버는 동일한 출처 정책을 어떻게 시행합니까?

RESTful API 개발에 대해 자세히 알아보고 있으며 지금까지 몇 가지 다른 프레임 워크를 사용하여이를 달성했습니다. 물론 동일한 출처 정책에 부딪 쳤으며 이제는 웹 브라우저가 아닌 웹 서버가 어떻게 정책을 시행하는지 궁금합니다. 내가 이해 한 바에 따르면 브라우저 끝에서 일부 시행이 발생하는 것 같습니다 (예 : 서버에서받은 Access-Control-Allow-Origin 헤더를 존중). 그러나 서버는 어떻습니까?

예를 들어, 웹 서버가 해당 서버에서 호스팅되는 API에 액세스하는 Javascript 웹 앱을 호스팅한다고 가정 해 보겠습니다. 서버가 동일한 출처 정책을 시행한다고 가정하여 해당 서버에서 호스팅되는 자바 스크립트 만 API에 액세스 할 수 있도록합니다. 이렇게하면 다른 사람이 해당 API에 대한 자바 스크립트 클라이언트를 작성하여 다른 사이트에서 호스팅하지 못하게됩니다. 그렇다면 웹 서버는 동일한 웹 서버에서 생성 된 자바 스크립트를 실행한다고 주장하면서 API 엔드 포인트에 AJAX 요청을 시도하는 악의적 인 클라이언트를 어떻게 막을 수 있을까요? 가장 인기있는 서버 (Apache, nginx)가 이러한 종류의 공격으로부터 보호하는 방법은 무엇입니까? 아니면이 점에 대한 나의 이해가 어떻게 든 표식에서 벗어 납니까?

아니면 교차 출처 정책이 클라이언트 쪽에서 만 시행됩니까?

동일한 오리진 정책은 전적으로 클라이언트 기반 제한이며 주로 서비스가 아닌 사용자 를 보호 하도록 설계되었습니다 . 모든 브라우저 또는 대부분의 브라우저에는 명령 줄 스위치 나 구성 옵션이 포함되어 있습니다. SOP는 자동차의 안전 벨트와 같습니다. 자동차의 라이더를 보호하지만 누구나 자유롭게 사용하지 않을 수 있습니다. 확실히 사람의 안전 벨트가 차에서 나와 사용자를 공격하거나 웹 서비스에 액세스하는 것을 막을 것으로 기대하지 마십시오.

웹 서비스에 액세스하는 프로그램을 작성한다고 가정하십시오. HTTP 요청을 포함하는 TCP 메시지를 보내는 프로그램 일뿐입니다. 내 프로그램 (아무것도 보낼 수 있음)의 요청과 허용 된 출처에서 페이지가로드 된 브라우저의 요청을 구별하는 서버 측 메커니즘을 요구하고 있습니다. 단순히 할 수 없습니다. 내 프로그램은 항상 웹 페이지에서 만든 것과 동일한 요청을 보낼 수 있습니다.

동일한 출처 정책은 한 웹 사이트의 코드가 다른 사이트의 자격 증명이 제한된 콘텐츠 에 액세스하지 못하도록하기 때문에 고안되었습니다 . Ajax 요청은 기본적으로 대상 사이트에서 부여한 인증 쿠키와 함께 전송됩니다. 예를 들어 실수로 load를 http://evil.com/요청하면에 대한 요청을 보냅니다 http://mail.google.com/. SOP가 설치되어 있지 않고 Gmail에 로그인 한 경우 스크립트에서 evil.com받은 편지함을 볼 수있었습니다. 사이트를 쿠키없이 evil.com로드 mail.google.com하려면 프록시 서버 만 사용하면됩니다. 의 공개 내용은 mail.google.com비밀이 아닙니다 (그러나 mail.google.com쿠키 로 액세스 할 때 의 내용은 비밀입니다).

동일한 출처 정책이 클라이언트 측에서 시행됩니다. 브라우저가 CORS를 지원하는 경우, 서버는 브라우저에게 동일 출처 정책에 대한 예외를 설정하도록 지시하는 헤더를 다시 보낼 수 있습니다. 예를 들어 헤더 보내기

 Access-Control-Allow-Origin: www.example.com

www.example.com의 교차 출처 요청을 허용하도록 브라우저에 지시합니다.

 Access-Control-Allow-Origin: *

브라우저가 모든 출처 간 요청을 해당 자원에 허용하도록 브라우저에 지시합니다.

웹 서버는 일반적으로 RefererHTTP 헤더에서 (잘못 표기된) 철자를 검사하여 요청이 자체 사이트의 페이지에서 오는지 확인함으로써 이러한 종류의 공격을 방지 합니다. 악의적 인 클라이언트로부터 보호 할 수있는 좋은 방법은 없지만 XSRF 공격이 작동하는 방식은 아닙니다.

클라이언트는 악성이 아닙니다. 일반적으로 악의적 인 제삼자가 클라이언트의 저장된 쿠키를 사용하여 HTTP 요청을 자동으로 작성하는 문서를 열도록 속인 일반 사용자입니다. 따라서 서버가 RefererHTTP 요청이 MyAwesomeWebsite.com이 아닌 gmail.com에서 온 것인지 확인할 수 있으면 공격을 종료 할 수 있습니다.

웹 서버는 동일한 출처 정책을 어떻게 시행합니까?

요컨대, apsillers 와 Dirk가 지적했듯이 그들은 그렇지 않습니다 .
중요한 이유 중 하나 는 ACAO 헤더가 서버 자체를 분산 된 DDoS (Distributed Denial of Service) 공격으로부터 보호하기 때문입니다 .

누구:

HTTP 응답 헤더로서의 ACAO는 대부분의 휴먼 인터넷 사용자가 W3C 권장 초안 을 준수하고 구현하는 주요 브라우저 공급 업체를 통해 웹을 탐색한다는 가정하에 웹 클라이언트를 해석하기위한 것 입니다. 그들은 결국 대부분의 사람들이 빠르고 접근 가능한 인터넷으로부터 이익을 얻어야합니다.

방법:

그렇지 않으면 누구나 간단한 루프를 실행하는 악성 웹 사이트에 자바 스크립트 코드 몇 줄을 복사하여 붙여 넣어 Ajax GET 또는 POST의 요청을 외부 도메인으로 만들 수 있습니다. 사용자 상호 작용이없고 멀티 스레딩 기능이 없습니다.

당신이 이유입니다 ACAO HTTP 헤더를 통해, 크로스 원본 사이트 액세스에 수신 거부에 있습니다 . 사용자는 사용자 인식 상호 작용, 즉 인터넷 링크를 통해 언제든지 해당 사이트에 액세스 할 수 있습니다. 사용자가 인식 할 수있는 것처럼 클립 보드에서 또는 클립 보드로 콘텐츠를 복사하거나 붙여 넣을 수 있지만 다른 방법으로는 플러그인을 제외하고는 불가능합니다.

미래:

이 시점에서 웹 브라우저 메이커의 지시에 유의하십시오.

• 완전한 샌드 박스 환경을 향한 단계로서 기본 플러그인 제거
• 자바 스크립트를 끄는 사용자 옵션 제거

TSL 2/3, 강력한 세션 ID, TAN, 2 단계 인증 등을 사용하여 보안 제한을 적절하게 설정할 수 있습니다.

'Google'은 DDOS 에 대해 보여주고 말할 수 있습니다.

마지막으로 누구나 웹 컨텐츠를 프록시하고 원하는 ACAO 헤더 를 추가하여 프록시 된 교차 사이트 컨텐츠에 액세스 할 수 있습니다. 마찬가지로이 프록시는 ACAO 설정에서 허용하는 것처럼 DDOS 공격에 개방적입니다. 실제로 하나의 무료 공공 서비스 오퍼링을 모릅니다. 내가 틀렸다면 정정 해주세요.

다른 사람들이 말했듯이, 그것은 클라이언트에게 달려 있습니다. 그러나 서버는 SOP를 우회하는 XSS를 처리해야 할 수도 있습니다.

서버를 중단하면 사용자가 컨텐츠를 업로드 할 수 있으며 다른 사용자가 사이트를 탐색 할 때 표시됩니다. 이 페이지는 좋은 예입니다. 방금 콘텐츠를 업로드했는데 표시됩니다.
내 콘텐츠에 <script>태그 가 포함되어 있고 서버 가 태그를 생성 한 HTML로 복사하면 업로드 한 스크립트가 실행됩니다.
스크립트는 파일에서 HTML로 발견되었으므로 사이트 스크립트의 모든 권한이 있습니다. 예를 들어이 답변을 찬성 할 수 있습니다. 이것이 바로이 답변에 많은 투표가있는 이유입니다.

좋은 웹 서버 (예를 들어, StackExchange가 사용하는 것과 같은)는 이것을 허용하지 않습니다. <script>태그 를 제거 하거나 이스케이프 처리 할 수 ​​있으므로 표시되지만 실행되지는 않습니다 (경고-이 답변은 XSS를 방지하기위한 신뢰할 수있는 레시피와는 거리가 멀습니다).

따라서 SOP를 적용하는 것은 클라이언트 측이지만 일부 경우 서버가이를 우회하지 않도록 작동해야합니다.