1. 홈
  2. 질의 응답
  3. HTML5의 contenteditable 속성은 XSS 안전합니까?

HTML5의 contenteditable 속성은 XSS 안전합니까?

2017-12-27 8 views
3

다소 관련있는 질문 div contenteditable, XSS을 읽었지만 그 대답은 contenteditable의 XSS 안전성에 대해별로 강조하지 않습니다. 특히 우발적 인 경우 (심각한 크로스 사이트 스크립팅과 비교하여). 나는 물론 사용자 입력 서버 쪽을 위생적으로해야한다는 것을 알고있다.HTML5의 contenteditable 속성은 XSS 안전합니까?

TL.DR. : 페이지 요소 contenteditable을 통해 사용자가 일부 외부 스크립트 (예 : 클립 보드에서 붙여 넣은 데이터를 통해)를 소개 할 위험이 없다는 것을 확신 할 수 있습니까? 스펙은 contenteditable에 붙여진 마크 업이 DOM에 삽입되기 전에 삭제되는지 확인합니까?

나는 실수로 contenteditable 태그 내로 활성 요소를 삽입하는 것은 불가능 것 같다, 내가 시험 두 가지 주요 브라우저, 크롬/크롬과 파이어 폭스에 그것을 발견했습니다.

  • 사용자를 복사 한 웹 페이지에서 DOM 요소의 선택 및 다른 사이트에 contenteditable 요소에 삽입 : 내가 예를 들어로 상상 한 것 같은 accedental 삽입 예.
  • 사용자가 (리눅스 명령 행에서) echo "<b onclick='alert("XSS");'>click me</b>" | xclip -t text/html -selection "clipboard"을 붙여서 contenteditable에 붙여 넣습니다.

능동 소자는 것이 아무것도 같은

  • 인라인 핸들러 등 같은 스크립트하는 HREF 포함 된 HTML 태그
  • onclick="alert(\"XSS\");" 등으로 소자를 포함하는 <script>
  • HTML 태그를 포함하는 HTML 태그 <a href="javascript:alert(\"XSS\")"> click me </a>

이제 제 질문은 contenteditable이 정상적인 XSS 벡터를 붙여 넣는 것을 다소 안전하다고 생각합니다.

는 어느 쪽도 명시 적으로 어느 쪽이 허용 될 것이라고 contenteditable 어떤 활성 요소 페이지의 DOM에 삽입되지 않도록해야한다고 언급하지 않는 경우 좀 specs/refs/whatever을 읽었습니다. contenteditable에 외부 자바 스크립트가 삽입되는 위험을 감수하고 싶지 않기 때문에, 내가 contenteditable 기능을 사용해야한다면 의심의 여지가 있습니다. 이 XSS 안전성에 대한 대답 contenteditable이이 질문의 핵심입니다.

업데이트는 contenteditable 특성과 유사한 기능 문서 designMode 달리 (https://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#designModeScriptBlocked 참조)에 대한 자바 스크립트가 중지되고 (따라서 XSS 방지) 구체적으로 보인다.

업데이트 2 MDN에 인용 된 가장 최근의 참조/스펙 contenteditable 붙여 넣기를 통해 악의가 자바 스크립트를 도입하지 않는 제공하는 모든 보증에 대한 이상한 무관심 https://html.spec.whatwg.org/multipage/interaction.html#contenteditable 이다.

출처

2017-12-27 humanityANDpeace

+3

서버 쪽에서 입력 내용을 살균하는 한, 왜 'contenteditable'에 자바 스크립트를 붙여 넣는 사람이 문제가되는지 알 수 없습니다. 누구나 Dev Tools를 열 수 있으며 서버 측에서 XSS 공격을 막기에 충분하지 않은 JavaScript를 페이지에서 실행할 수 있습니다. –

+0

@DeepakKamat 악의적 인 스크립트를 붙이면이 priveledges를 상속받을 것이라고 생각합니다. (예를 들어, 사용자가 로그인되어 있고 컨텐츠를 삭제하는 것과 같은 특정 priveledges가 있다고 가정합니다.) 너 뭐라고 말 할래? 또한 XSS 안전성은 사용자 데이터 (예 : 입력 데이터)의 안전성을 악성 스크립트로, 가능한 경우 'contenteditable'을 통해 xhr/악의적 제삼자에게 보낼 수 있다고 가정합니다. 서버가 손상되지 않았음에도 불구하고 내 이해에서 XSS가 사용자 계정/데이터를 공격한다는 점이 나쁘다. 따라서 내 관심사가 – humanityANDpeace

+0

왜 현재 스펙 대신 9 년 반 전에 스펙을 읽는가? – BoltClock

답변

0

브라우저가 준수해야하는 표준은 없으므로 각 브라우저에는 사용자 입력을 처리하기위한 자체 구현이 있습니다.그리고 방법이 있다면 사용자가 어떻게해야하는지 파악할 수 있습니다 (예전 브라우저가 일반적으로 가장 취약합니다). 입력, 붙여 넣기 등 사용자의 입력을 위생하는 것은 사용자의 몫입니다 (프로젝트에서이 작업을 수행해야했기 때문에 "올바르게 작동하는"방법에 의존 할 수는 없습니다). 대해 designMode에 관해서는

, 당신은 연결 부분 : 스크립트, 스크립트가 비활성화되어있는 스크립트 실행 컨텍스트에서 실행될

, 아무것도 아무것도하지 않고 반환해야하는 스크립트 (무효 반환 값).

예를 들어, designMode를 활성화하면 문서의 스크립트에서 설정 한 이벤트 핸들러 속성, 이벤트 리스너, 시간 초과 등이 비활성화됩니다.

이렇게하면 designMode를 사용하면 시간이 지날수록 진화하는 사양을 기억할 수 있으므로 다양한 브라우저 (또는 사용자가 가진 브라우저)를 모두 테스트하지 않아도됩니다. 절대.

출처

2017-12-27 17:13:17 skyline3000

+0

"안전"을 테스트했으며, document.designMode = "on"과 예상대로 동작하지 않았습니다. https://stackoverflow.com/q/47996078/1711186 – humanityANDpeace

+0

Gmail은 html5 사용자 인터페이스에서 'contenteditable'을 사용하므로 잠재적 인 XSS 또는 HTMLInjection을 상상할 수 없습니다. https://davidyat.es/2016/02/16/contenteditable/문제가 브라우저에 완료되었습니다. 나에게 그것은 contenteditable을 구현하는 것까지 모든 브라우저가 내용을 붙여 넣는 것이 데이터 위반을 위험에 빠뜨리지 않는 방식으로 구현할 것이라는 것이 완전히 논리적 인 것처럼 보인다. 표준이 없다는 대답은 충격적이거나 거짓이거나 위험합니다 :) – humanityANDpeace

+0

나는 두려운 말을 할 것입니다! 그러나 나를 믿어 라, 나는 폼 요소, 입력 이벤트, 및 contenteditable에 대한 w3 스펙을 읽는 문서를 통해 구현 특정 적이라고 결론 지을 때까지 몇 시간 동안 탐색했다. http://www.w3.org/TR/#w3c_all 나는 contentEditable을 사용하는 GMail과 유사한 HTML 기반 메일 시스템에서 작업했고 우리 자신의 JS가 여전히 내부에서 실행되기를 원했기 때문에 designMode를 사용할 수 없다. contentEditable은 실제로 또는