2017-12-27 27 views
3

私はやや関係のある質問div contenteditable, XSSを読んだことがありますが、答えはcontenteditableのXSSの安全性についてはあまり強調していません。特に、偶発的な(クロスサイトスクリプティングとの比較)私は、もちろん、私はユーザー入力をサーバー側で消さなければならないことに気付いています。HTML5のcontenteditable属性はXSSに対して安全ですか?

TL.DR.:ユーザーがページを介して外部スクリプト(クリップボードから貼り付けられたデータを介して)を導入する危険性がないことを確認できますか?contenteditable?スペックは、contenteditableに貼り付けられたマークアップがDOMに挿入される前に消されていることを確認していますか?

私は偶然contenteditableタグに能動素子を挿入することは不可能であると思われることを、私がテストした二つの主要なブラウザ、クロム/ ChromeとFirefoxの上でそれに気づきました。

  • ユーザーをコピーして、1つのWebページからのDOM要素の選択と別のサイトにcontenteditable要素に挿入します:私はインスタンスのことを想像しただろうなaccedental挿入するための一例。
  • ユーザは(Linuxのコマンドラインで)echo "<b onclick='alert("XSS");'>click me</b>" | xclip -t text/html -selection "clipboard"と貼り付けて、contenteditableに貼り付けます。

能動素子は、のようなものであろう:例えばようなJavaScriptのhref属性を含むonclick="alert(\"XSS\");"

  • HTMLマークアップとしてインラインハンドラを持つ要素を含む<script>
  • HTMLマークアップを含む

    • HTMLマークアップ<a href="javascript:alert(\"XSS\")"> click me </a>

    私の質問は、contenteditableが通常のXSSベクターを貼っていることから幾分安全だと思っています。

    私はそれがどちらも明示的contenteditableはどちらも、それが許されることを、がページのDOMに挿入されている任意の能動素子を防ぐ必要があることを言及しないところ、いくつかのspecs/refs/whateverを読みました。 contenteditableに挿入されている外部のJavaScriptを危険にさらしたくないので、私はcontenteditable機能を使うべきかどうか疑問に思う。このXSSの安全性に答えてcontenteditableがこの質問の中核です。

    アップデートはcontenteditable属性類似した機能文書designModeとは対照的に 、(https://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#designModeScriptBlockedを参照)についてのJavaScriptが無効になっている(したがって、XSSを防ぐ)、特定のようです。

    UPDATE 2 MDNに引用された最新の参照/仕様はcontenteditableがペースト経由で悪質なJavaScriptを導入しないことを提供していいかなる保証についての奇妙な無関心であるhttps://html.spec.whatwg.org/multipage/interaction.html#contenteditable です。

  • +3

    サーバー側の入力をサニタイズする限り、JavaScriptを「contenteditable」に貼り付ける理由は問題ではありません。誰でもDevツールを開き、XSS攻撃を防ぐためにサーバ側が設定されていない場合は、XSS攻撃に十分なJavaScriptをページ上で実行できます。 –

    +0

    @DeepakKamat悪意のあるスクリプトを貼り付けると、このpriveledgesを継承すると、問題があると思うでしょう(ユーザーがログインしていて、コンテンツを削除するような特権があると仮定します)。あなたは何と言うでしょう?さらに、XSSの安全性はユーザーデータの安全性(入力データなど)を悪意のあるスクリプトでカバーしています。可能であれば、「contenteditable」を介して悪質な第三者に送信します。確かにそのサーバーは妥協ではないが、私の理解でもXSSはユーザーアカウント/データを攻撃するので、私の懸念は – humanityANDpeace

    +0

    なぜあなたは9年前から仕様を現在の仕様の代わりに読んでいるのですか? – BoltClock

    答えて

    0

    ブラウザに従わなければならない標準はないので、各ブラウザにはユーザー入力を処理する独自の実装があります。方法がある場合は、ユーザーがその方法を理解できるようにすることができます(古いブラウザが通常最も影響を受けます)。入力、貼り付けなどからユーザーの入力を害するのはユーザーの責任です(プロジェクトのためにこれを行う必要がありました。単に「うまく作業している」ということに頼ることはできません)。

    のdesignMode、リンクされた部分については:

    スクリプトは、スクリプトが無効になっているスクリプトの実行コンテキストで実行する場合、スクリプトは何もしないし、何も返さないしなければならない(ボイド戻り値)。

    たとえば、designModeを有効にすると、ドキュメント内のスクリプトによって設定されたイベントハンドラ属性、イベントリスナー、タイムアウトなどが無効になります。

    これにより、designModeが安全に見えるようになりますが、時間が経つにつれて仕様が変化することを忘れないでください。そのため、さまざまなブラウザ(またはユーザーの少なくとも1つ)をすべてテストしなくても決して確かではありません。

    +0

    私は "安全"をテストしました、 'document.designMode = "on"と期待どおりに動作しませんでした。 https://stackoverflow.com/q/47996078/1711186 – humanityANDpeace

    +0

    Gmailはhtml5ユーザーインターフェースで「contenteditable」を使用しているため、潜在的なXSSやHTMLInjectionは想像できません。https://davidyat.es/2016/02/16/contenteditable/issueはブラウザに残っています。私にとって、contenteditableを実装する限りでは、コンテンツを貼り付けることでデータが破損する危険性がないように、ブラウザを実装することは完全に論理的なことです。答えが標準でないということは、衝撃的でも偽でも、危険でもあります:) – humanityANDpeace

    +0

    私は恐ろしいですね!しかし、私は信じて、フォーム要素、入力イベント、およびcontenteditableにw3仕様を読んでいるドキュメンテーションを通して、それが実装固有のものであると結論づけて何時間も閲覧しました。 http://www.w3.org/TR/#w3c_all私は、contentEditableを使ってGMailに似たHTMLベースのメールシステムを開発しました。独自のJSを内部で実行したいので、designModeを使用することはできませんでした。 contentEditableは実際にはまたは