it-swarm-korea.com

XSS를 무력화하기위한 DOM 요소 화이트리스트

아시다시피 개발자는 데이터를 렌더링하거나 저장하기 전에 사용자가 제공 한 데이터를 올바르게 이스케이프/검증 할 책임이 있습니다. 그러나 우리는 수백 가지 중 하나의 입력을 잊어 버리고 마침내 XSS에 의해 웹 앱을 악용하는 것이 상대적으로 쉽다는 데 동의해야합니다. 아니면 XSS가 자신의 사이트를 악용 한 사람을 만난 적이 없습니까?

Twitter와 Orkut조차도 최근 XSS로 어려움을 겪었습니다. 그리고 나는 누구를 비난하기 위해 여기있는 것이 아닙니다.

브라우저가 화이트리스트 DOM 요소를 지원한다고 가정합니다. 이러한 화이트리스트 요소는 JavaScript를 실행할 수있는 유일한 요소입니다. 그런 일반적인 화이트리스트가 있으면 선호하는 웹 사이트가 제대로 작동하도록 유지하는 것이 불가능하기 때문에 미친 소리라는 것을 금방 깨닫게됩니다. 그리고 당신이 맞습니다!

그러나 이제 HTML 및 JavaScript 엔진이 자체 웹 사이트의 요소를 허용 목록에 추가 할 수있는 구문을 지원한다고 가정합니다. 예를 들면 :

<head>
    <script type="text/javascript">
        document.allowJavaScript(['div.item', '#list', 'a.navigate']);
    </script>
</head>

이것은 DOM 트리 중간에 <script> 태그를 렌더링하는 문제를 해결하지 못하지만 훨씬 쉽게 해결할 수 있습니다.

이전 요점 외에 설명 된 솔루션에서 어떤 종류의 문제 나 결함이 있습니까?

PDATE 1 : allowJavaScript를 호출하려면 head 요소 만 신뢰해야합니다.

PDATE 2 : 바라건대, 다음 스 니펫이 내 아이디어를 좀 더 설명합니다.

<html>
<head>
    <style>
        div.outer { background-color: #aaa; width: 200px; height: 100px; }
        div.inner { background-color: #5ff; width: 100px; height: 50px; }
        ul { list-style-type: none; }
        li { background-color: #bbc; border: 1px solid #fff; float: left;
            width: 100px; height: 30px; }
    </style>
    <script type="text/javascript">
        document.allowJavaScript(['div.outer', '#list', 'a.test']);
        function register_events() {
            var list = document.querySelector('#list');
            list.onclick = function() { alert('list'); }
            var example1 = document.querySelector('#list li:nth-of-type(1)');
            example1.onclick = function() { alert('example 1'); }
        }
        window.onload = register_events;
    </script>
</head>
<body>
    <div class="outer" onclick="alert('outer');">
        <div class="inner" onmouseover="alert('inner');">
        </div>
    </div>
    <a class="navigate" href="#" onclick="alert('a');">click me</a>
    <ul id="list">
        <li>example 1</li>
        <li>example 2</li>
    </ul>
</body>
</html>

이것은 다음의 실행을 허용해서는 안됩니다.

  1. alert('inner')-> div.outer는 허용되지만 하위 요소는 허용되지 않습니다.
  2. alert('example 1')-> #list는 허용되지만 자식 요소는 없습니다.
  3. alert('a')-> Google은 a.test가 아닌 a.navigate를 허용합니다.
13
jweyrich

화이트리스트를 <head> 요소로 제한하는 것은 <title>이 <head>의 일부이고 종종 사용자가 제공 한 데이터를 포함하기 때문에 도움이되지 않습니다. 따라서 화이트리스트 정의는 <head>의 첫 번째 요소 여야하며 첫 번째 화이트리스트 호출 만 수락 될 수 있습니다.

<li> 예 1 </ li>의 내용은이 예에서 신뢰할 수 없습니다. 따라서 공격자는 다음을 제공 할 수 있습니다.

<li>example 1><a class="test" onmouseover="alert(document.cookie)">hello</a></li>

A.test가 화이트리스트에 있으므로 코드가 실행됩니다. 엄격한 dom 요소 유효성 검사를 적용 할 수 있습니다. 그러나 <b> 및 <i>와 같은 일부 중첩 요소를 허용하고 싶을 것입니다.

허용 된 태그 및 속성의 화이트리스트를 기반으로 신뢰할 수없는 콘텐츠를 적절하게 이스케이프하는 것이 훨씬 쉬워 보입니다.

추신 : CSS에 포함 된 JavaScript와 플래시 및 Java와 같은 플러그인과 같은 다른 이름이 있다는 것을 명심하십시오.

8
Hendrik Brummermann

JavaScript는 클라이언트 측 언어입니다.

제 전문적인 의견으로는 추가 보안을 위해 클라이언트 측 구현을 신뢰하는 것은 시간 낭비이며 구현은 엄청난 자원 낭비가 될 것입니다.

서버 측 환경에서 적절한 입력 정리 및 유효성 검사를 구현하면 시간과 돈을 더 잘 활용할 수 있습니다.

14
Purge

나에게는 흥미로운 아이디어처럼 보이지만 문제에 대해 물어 보셨 기 때문에 몇 가지 명백한 아이디어로 응답하겠습니다. 대부분의 사이트에서 핵심 기능에 사용할 수있는 위험한 자바 스크립트 함수가 많이 필요한 것처럼 보이므로 이것이 대부분의 사이트에 전역 적으로 어떻게 적용될 수 있는지 모르겠습니다. 예 : onmouseover, href = "javascript : alert (1)"등. Caja 또는 JSReg 또는 JSandbox 의 대안으로 유용합니다. = DOM의 모든 수준에서 적용해야 할 수 있습니다. 예를 들어 <div name="untrusted"> 내용.

8
Weber

XSS는 일반적으로 신뢰할 수있는 페이지의 본문에 외부 Javascript를 삽입하여 작동합니다. document.allowJavaScript(['div.outer', '#list', 'a.test']);이라는 코드를 신뢰한다면 XSS 취약성에 의해 생성 된 document.allowJavaScript(['div.evil', '#securityhole', 'a.exploit']); 사이트의 다른 페이지에있는 코드를 어떻게 신뢰하지 않겠습니까? 둘 다 동일한 페이지의 동일한 컨텍스트 (XSS의 주요 아이디어)에있는 한 서로를 알 수있는 방법이 없습니다.

물론 "권한있는"컨텍스트 (예 : <head> 내부 및 <body> 내부의 "unprivileged"컨텍스트)가 있다고 말할 수 있습니다. 이것은 취약점의 일부를 다루지 만 전부는 아닙니다. 그것의. 페이지의 "권한이있는"부분에 콘텐츠를 삽입 할 수있는 XSS 취약점이 없다는 것을 보장 할 방법이 없기 때문입니다. 물론, 그 빈도는 적지 만 전체 문제를 해결하지는 못합니다. 서버에서 유효성 검사를해야합니다.

또한 유지 관리 문제가 발생합니다. 디자이너가 페이지에서 무언가를 변경할 때마다 권한이있는 요소 목록을 편집해야하는 동시에 "동적"부분은 항상 유지해야합니다. 이는 실제 프로젝트에서 수행하기가 다소 어려울 수 있습니다. 특히 일부 페이지는 완전히 다른 팀에서 생성 할 수있는 애플리케이션의 개별 부분에서 생성 된 많은 독립적 인 위젯으로 구성되어 있기 때문입니다.

7
StasM

귀하의 관심을 감안할 때 Ter Louw 및 Vernkatakrishnan의 청사진 , Dan Kaminsky의 Interpolique 및 Mozilla 콘텐츠 보안 정책을 읽어 보시기 바랍니다. 또한 context-aware auto-escaping , Google의 ctemplate에서 구현 됨 을 확인하십시오. 환상적인 선행 작업이 많이 있습니다. 바퀴를 재발 명하지 않도록하십시오.

Blueprint 및 BEEP에 대한 이전 작업에 따르면 인라인 보안 정책 (제안에서와 같이)의 위험은 XSS 주입으로 인해 공격자가 새로운 정책을 주입 할 수 있다는 것입니다. 공격자가 새 HEAD 태그를 삽입 한 다음 그 안에 allowJavaScript를 호출하는 스크립트를 추가하면 어떻게됩니까?

또한 이전 작업은 악성 자바 스크립트 실행을 중지하는 것만으로는 안전하지 않다는 것을 보여줍니다. 공격자가 HTML 페이지에 임의의 내용을 삽입 할 수있는 경우 공격자는 다음을 수행 할 수 있습니다. (i) 데이터 유출 공격을 탑재 (예 : 페이지에서 CSRF 토큰 또는 비밀 학습), (ii) 페이지 손상, (iii) 사용자를 피싱하거나 인증 자격 증명을 훔칩니다 (사용자에게 사용자 이름과 암호를 요청하는 로그인 양식을 추가하는 것을 고려하지만 양식 작업이 공격자의 사이트에 제출하는 위치), (iv) CSRF 공격을 탑재 (인라인 이미지 또는 피해자의 사이트에 URL을 자동으로로드하거나 사용자를 속이는 양식 요소), (v) 클릭 재킹/스트로크 재킹 공격 (일부는 자바 스크립트가 필요하지 않음).

이전 연구에서도 CSS를 공격하여 Javascript를 실행하지 않고도 공격이 가능함을 보여주었습니다. CCS 2010에서 Huang, Weinberg, Evans 및 Jackson의 논문을 참조하십시오. 최소한 일부 브라우저에서 문서에 주입 지점이 있으면 귀하의 계획이 이에 취약 할 수 있습니다.

마지막으로, DOM에서 요소를 화이트리스트에 추가하는 경우 HTML 페이지에 물건을 삽입하는 공격자가 악성 데이터가 화이트리스트 요소의 컨텍스트에있을 때까지 태그를 열고 닫는 것을 차단하는 것은 무엇입니까? 예를 들어 정책에 BODY 아래의 첫 번째 DIV 아래 두 번째 P 태그에서 스크립트가 허용된다고 명시되어 있고 첫 번째 P 태그 바로 뒤에 주입 지점이 있으면 공격자가 </P><P><DIV><SCRIPT>alert('nasty')</SCRIPT>을 주입 할 수 있습니다. , 이제 공격자의 불쾌한 스크립트는 페이지의 허용 목록 부분의 일부로 브라우저에 의해 처리됩니다.

전반적인 권장 사항 :이 방어에 의존하지 않는 것이 좋습니다. 여러 가지 약점이 있습니다.

6
D.W.

내가 매우 비슷한 질문을했지만 (지금까지) 돌파 할 가능성이 없었기 때문에 누군가가 귀하의 질문을 지적했습니다.
https://stackoverflow.com/questions/5821985/would-this-be-a-good-idea-against-xss

어쩌면 함께 우리는 좋은 해결책을 찾을 수 있습니다;)

1
mgutt