web-dev-qa-db-ja.com

JavaScript入力を許可するがXSSを防止するソリューション

ユーザーがHTMLとJavaScriptを入力してブログページを作成できるようにするシンプルなブログシステムがあります。 JavaScriptを許可すると、xss攻撃への扉が開かれることを知っています。ただし、JavaScriptを含むGoogle広告コードをユーザーが挿入できるようにするため、ユーザーがJavaScriptを挿入できるようにする必要があります。問題は、xssを防ぎながらJavaScriptを許可する方法です。 httpsはCookieを保護し、Cookieの盗用を防ぐと想定していましたが、stackoverflowのユーザーは別の言い方をしました。

appsecweb-applicationweb-browserxssjavascript
15
Hussein

httpsはすべてencryptionに関するものであり、他の人がトラフィックを聞かないようにサーバーIDを保証します。したがって、同じOriginポリシーの範囲内の悪意のあるJavaScriptコードに対してはまったく役に立ちません。

httpOnlyと呼ばれるcookieにフラグがあり、最新のブラウザーの単純なJavaScriptコードがcookieにアクセスできないようにしています。しかし、これは問題を解決しません。エクスプロイトを少し単純にするだけです。JavaScriptコードは、現在のユーザーの権限でフォーム送信を直接トリガーできます。 JavaScriptは同じドメイン上にあるため、 [〜＃〜] csrf [〜＃〜] トークンにアクセスできます。ブラウザは、JavaScriptコードがアクセスする必要なく、フォーム送信にCookieを含めます。 （また、HttpOnlyには多くのバグがあります。たとえば、一部のブラウザーではXMLHttpRequestオブジェクトからCookieを読み取ることができます。）

さらに、JavaScriptの作成者は、現在のページのコンテンツを「セッションがタイムアウトしました。もう一度ログインしてください」とその独自のログインフォームに置き換える場合があります。しかし、彼が追加するフォームは、サーバーのログインURLではなく、彼が制御するサーバーを指しています。あるいはさらに微妙なことに、submit-buttonのイベントハンドラーにクロスドメインのAjax呼び出しがあるかもしれません。

2つのステップでかなり単純なソリューションがあります。

  1. すべてのJavaScriptを含む、すべての非信頼マークアップをフィルタリングします。 PHPを使用している場合は、 HTML-Purifier を使用できます。すべての一般的な言語に似たライブラリがあります。
  2. 無害なプレースホルダーを提供します（ "widgets"）。したがって、ユーザーがJavaScriptコードを直接埋め込むのではなく、<div id="googleadd">identifier</div>のように記述する必要があります。信頼できるグローバルJavaScriptコードの一部は、これらのコードフラグメントを実際の追加コードに置き換えることができます。入力パラメータは適切にエスケープしてください。これにより、ユーザーができることは少し制限されますが、すべての一般的なユースケースをカバーするのは非常に簡単です。

すでに多数のウィジェットライブラリが存在しているため、グーグルに少し意味があります。それらのほとんどはまだJavaScript呼び出しが必要です。

12
Hendrik Brummermann

HTTPSはCookieの盗用を防止しません HTTPOnlyフラグ は防止します。 （可能であれば）ユーザーがページに含めて構成できる「ウィジェット」のライブラリを用意することをお勧めします。その後、ユーザーがJavaScriptコードを作成することを許可せずに、構成済みのパラメーターを使用してJavaScriptコードを挿入できます。

ユーザーが独自のJavaScriptコードを挿入できるようにすると、ユーザーはブログシステムのログインフォームを更新して別のサーバーに認証情報を送信できるため、悪意のあるブログページにアクセスしてシステムにログインすることを決定できます。そのページでは、彼の資格情報が侵害される可能性があります。

9
bretik

いいえ、HTTPSはこの脅威を阻止しません。

ユーザーがページに書き込んだJavascriptを含めることを許可する必要がある場合、これは非常に困難な問題です。あなたが望むのはある種のJavaScriptサンドボックスです。 @Mike SamuelによるCajaの推奨は、Javascriptサンドボックステクノロジーの良い選択です。この分野の他の可能性には、MicrosoftのWebサンドボックス、YahooのAdSafe、FacebookのFBJS、そしておそらく私が見逃した他のものがあります。

ソリューションは存在しますが、展開するのは簡単ではありません。あなたはWebセキュリティの難しい問題に遭遇しました。 Webはこの種のものをサポートするように設計されていないだけであり、その結果、ソリューションは必然的にかなり複雑なテクノロジーになってしまいます。したがって、これらのソリューションの1つをWebサイトに展開および統合するには、有能な開発者のサポートが必要になるでしょう。

7
D.W.

恥知らずだが関連するプラグ：

code.google.com/p/google-caja/ から

Cajaを使用すると、WebサイトはサードパーティからのDHTML Webアプリケーションを安全に埋め込むことができ、埋め込みページと埋め込みアプリケーションの間の豊富な相互作用が可能になります。オブジェクト機能のセキュリティモデルを使用して、幅広い柔軟なセキュリティポリシーを可能にします。これにより、含まれているページは、組み込みアプリケーションによるユーザーデータの使用を効果的に制御し、ガジェットがガジェットのUI要素間の干渉を防止できるようにします。

6
Mike Samuel

定義により、JavaScriptを格納し、それをブラウザーでレンダリングすると、XSSになります。

1）IDを追加

2）使用ポリシーを追加します： https://www.google.com/analytics/tag-manager/use-policy/

3）私はサーバーサイトフィルタリングのホワイトリスト/ブラックリストに反対しています。これは主な問題の回避策であり、正しく行うことが難しく、ドロップしてはならない入力をドロップできるためです。 HTML5、CSS3、JSが進化し続けている場合、サニタイザが配置されているすべてのことを許可する非常に大きなコードの平和になるまで、ホワイトリスト/ブラックリストを更新し続ける必要があるため、その目的を達成できなくなります。ただし、このトラックにOWASP HTML Sanitizerを主張する場合、JSoupは上記とは別の例です。

4）3）の代わりに https://content-security-policy.com/ を使用して、古いブラウザーのサポートを削除します。これは、コンテンツを格納するサーバー上でこれを修正する適切な方法です。ブラウザのコンテキストで実行します

5）テンプレートタグ/プレースホルダーを追加してリスク（例：マークダウン）を減らすことができます。これは、ペンテストツールがエコーバックしないようにするのにも役立ちます; alert（1）;サーバーがjavascriptを保存して送信するために異なる入力を期待するため

6）AVを実行し、サーバーで静的コードアナライザーを強化して、次に移動します。

7）エラーの組み込み検証：JSLint/JSHint/CSSHintなど

8）最後に、上記の自動化のいずれも信頼できない場合は、ヒューマンファクターを追加して、公開前にステップを確認および承認します。

1
const

Google-analiticsは定義上XSSであるため、googleトラッキングを許可すると、XSSはすでに許可されます。

ユーザーが適切にサニタイズできるIDのみを貼り付けるテンプレートを設定できます。

JavaScript入力を許可することはできず、安全です。以下のコードを試してください。安全だと思いますか？危険を示唆するキーワードはありますか？ :)

_$=''|'',_=$+!"",__=_+_,___=__+_,($)[_$=($$=(_$=""+{})[__+__+_])+_$[_]+(""+_$[-__])[_]+(""+!_)[___]+($_=(_$=""+!$)[$])+_$[_]+_$[__]+$$+$_+(""+{})[_]+_$[_]][_$]((_$=""+!_)[_]+_$[__]+_$[__+__]+(_$=""+!$)[_]+_$[$]+"("+_+")")();
_

スポイラー：alert(1)です

1
naugtur