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

이 글에서는 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 및 동적 스크립트 태그

src="http://yoursiteweb.com/findItinerary?username=sachiko&
bookingNum=1234&output=json&callback=showItinerary" />

JavaScript 코드가 <script> 태그를 동적으로 삽입하면 브라우저는 src 속성의 URL에 액세스합니다. 이렇게 하면 쿼리 문자열의 정보가 서버로 전송됩니다. 목록 1에서는 사용자 이름과 예약이 이름-값 쌍으로 전달됩니다. 또한 쿼리 문자열에는 서버에서 요청한 출력 형식과 콜백 함수 이름(즉, showItinerary)이 포함됩니다. <script> 태그가 로드된 후 콜백 함수가 실행되고 서비스에서 반환된 정보가 해당 매개변수를 통해 콜백 함수에 전달됩니다. </script>

Ajax 프록시

Ajax 프록시는 웹 브라우저와 서버 간의 HTTP 요청과 응답을 중재하는 애플리케이션 수준 프록시 서버입니다. Ajax 프록시를 사용하면 웹 브라우저가 동일 출처 정책을 우회하여 XMLHttpRequest를 사용하여 타사 서버에 액세스할 수 있습니다. 이 우회를 달성하려면 다음 두 가지 방법 중에서 선택할 수 있습니다.
클라이언트 웹 애플리케이션은 타사 URL을 알고 있으며 해당 URL을 HTTP 요청의 요청 매개변수로 Ajax 프록시에 전달합니다. 그런 다음 프록시는 요청을 [url]www.jb51.net[/url]로 전달합니다. 웹 애플리케이션 개발자가 사용하는 Ajax 라이브러리 구현에서는 프록시 서버 사용이 숨겨질 수 있습니다. 웹 애플리케이션 개발자에게는 동일 출처 정책이 전혀 없는 것처럼 보일 수 있습니다.
클라이언트 웹 애플리케이션은 타사 URL을 인식하지 못하고 HTTP를 통해 Ajax 프록시 서버의 리소스에 액세스하려고 시도합니다. Ajax 프록시는 미리 정의된 인코딩 규칙을 사용하여 요청된 URL을 타사 서버의 URL로 변환하고 클라이언트를 대신하여 콘텐츠를 검색합니다. 이는 웹 애플리케이션 개발자에게 프록시 서버와 직접 통신하고 있는 것처럼 보이게 합니다.

그리스몽키

Greasemonkey는 사용자가 웹페이지의 스타일과 콘텐츠를 동적으로 수정할 수 있는 Firefox 확장 프로그램입니다. Greasemonkey 사용자는 사용자 스크립트 파일을 URL 모음과 연결할 수 있습니다. 이러한 스크립트는 브라우저가 이 URL 집합에서 페이지를 로드할 때 실행됩니다. Greasemonkey는 사용자 스크립트용 API에 추가 권한을 제공합니다(브라우저 샌드박스에서 실행되는 스크립트에 대한 권한과 비교).

GM_XMLHttpRequest는 이러한 API 중 하나이며 본질적으로 동일한 원본 정책이 없는 XMLHttpRequest입니다. 사용자 스크립트는 브라우저에 내장된 XMLHttpRequest를 GM_XMLHttpRequest로 재정의하여 XMLHttpRequest가 도메인 간 액세스를 수행할 수 있도록 할 수 있습니다.

GM_XMLHttpRequest의 사용은 사용자 동의를 통해서만 보호될 수 있습니다. 즉, Greasemonkey는 새로운 사용자 스크립트와 특정 URL 모음 간의 연결을 설정할 때만 사용자 구성이 필요합니다. 그러나 일부 사용자가 결과를 완전히 이해하지 못한 채 설치를 수락하도록 속일 수 있다는 것을 상상하는 것은 어렵지 않습니다.

이 기사가 모든 사람의 JavaScript 프로그래밍 설계에 도움이 되기를 바랍니다.