>  기사  >  웹 프론트엔드  >  Js Same Origin Policy_javascript 스킬에 대한 자세한 설명

Js Same Origin Policy_javascript 스킬에 대한 자세한 설명

WBOY
WBOY원래의
2016-05-16 15:58:061278검색

이 글에서는 js의 동일 출처 전략을 좀 더 자세히 분석합니다. 참고할 수 있도록 모든 사람과 공유하세요. 세부 내용은 다음과 같습니다.

개념: 동일 원본 정책은 클라이언트측 스크립트(특히 Javascript)에 대한 중요한 보안 지표입니다. Netscape Navigator2.0에서 처음 나왔으며 그 목적은 문서나 스크립트가 여러 다른 소스에서 로드되는 것을 방지하는 것입니다.

여기서 동일한 출처는 동일한 프로토콜, 동일한 도메인 이름 및 동일한 포트를 의미합니다.

에센스:

핵심은 간단합니다. 모든 사이트에서 로드된 신뢰할 수 있는 콘텐츠는 안전하지 않은 것으로 간주합니다. 브라우저가 신뢰하지 않는 스크립트가 샌드박스에서 실행되는 경우 동일한 사이트의 리소스에만 액세스할 수 있어야 하며 악의적일 수 있는 다른 사이트의 리소스에는 액세스할 수 없습니다.

동일출처 제한은 왜 있나요?

예를 들어 보겠습니다. 예를 들어, 해커 프로그램은 IFrame을 사용하여 실제 은행 로그인 페이지를 자신의 페이지에 삽입합니다. 실제 사용자 이름과 비밀번호로 로그인하면 해당 페이지의 내용을 Javascript를 통해 읽을 수 있습니다. 사용자 이름과 비밀번호를 쉽게 얻을 수 있도록 양식에 입력하십시오.

Ajax 애플리케이션:

Ajax 애플리케이션에서는 이 보안 제한이 깨졌습니다.

일반 Javascript 애플리케이션에서는 Frame의 href 또는 IFrame의 src를 수정하여 GET 모드에서 도메인 간 제출을 달성할 수 있지만 도메인 간 Frame/IFrame의 콘텐츠에 액세스할 수는 없습니다.

Ajax는 비동기 상호작용을 위해 XMLHTTP를 사용합니다. 이 객체는 원격 서버와도 상호작용할 수 있습니다. 더욱 위험한 점은 XMLHTTP가 순수 Javascript 객체라는 점입니다. 따라서 XMLHTTP는 실제로 Javascript의 원래 보안 한계를 극복했습니다.

새로 고침이 필요 없는 XMLHTTP의 비동기 상호 작용 기능을 활용하고 싶지만 Javascript의 보안 정책을 노골적으로 깨뜨리고 싶지 않다면 대안은 XMLHTTP에 엄격한 동일 출처 제한을 추가하는 것입니다. 이러한 보안 정책은 Applet의 보안 정책과 매우 유사합니다. IFrame의 한계는 교차 도메인 HTMLDOM의 데이터에 액세스할 수 없다는 점이며, XMLHTTP는 근본적으로 교차 도메인 요청 제출을 제한합니다.

브라우저 지원: IE는 실제로 이 보안 정책에 대해 두 개의 백도어를 엽니다. 하나는 로컬 파일이 어떤 콘텐츠에 액세스할지 자연스럽게 알 것이라고 가정하므로 로컬 파일이 외부 데이터에 액세스하지 않습니다. 경고. 또 다른 이유는 귀하가 방문하는 웹사이트의 스크립트가 도메인 간 정보에 액세스하려고 할 때 실제로는 이를 상기시키기 위한 대화 상자를 표시한다는 것입니다. 사기성 웹사이트가 이 방법을 사용하여 가짜 페이지를 제공한 후 XMLHTTP를 통해 원격으로 실제 은행 서버에 로그인할 수 있도록 도와주는 경우입니다. 10명의 사용자 중 단 한 명만 혼란스러워서 확인을 클릭했습니다. 그들의 계정 도용이 성공했습니다! 생각해 보십시오. 이것이 얼마나 위험한 일입니까!

FireFox는 이를 수행하지 않습니다. 기본적으로 FireFox는 도메인 간 XMLHTTP 요청을 전혀 지원하지 않으며 해커에게 그러한 기회를 제공하지 않습니다.

동일 출처 전략 피하기:

JSON 및 동적 스크립트 태그