問題タブ [xss]

とりわけ、Cookie の存在をチェックし、Cookie の内容を読み取って復号化するアプリケーションがあります。Cookie 内に保存されているデータは機密ではありませんが、TripleDes 暗号化によって暗号化されています。今日、1 台の PC に保存された Cookie を別の PC にコピーできるかどうか、および Web アプリケーションがこのコピーされた Cookie が別のマシンに存在することを検出し、元の PC にあるものを最終的に復号化するかどうかという問題が提起されました。

私の質問は次のとおりです。標準の ASP.NET 実装を使用して Cookie を保存します (つまり、HttpResponse 経由)。index.dat ファイルは、あるマシンから別のマシンへの Cookie の移植を防止しますか? index.dat ファイルも転送およびコピーされた場合、または Cookie を特定のマシンに結び付ける内部構造が index.dat 内にある場合はどうなるでしょうか?

簡単な ASP.NET MVC ブログ アプリケーションがあり、読者がブログ投稿にコメントを追加できるようにしたいとします。あらゆる種類の XSS シェナニガンを防止したい場合は、すべてのコメントを HTML エンコードして、レンダリング時に無害になるようにすることができます。ただし、ハイパーリンク、太字、斜体などの基本的な機能が必要な場合はどうすればよいでしょうか?

StackOverflow がWMD Markdown Editorを使用していることは知っています。これは、 HTML と Markdownの両方をサポートしているため XSS 攻撃を受けやすいという事実がなければ、私が達成しようとしていることに最適な選択肢のようです。

Web サーバーをアップグレードせずにApache 2.2.4でこの脆弱性を修正する方法を知っている人はいますか?

これは、ネット上のSecurityReasonで見つけたものです。彼らが提案した修正は、バージョン 2.2.6 にアップグレードすることです。しかし、サーバーは稼動しており、アップグレードは最後の手段です。

Apache2 XSS の未定義の文字セット UTF-7 XSS の脆弱性

XSS(UTF7) はmod_autoindex.cにあり ます。文字セットは定義されておらず、文字セットを UTF-7 に設定することにより、Apache 2.2.4 で使用可能な「P」オプションを使用して XSS 攻撃を提供できます。

「P=パターンは、指定されたパターンに一致するファイルのみをリストします」

これに対する解決策を提案してください。

侵入テストアプリを実行したところ、大量の XSS エラーが見つかりました。具体的には、未検証のデータをクエリ文字列を介してブラウザにエコーバックした罪があります。

具体的には、これを実行すると JavaScript がページに挿入されます。 http://www.mywebsite.com/search.php?q=%00 '" [ScRiPt]%20%0a%0d>alert(426177032569)%3B[/ScRiPt].

ありがたいことに、ユーザーがデータベースにデータを保存して他のユーザーに表示できるようにする場所がないので、この問題で自分自身をハッキングすることしかできないと思いますが、それでも修正したいと思います。

これを行うことをお勧めします。

しかし、現在、私はこれをできるだけ早くパッチを当ててから、ケースバイケースで修正する必要があります. サイトのすべてのページにインクルードするヘッダー ファイルがあります。それが悪い形式であることはわかっていますが、そうすると何が問題になる可能性がありますか。

COOKIE と GET についても同様に行う必要があります。_REQUEST は使用しません。

ありがとう

iframe を (JavaScript を使用して) コンテンツに 100% 適合させる方法に関する質問は、既にフォーラムで回答されています...同じドメインのコンテンツを表示する iframe のみ.

私の質問: iframe の src 属性が、フレームを含むページのドメイン外のページ用である場合、コンテンツに合わせて iframe のサイズを変更することは可能ですか? クロスサイト スクリプティングに関するブラウザのセキュリティ機能により、iframe のドキュメント オブジェクトにアクセスできません。

私は創造的な解決策を探しています。私の考えの 1 つは、スクロールバーが iframe に表示されていることを何らかの方法で検出し、表示されなくなるまで高さを段階的に増やすことでした。残念ながら、表示されているスクロールバーを検出する方法も見つかりません。アイデア？

クライアント側のソリューションを探していることに注意してください。

反応：

デイブ

問題はまだ存在します。リモート ドキュメントの高さが事前にわからないため、データベースまたはクエリ文字列の値から設定することはできません。

ダソフト

CSS の iframe の 100% は、iframe内のコンテンツの 100% に設定するのではなく、ページまたはそれを含む要素 (つまり、div など) に対して相対的に設定します。

XML呼び出しを行うためにXMLHTTPRequestを使用しても、ドメイン境界を越えて呼び出しを行うべきではないと決定されたのはなぜですか？JavaScript、画像、CSS、iframe、および他のドメインから考えられる他のほぼすべてのコンテンツを取得できます。Ajax HTTPリクエストがドメインの境界を越えることが許可されていないのはなぜですか？それが悪用されているのを私が見ることができる唯一の方法を考えると、誰かがJavascriptをページに挿入した場合、それを置くのは奇妙な制限のように思えます。ただし、この場合、ドキュメントにimg、script、またはiframe要素を追加するだけで、サードパーティのURLを要求してサーバーに送信できます。

[編集]

いくつかの回答は次の理由を指摘していますが、これを許可しない主な理由を作成しない理由を指摘しましょう。

XSRF（クロスサイトリクエストフォージェリ、CSRF、XSRFとも呼ばれます）

これをまったく使用せずにXSRF攻撃を行うことができます。原則として、XMLHTTPRequestはまったく使用されません。これは、すべての主要なブラウザーと互換性のある方法でXMLHTTPRequestを作成することが非常に難しいためです。URLをロードする場合は、URLにimgタグを追加する方がはるかに簡単です。

サードパーティのサイトへの投稿

で達成することができます

JPunyon：なぜこの脆弱性を新機能に残すのですか？

あなたはこれ以上不安を生み出していません。あなたはそれを良い方法で使いたいと思っている開発者に不便をかけているだけです。この機能を悪（別名素晴らしい）に使用したい人は、他の方法を使用することができます。

結論

彼が重大な問題を指摘したので、私はbobinceからの答えを正しいとマークしています。XMLHTTPRequestを使用すると、クレデンシャル（Cookie）を使用して宛先サイトに投稿し、サイトから返送されたデータを読み取り、個人のクレデンシャルを送信できるため、確認フォームを含む一連のフォームを送信するJavaScriptを調整できます。 、XSRFを防止するために配置されたランダムキーが生成された状態で完了します。このようにして、銀行のようにターゲットサイトを閲覧することができ、銀行のWebサーバーは、これらすべてのフォームを送信するのは通常のユーザーだけではないことを認識できません。

私は内部ツールに取り組んでおり、スクリプトに権限の昇格を求めるプロンプトを表示し、受け入れられた場合はクロスサイトリクエストなどを許可する方法があったことを思い出します...これは内部ツールであるため、必要なものを達成できる可能性があります.

誰もこれを行う方法を知っていますか?

詳しく説明すると、パフォーマンス分析情報を提供するために、ページに挿入されたサードパーティの追跡 iframe の内容を (javascript で) 読み取ろうとしています。これらの iframe は明らかに別のドメインのものです。私が彼らを代理した場合、彼らはもはや正確な情報を提供しないので、その選択肢はありません.

私はちょっとした wiki を書いていて、構文の強調表示のすべてのオプションを調べています。ウィキ構文 (mediawiki) とマークダウン + ホワイトリストに登録されたタグの間の議論。私は後者を好むと思いますが、ユーザーにはテーブルが必要だと思います。ここ Stackoverflow でテーブルが許可されていないのはなぜですか?

HTML フォームに入力すると、Firefox や Internet Explorer などのブラウザーは値を保存しますが、場合によっては静かに保存されます。そのため、別の Web フォームに入力すると、ブラウザは同じ情報をスマートに提案します。ドロップダウン リストを表示する別の方法は、空のテキスト ボックスをダブルクリックすることです。

E コマース Web サイトで、顧客はクレジット カード番号やその他の機密情報を入力します。機密情報を保存するブラウザを回避またはブロックするにはどうすればよいですか?

もう 1 つの懸念は、格納されたフォーム データの改ざん (たとえば、マルウェアによる) です。次に、顧客はこの汚染されたデータを選択して、サイトを危険にさらすことができます。

NodeタイプのDOMがTextブラウザによってHTMLとして解釈されないことが保証されているかどうかを知っている人はいますか?

詳細は次のとおりです。

バックグラウンド

私は友人のために簡単な Web コメント システムを構築しており、XSS 攻撃について考えています。HTML タグのフィルタリングやエスケープは、非常に洗練された解決策ではないと思います。フィルターをすり抜けてしまう畳み込みを考え出すのは簡単すぎます。基本的な問題は、特定のコンテンツ (つまり、認証されていない Web ユーザーが無作為に POST するコンテンツ) について、ブラウザーがコンテンツを解釈または実行しようとしないことを保証したいということです。

プレーン（テキスト）の開始

頭に浮かんだ最初の考えは、単に を使用することContent-Type: text/plainですが、これはページ全体に適用する必要があります。ページの途中にプレーンテキストを配置することはできますがIFRAME、見苦しく、ユーザーがフレームをクリックするとフォーカスの問題が発生します。

innerText/textContent/JQuery

innerTextブラウザー固有 ( IE、textContentFF、Safari など) の属性がいくつかあることが判明しました。これらの属性を設定すると、単一のTextノードを作成する必要があります。

text(val)JQuery は、ブラウザー固有の属性をスキップして に直接移動する単一の関数を実装することにより、ブラウザー固有の属性の違いを回避しようとします。document.createTextNode(text)これは、ご想像のとおり、ノードを作成しTextます。

Text NodeW3 DOM

これは私が望むものに近いと思います。見た目は良いです。Textノードは子を持つことができず、HTML として解釈できないように見えます。しかし、公式ドキュメントからは 100% 確信が持てません。

• インターフェイスNode: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1950641247
• インターフェイスText: http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1312295772
• textContent: http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

の部分textContentは、「設定時に解析も実行されず、入力文字列は純粋なテキスト コンテンツとして取得される」と記載されているため、特に励みになります。しかし、これはすべてのノードの基本ですかText、それとも設定したノードのみtextContentですか? これはおそらくばかげた言い訳のように思えますが、IE はサポートしていないためtextContent(上記を参照)、これは重要なことかもしれません。

最初の質問に戻る

これが機能することを誰でも確認/拒否できますか? つまり、w3 DOM 準拠のブラウザーは、コンテンツが何であれ、ノードを HTML として解釈しないということですか? Textこの苦しむ小さな不確実性が解決されたことに、私は非常に感謝しています。

お時間をいただきありがとうございます！