브라우저가 동일한 출처 정책을 구현하는 방식에 상당한 차이가 있습니까?

Question

내 홈페이지에 XHR POST를 통해 URL https://mydomain.com/send_sms에 제출할 양식이 있습니다.

인터넷 익스플로러 (http://mydomain.com) &의 홈페이지의 비 SSL 버전을 방문하면 아무 일도 일어나지 않습니다. Webkit 콘솔에서 도움이되는 오류 메시지가 나타납니다. Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

그러나 Firefox 13에서는 응답 본문이 & a로 명확하게 제출됩니다. 응답 본문은 200 OK이지만 응답 본문은 비어 있습니다. 또한 서버 측 작업 (SMS 전송)은 Firefox 요청에 의해 실제로 트리거되지만 다른 브라우저에서는 트리거되지 않습니다.

나는 항상 같은 출처 정책이 요청 전송도 거부했다고 생각하지만, 허용되지 않는 응답에서 데이터를 수신하는 브라우저가있을 것입니다.

이것이 모질라의 구현 (또는 심지어 감시까지)의 목적과 다른 점은 누구나 알고 있습니까?

Answer 1

우선, http://example.com 및 https://example.com은 다른 출처입니다. XHR Level 1의 경우 교차 출처 요청이 허용되지 않습니다.

그러나 CORS가 지원 될 때 출처 간 요청을 지원하는 현재 XHR (Level 2)에 대한

(서버 및 클라이언트 모두에 의해!), 크로스 원산지 요청하거나,

• simple cross-orgin request 수 있습니다

  경우
  • 요청 방법 GET, HEAD 또는 POST 및 요청 heade의
  • 상관 할 R 필드는 달리 Accept 이외 하나 Accept-Language, Content-Language 또는 Content-Type 및
  • 프리 플라이트 플래그

  또는

• cross-origin request that requires a preflight

  설정하지된다.

간단한 출처 요청의 경우 브라우저가 요청을 보낼 수 있습니다. 그러나 응답을 받으면 check whether the server allows to share the resource이 필요합니다. 여기에서 Access-Control-Allow-Origin 헤더 필드 및 기타 Access-Control-* 응답 헤더 필드를 확인합니다. 이 검사가 통과 된 경우에만 브라우저가 스크립트로 응답을 읽을 수 있습니다.

다른 교차 출처 요청의 경우 실제 요청에서 어떤 정보를 보낼 수 있는지 서버와 협상하기 위해 프리 플라이트가 필요합니다. 이 프리 플라이트 요청은 기본적으로 서버에 실제 요청에 포함될 내용 (요청 메소드 및 헤더 필드)을 알려주는 OPTIONS 요청입니다. 그런 다음 서버는 이러한 요청을 허용하는지 여부를 결정할 수 있습니다.

귀하의 경우, 관찰 된 동작에는 여러 가지 이유가있을 수 있습니다. send_sms 스크립트는 단지 support the server side part for CORS이 아닙니다.

Answer 2

데이터를 보내는 것과 마찬가지로 데이터 보내기도 금지해야합니다. 이 페이지에 악의적 인 JS가 있고 각 키 스트로크를 임의의 서버에 제출하면 어떨까요? 이 경우, 송신은 수신보다 더 사악합니다 (같은 출발지 정책의 적용을받지 않기 때문에 이미지 문자열이나 스크립트와 같은 자원을 쿼리 문자열로 요청하여 실제로 수신 할 수 있습니다).

나는 과거에 약간의 차이가 있었지만 일반적으로 기존 IE에서 발생했습니다.

저에게 파이어 폭스의 불일치는 버그입니다 (바닐라 설치에는이 특성이 있습니다). 다른 프로토콜 (HTTP 대 HTTPS)은 다른 출발점과 동일합니다. 동일한 프로토콜의 하위 도메인도 다른 출발점으로 간주되므로 FF13은 AJAX 요청을 확실히 작성하지 않아야합니다.

CORS (Cross-Origin Resource Sharing)를 설정하지 않았습니까? FF13을 지원하도록 테스트 한 유일한 브라우저는 FF13입니까?