도메인 간 양식 게시

145

이 주제에 대한 기사와 게시물을 모두 보았습니다 (SO 포함). 주석 의견은 동일한 출처 정책으로 인해 도메인 전체에서 POST 형식을 막을 수 있다는 것입니다. 내가 본 사람이 같은 출처 정책이 게시물 게시에 적용되지 않는다고 제안하는 유일한 장소 는 여기 입니다.

좀 더 "공식적인"또는 공식적인 출처로부터 답변을 받고 싶습니다. 예를 들어, 동일한 출처가 양식 POST에 미치는 영향을 다루는 RFC를 아는 사람이 있습니까?

설명 : GET 또는 POST를 구성하여 어떤 도메인으로 보낼 수 있는지 묻지 않습니다. 나는 물어보고있어:

Chrome, IE 또는 Firefox에서 도메인 'Y'의 콘텐츠가 도메인 'X'에 POST를 보내도록 허용하는 경우
POST를 수신하는 서버가 실제로 모든 양식 값을 볼 수 있습니다. 나는 대부분의 온라인 토론 기록 테스터가 서버가 게시물을 받았다고 말했지만 양식 값이 모두 비어 있거나 제거 되었기 때문에 이것을 말합니다.
어떤 공식 문서 (예 : RFC)에는 브라우저가 현재 구현 한 내용에 관계없이 예상되는 동작이 무엇인지 설명되어 있습니다.

또한 동일한 출처가 POST 형식에 영향을 미치지 않으면 위조 방지 토큰이 필요한 이유가 다소 분명해집니다. 공격자가 단순히 위조 방지 토큰이 포함 된 양식을 검색하기 위해 HTTP GET을 발행 한 다음 동일한 토큰이 포함 된 불법 POST를 만들 수 있다고 생각하기 때문에 "약간"이라고 말합니다. 코멘트?

— 브렌트 아리아스
소스

예, 침입자는 일반적인 웹 브라우저로 그렇게 할 수 있습니다.

— Michael Hampton

아마도 "웹 사이트에 비밀번호를 게시하지 마십시오"라는 RFC가없는 것과 같은 이유로 RFC가 없을 것입니다. 웹 표준은 여러 당사자가 협력하여 무언가를 달성해야하는 경우에만 필요합니다. 동일한 출처 정책은 사용자가 해킹당하는 것을 막는 복잡한 "보안 모범 사례"에 가깝습니다.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@Ciro 명시 적으로 말하십시오. 다른 사이트에 대한 교차 게시 규칙은 여러 당사자에게 영향을 미치지 않습니다. 안개가 필요하지 않습니다.

— Little Alien

답변:

175

동일한 오리진 정책이 브라우저 측 프로그래밍 언어에만 적용됩니다. 따라서 JavaScript를 사용하여 원본 서버가 아닌 다른 서버에 게시하려고하면 동일한 원본 정책이 작동하지만 양식에서 직접 게시하면 작업이 다음과 같은 다른 서버를 가리 킵니다.

<form action="http://someotherserver.com">

양식 게시와 관련된 자바 스크립트가없는 경우 동일한 출처 정책을 적용 할 수 없습니다.

자세한 내용은 Wikipedia 를 참조하십시오.

— 수레 쉬 쿠마르
소스

오래된 질문을 드래그하여 죄송합니다. JS를 사용하여 작업을 변경했지만 버튼을 사용하여 양식을 게시하면 어떻게됩니까? 교차 도메인 게시물이 성공할 수 있습니까?

— Chris

AFAIK 그것은 문제가되지 않아야하지만 직접 시도하지는 않았습니다. 알아두면 흥미로울 것입니다.

— Suresh Kumar

나도 같은 생각이야 실제로 보안에 대한 우려가 있었으며 일부 타사 JS / 바이러스는 악의적 인 어딘가에 양식을 게시하도록 작업을 변경했지만 교차 도메인을 통해 지불하는 모든 지불에 대해 수행 할 수 있으며 결과는 동일하다는 것을 깨달았습니다. 여기에 레슨 : 제 3 자 JS 파일 확인;)

— Chris

한마디로 : 예, 도메인 간 POST가 허용됩니다.

— Christian Davén

-1 for : 동일한 출처 정책은 다른 URL (다른 프로토콜 또는 도메인 또는 포트)로 요청을 보내는 것과 아무 관련이 없으며, 다른 URL의 응답 데이터에 대한 액세스를 제한 (읽기)하여 Javascript가 문서를 업데이트하지 못하도록하는 것입니다. 다른 URL의 보안 토큰이있는 양식).

— Mohsenme

임의의 GET 또는 POST 요청 을 작성하여 대상 브라우저가 액세스 할 수 있는 서버로 전송할 수 있습니다. 여기에는 프린터 및 라우터와 같은 로컬 네트워크의 장치가 포함됩니다.

CSRF 익스플로잇을 구축하는 방법에는 여러 가지가 있습니다. 방법을 사용하여 간단한 POST 기반 CSRF 공격 을 보낼 수 있습니다 .submit(). 사이트 간 파일 업로드 CSRF 공격 과 같은보다 복잡한 공격 은 CORS의 xhr.withCredentals 동작 사용을 악용 합니다.

SOP는 클라이언트 요청에 대한 서버의 응답을 읽는 JavaScript와 관련되므로 CSRF는 JavaScrip에 대한 동일 원본 정책을 위반하지 않습니다 . CSRF 공격은 응답에 신경 쓰지 않으며, 부작용 이나 관리 요청자 추가 또는 서버에서 임의의 코드 실행과 같은 요청에 의해 생성 된 상태 변경에 신경을 씁니다 .

OWASP CSRF 예방 치트 시트에 설명 된 방법 중 하나를 사용하여 요청을 보호해야합니다 . CSRF에 대한 자세한 내용은 CSRF의 OWASP 페이지를 참조하십시오 .

— 마이키
소스

명확히하기 위해 질문을 업데이트했습니다. 또한 귀하가 제공 한 WordPress 링크는 교차 도메인 Y에서 시작된 것이 아니라 동일한 출처 X에서 시작된 익스플로잇과 관련이 있습니다.

— 브렌트 아리아스

@Brent Arias 예, 1과 2에서 설명하는 것은 CSRF 공격과 정확히 동일합니다. 제공된 CSRF 익스플로잇 중 하나를 실행하고 트래픽을 스니핑해야 할 수도 있습니다. 내 게시물을 업데이트했습니다. 제공된 질문에 정확하게 답변 할 수 있도록 제공된 모든 링크를 읽어야합니다. "CSRF (Cross-Site Request Forgery)"공격의 요점은 다른 도메인에서 온 요청이며, 제공된 모든 악용은이 기본 요구 사항을 완전히 충족합니다.

— Mikey

동일한 출처 정책은 다른 URL (다른 프로토콜 또는 도메인 또는 포트)로 요청을 보내는 것과는 아무런 관련이 없습니다.

다른 URL의 응답 데이터에 대한 액세스를 제한하는 것입니다. 따라서 페이지 내의 JavaScript 코드는 임의의 도메인에 게시하거나 해당 페이지 내의 양식을 다른 위치에 제출할 수 있습니다 (양식이 URL이 다른 iframe에있는 경우 제외).

그러나 POST 요청을 비효율적으로 만드는 것은 이러한 요청에 위조 방지 토큰이 없기 때문에 다른 URL에서는 무시한다는 것입니다. 또한 JavaScript가 해당 URL을 AJAX 요청을 희생자 URL로 보내 보안 토큰을 얻으려고하면 동일한 출처 정책으로 해당 데이터에 액세스 할 수 없습니다.

좋은 예 : 여기

그리고 Mozilla의 훌륭한 문서 : here

— 모 센메
소스