웹 개발은 종종 교차 도메인 문제에 직면해야합니다. 도메인 간 문제의 근본 원인은 브라우저 보안에서 동일한 원천 전략입니다. 예를 들어 http://www.a.com/1.html :
1. http://www.a.com/2.html은 상동입니다.
2. https://www.a.com/2.html은 프로토콜이 다르기 때문에 다른 소스에서 나온 것입니다.
3. http://www.a.com:8080/2.html은 포트가 다르기 때문에 다른 소스에서 나온 것입니다.
4. http://sub.a.com/2.html은 호스트가 다르기 때문에 다른 소스 출신입니다.
브라우저에서 태그 <cript>, <img>, <iframe> 및 <link>는 크로스 도메인 (비 호모 학적) 리소스를로드 할 수 있으며 로딩 방법은 실제로 일반적인 GET 요청과 동일합니다. 유일한 차이점은 보안을 위해 브라우저는 이러한 방식으로로드 된 리소스에 대한 읽기 및 쓰기 작업을 허용하지 않지만 태그 자체에 있어야하는 기능 (예 : 스크립트 실행, 스타일 응용 프로그램 등) 만 사용할 수 있다는 것입니다.
가장 일반적인 크로스 도메인 문제는 Ajax의 크로스 도메인 접근 문제입니다. 기본적으로 Ajax를 통해 크로스 도메인 URL에 액세스 할 수 없습니다. 여기서 나는 크로스 도메인 방법에 대해 배운 것을 기록합니다.
1. 서버 측 프록시 , 할 말이 없습니다. 단점은 기본적으로 AJAX 요청을 수신하는 서버가 클라이언트의 IP 및 UA를 얻을 수 없다는 것입니다.
2. iframe , iframe을 사용하는 것은 실제로 새 웹 페이지를 여는 것과 동일합니다. 특정 크로스 도메인 방법은 대략 도메인 A에 의해 열린 상위 페이지입니다. ests a iframe을 도메인 B를 가리키고 데이터를 제출합니다. 완료 후 B의 서버는 다음을 수행 할 수 있습니다.
● 302 리디렉션 응답을 반환하고 결과를 도메인 A로 다시 가리 킵니다.
●이 iframe 내부의 도메인을 가리키는 iframe을 중첩하십시오.
이 두 가지 모두 마침내 크로스 도메인 호출을 구현합니다. 이 방법은 아래 도메인 완료 후에 DOM 운영 및 JavaScript 호출에 문제가 없지만 URL 매개 변수로 전달되는 결과와 같은 몇 가지 제한 사항이 있기 때문에 아래에 도입 된 JSONP보다 기능적으로 더 강합니다. 결과 데이터가 크면 세그먼트에 통과해야한다는 것을 의미합니다. iframe 자체로 인해 발생하는 또 다른 문제가 있으며, 상위 페이지와 iframe 자체의 상호 작용에는 보안 제한이 있습니다.
3. 스크립트 태그를 사용하여 크로스 도메인 ,이 방법은 매우 일반적입니다. 스크립트 태그는 외국 자바 스크립트를로드하여 실행할 수 있습니다. 사전 설정된 콜백 함수는 상위 페이지와의 상호 작용을 실현할 수 있습니다. 그것은 JSONP Cross-Domain이라는 큰 이름을 가지고 있으며, 이는 패딩이있는 JSON의 약자입니다. 비공식 프로토콜로 스크립트를로드하는데 왜 JSON과 관련이 있습니까? 이 콜백 함수라는 것이 밝혀졌습니다. JSON을 통해 매개 변수를 전달하는 일반적인 사용 방법이 있습니다. 즉 JSON 데이터를 콜백 함수로 채우는 것입니다. 이것이 JSONP의 JSON+패딩의 의미입니다.
인터넷에는 데이터를 제공하기 위해 많은 JSONP 서비스가 있습니다. 본질적으로, 그들은 크로스 도메인 요청이며 콜백 = 결과와 같은 요청 URL에서 콜백을 지정합니다. 이 데이터를 얻은 후 결과 함수는 자동으로 호출되고 데이터는 JSON 형태 (예 : "Football") 형태로 전달됩니다.
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=result
jQuery를 사용하여 호출하고 다음과 같이 씁니다.
코드 사본은 다음과 같습니다.
$ .getJson ( "http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=?", 기능 (데이터) {
// ...
});
일반적으로 JSONP의 크로스 도메인 접근 방식의 한계는 GET 요청 만 사용할 수 있으며 다른 도메인의 두 페이지간에 JavaScript 호출을하는 방법의 문제를 해결할 수 없다는 것입니다.
4. 플래시 크로스 도메인 :
대상 웹 사이트의 루트 디렉토리 아래 CrossDomain.xml 파일에 액세스하고 파일의 내용을 기반 으로이 크로스 도메인 액세스를 허용할지 여부를 결정합니다.
코드 사본은 다음과 같습니다.
<크로스 도메인-폴리치>
<허용-액세스 -From 도메인 = "xxx.xxx.com" />
</Cross-Domain-Policy>
5. IMG 태그도 사용할 수 있으며 이는 매우 일반적인 방법입니다. 기능이 약하고 콜백 없이만 GET 요청 만 보낼 수 있습니다. 이것이 Google의 클릭 수가 결정되는 방식입니다.
6. Window.postMessage는 크로스 도메인 커뮤니케이션을위한 새로 추가 된 메커니즘 인 Firefox 3, Safari 4, IE8 및 이후 버전에서만 지원됩니다. 다른 창에 메시지를 보내기 위해 사용하는 호출은 다음과 같습니다.
코드 사본은 다음과 같습니다.
Otherwindow.postmessage (메시지, Targetorigin);
수신 창에서 보낸 메시지를 수신하도록 이벤트 핸들러를 설정해야합니다.
코드 사본은 다음과 같습니다.
window.addeventListener ( "메시지", 채권, 거짓);
함수 채권 (이벤트) {
if (event.orgin! == "http://example.org:8080")
반품;
}
메시지의 원점 및 소스 속성은 발신자의 신원을 확인하는 데 사용해야합니다. 그렇지 않으면 XSS 취약점이 발생합니다.
7. 액세스 제어
일부 브라우저는 Access-Control-Origin과 같은 응답 헤더를 지원합니다.
코드 사본은 다음과 같습니다.
헤더 ( "Access-Control-allow-origin : http://www.a.com");
이것은 www.a.com에 대한 크로스 도메인 액세스가 허용되어 있음을 명시합니다.
8. Window.Name
이것은 실제로 XSS를 해킹하는 수단으로 사용되었습니다. 본질은 창 위치가 변경되면 페이지가 다시로드되지만 흥미롭게도 창이 변경되지 않으므로 값을 전달할 수 있습니다. iframe을 사용하면 iframe의 창 객체를 여러 번 변경하면 실제 크로스 도메인 데이터 전송이 완료됩니다.
9. 문서
이 방법은 a.example.com 및 b.example.com과 같은 크로스 도메인 커뮤니케이션에 적합합니다. 두 가지는 example.com이라는 공통 도메인을 가지고 있기 때문입니다. Document.domain을 example.com으로 설정하지만 A.Example1.com과 B.example2.com을 통신하려면 선택의 여지가 없습니다.
10. Fragment Identitier 메시징 (FIM)
이 방법은 매우 흥미롭고 Iframes의 협력이 필요합니다. Fragment Identitier는 URL의 파운드 마크 (#) 이후에 앵커 포지셔닝에 종종 사용되는 부분입니다. 이 부분의 변경으로 인해 페이지 새로 고침이 발생하지 않습니다. 여성 창은 마음대로 iframe의 URL에 액세스 할 수 있으며 Iframe은 여성 창의 URL에도 액세스 할 수 있습니다. 그런 다음 Fragmement Identitier를 변경하여 의사 소통을 달성 할 수 있습니다. 단점은 Fragmement Identitier의 변화가 불필요한 이력을 생성하고 길이 제한이 있다는 것입니다. 또한 일부 브라우저는 OnhashChange 이벤트를 지원하지 않습니다.
11. 크로스 프레임 (CF)
이 방법은 위의 FIM 방법의 변형입니다. CF와 FIM의 본질은 실제로 내 기사 "GWT 첫 경험"에 소개됩니다 (역사와 후진 기능을 구현하는 데 사용됩니다). 그것은 외국 영역을 가리키는 보이지 않는 iframe을 동적으로 생성합니다. 처리 후,이 iframe의 URL의 조각 아이스티티어에는 부모 페이지에 액세스 할 수있는 처리 결과가 포함되지만 브라우저의 URL에는 변경 사항이 없습니다.
12. 쿠키+P3P 프로토콜
P3P 프로토콜에서 크로스 도메인 액세스 쿠키의 특성을 사용하여 크로스 도메인 액세스를 달성하는 것도 이상한 속임수입니다. P3P는 W3C에서 발표 한 개인 정보 보호 추천 표준으로 인터넷 서핑을하는 인터넷 사용자에게 개인 정보 보호를 제공하는 것을 목표로합니다. 쿠키의 경로를 "/"로 설정하십시오. 즉, 도메인 제한이 없습니다. 현재 일부 브라우저는 다른 URL 페이지를 읽을 수있는 반면 다른 브라우저는 그렇지 않습니다. 이 경우 P3P 헤더는 부모 페이지 응답의 헤드에 설정해야합니다.
코드 사본은 다음과 같습니다.
P3P : CP = "CURA ADMA DEVA PSAO PSDO 우리 버스 UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"