1

サイト訪問者が印刷用にページに注釈を付ける手段を提供する javascript のクライアントのみのソリューションと、XSS または同様の攻撃ベクトルの観点からの悪用可能性について議論してきました。

理由: 表示するデータを選択するプロセスが長くなる可能性があります。実行した手順を文書化するために、サーバーに転送することを想定していない任意のテキストをユーザーが書き込むことができるテキストエリア( formを囲むことなく) が提供されます。最初のテキストは静的です。たとえば、このフィールドの使用方法に関する短い一連の指示などです。そのため、攻撃者がこのテキストエリアに対して悪意のある JavaScript を含む URL を構築する (明らかな) 可能性はありません。

ユーザーがこのテキストを変更すると、ページ (およびメモ) が印刷されます。ユーザーがページを離れると、メモは失われます。

「散文エラーが多すぎる」場合のコード例を次に示します。

<span id="descriptionHeader">Description of the result</span>
<div id="description">
  <textarea id="descriptionEditor" rows="15" cols="80" type="text"
            ondblclick="replaceDescription()">
Edit this text to add a detailed description to this page.
Double click to this editing area to finish editing.
If you want to edit the text again, do a double click to the
description header.
You may use html (e.g. <br>) for formatting.
   </textarea>
 </div>
 <script type="text/javascript">
    var header = getElem("descriptionHeader");
    var editor = getElem("descriptionEditor");
    var description = getElem("description");

    function empty() {
    }

    function editDescription() {
        header.ondblclick = empty;
        editor.value = description.innerHTML;
        description.innerHTML = "";
        description.appendChild(editor);
    }

    function replaceDescription() {
        header.ondblclick = editDescription;
        description.removeChild(editor);
        description.innerHTML = editor.value;
    }
</script>

また：

  • テキストがサーバー側で処理されることはなく、静的な説明 (「使用方法」) のみがサーバーからクライアントに送信され、クライアントからサーバーに送信されることはありません。
  • ユーザーは、好きなように JavaScript 要素を追加して、自分自身を悪用する可能性があります。
  • これがセキュリティ上のリスクをもたらすシナリオは考えられませんが、吐き気は残ります...

注: 問題は、このソリューションのエレガンスや、より快適なインライン編集を行うライブラリに関するものではなく、純粋に考えられるセキュリティ リスクに関するものです (もしあれば)。

4

3 に答える 3

2

ソーシャル エンジニアリング攻撃の可能性があります。ページに追加する美しいテンプレートと思われるものを (チャットなどで) ユーザーにコピー アンド ペーストするように依頼します。

パスワードを要求するよりも、ユーザーには疑わしく見えないかもしれません。ただし、フォーラムなどの公共の場所に投稿された場​​合、非常に迅速にフラグが立てられる可能性があるため、標的型攻撃を除いて機能しません。

クライアントとサーバー間でデータがやり取りされないため、自動化された攻撃は見られません。すべての攻撃はクライアント側であり、DOM を変更したり、ページで JavaScript を呼び出したりする可能性のあるソーシャル以外のクライアント側の攻撃では、XSS を実行するためにこれは必要ありません。

必要に応じてソーシャル エンジニアリングのクリックジャッキングが使用される可能性があることに注意してください。サイト上で複数の iframe を使用し、その下の iframe にサイトを配置すると、攻撃者はフォームがサイト上のフォームであるという事実を隠すことができますが、それでも攻撃者は次のことを行う必要があります。ユーザーをだまして、javascript コードをコピーして入力テキスト ボックスに貼り付けます。

HTML の機能を失わずに入力を保護するには、 stackoverflowのようなコードを JavaScript に移植することで HTML をフィルタリングできます(または、ライブ プレビューで使用される JavaScript バージョンのライセンスを取得してください)。

于 2009-02-27T12:00:12.497 に答える
2

description.innerHTML = editor.value;

ユーザーが適切な <script> タグを入力することで妥協するよう説得される可能性は比較的低いとはいえ、HTML を入力できるようにする必要は実際にあるのでしょうか? 単に値をエスケープするのはどうですか:

function escapeMultiline(s) {
    return s.split('&').join('&amp;').split('<').join('&lt;').split('\n').join('<br />');
};

description.innerHTML= escapeMultiline(editor.value);

そうすれば、ユーザーは < 文字と改行を HTML と誤解されることなく、喜んで入力できます。

（もちろん、帰りにも同様の脱エスケープがあります。）

于 2009-02-27T12:13:01.267 に答える
0

アプリケーション全体を知らない。あなたのシステムを攻撃することは可能だと思います。別のページからいくつかの有効な js/other 呼び出しを確認できる場合、このページにそのコードを挿入して、バックエンド データを変更しようとする可能性があります。前述のように、システムの構築方法に依存する可能性があります。

/アルベルト

于 2013-07-18T17:14:11.860 に答える