クロスサイトスクリプティング（XSS）について開発者に教える重要な概念は何ですか？
私は、クロスサイトスクリプティングに関する開発者（そのうち100人まで）の1時間のトレーニングを支援しています。それらを理解するために不可欠であると思う概念は何ですか？今私たちは持っています：
- 反映と保存の違い
- 防御層（ WAF 、ブラウザ防御、サーバーヘッダー、安全なコーディング）
- 安全なコーディングとエンコーディングパラメータのコンテキスト
そして何よりも、脆弱性の潜在的な影響。
開発者の観点から見ると、最初の2つのポイントはあまり関係ありません。保存されたXSSとリフレクトされたXSSは同じ緩和策を備えています。つまり、出力するものをコンテキストに応じて適切にエスケープします。防御層は、この緩和策を適切に実装していない場合の言い訳としてのみ見なされる可能性があります。「WAFは私にそれをキャッチします。」
代わりに、これらのコードの衛生習慣に焦点を合わせてください。
- 入力時にエスケープではなく検証します。入力の検証は、入力が「安全」であるという意味ではなく、入力が意味をなすことを保証するためにのみ行う必要があります。この時点では、使用される場所がすべてわからないため、安全かどうかを知ることはできません。
- すべてのデータが安全でないと仮定します。一部のデータがエスケープされている、またはタグや引用符やエンティティなどが含まれていないと仮定しないでください。安全でない入力はどこからでも発生する可能性があることを理解してください：HTTPヘッダー、Cookie、URLパラメーター、一括インポートデータなど。
- 使用時にエスケープします。使用時に、データが使用されるコンテキストのデータをエスケープします。パフォーマンスを改善するために一度だけ脱出したいですか？安全に使用できる場所に従って、宛先変数に名前を付けます：
jsstringsafeEmail、htmlattrsafeColor、htmltextsafeFullNameなど。
それらを理解するために不可欠であると思う概念は何ですか？
- リフレクトと保存の違い-本当に気にしません。
- 防御層-はい。多くの開発者は「多層防御」を理解していません。他のすべての緩和策が失敗し、コードがlastであり、攻撃者と脆弱なリソースの間に立っていると仮定します。攻撃を緩和するために何ができますか？
- 安全なコーディングとエンコーディングパラメータのコンテキスト-絶対に。
- そして何よりも、脆弱性の潜在的な影響。 -絶対に
ほかに何か？リストから欠落している大きなことは、これらの潜在的な脆弱性を軽減するためにすべて使用できる非常に多くのツールとテクニックがあることです。多層防御は、可能な限りそれらを使用することを示唆しています。
- 設計上、デフォルトで安全であること。設計と実装のすべての段階で脆弱性について考えます。必要に応じてinを選択せず、必要に応じてoutを選択するようにしてください。
- 正式な脅威モデルを作成します。敵対的なデータはどこにシステムに入ることができ、どこに出ることができますか？どのサブシステムが相互に信頼し、どのサブシステムが相互に信頼していませんか？境界がどこにあるかわからない場合、攻撃に対して境界を強化することは困難です。
- 弦は敵です。データは、連結および分割できる文字列ではなく、インテリジェントに構成できるスマートオブジェクト内を流れる必要があります。
- タイプシステムがある言語を使用している場合は、データがタイプシステムで汚染されているかどうかをキャプチャします。汚染されていないデータを期待するコンテキストに汚染されたデータを割り当てていることをコンパイラーに通知させます。
- コンパイラがバグを見つけられない場合は、命名規則で型システムをエミュレートしてください。変数に汚染されたデータが含まれている場合は、その名前のどこかに「汚染」されている。名前に「汚染」されていない変数に汚染された値を割り当てると、攻撃者が成功したときではなく、コードのレビュー時に問題が発生したことになります。
- この種の問題を見つけるには、セキュリティの専門家が設計した静的分析ツールを使用してください。出力に注意してくださいfalse positivesも。誤検知は、コードがアナライザーによって正しいと見なされなかったことを示しています。つまり、人間が正しいと見なすこともできない可能性があります。ツールが誤検知を検出しないようにコードを修正します。
- ユーザーではなく、攻撃者のようにすべてをテストします。入力をサニタイズするコードがある場合は、チームのメンバーに攻撃を仕掛けます。サニタイザーのバグは、見つけにくい脆弱性の一般的な原因です。
- 本番環境での設定ミスをテストします。 XSSの脆弱性は、デバッグまたはテストの目的で誤って一部の検証またはサニタイズをオフにし、オンに戻すのを忘れたり、間違った構成を本番環境にプッシュしたりすることによって引き起こされる可能性があります。
- 等々。
基本のほとんどをカバーしました。あなたのポイントを少し拡張するために（これらのいくつかはここでほとんどの読者に明白に見えるでしょうが、必ずしもすべての開発者に明白であるとは限らないかもしれません）：
- XSSは、GETおよびPOSTを介して発生する可能性があります。
- XSSは、管理バックエンドの問題でもあります。
- DOMベースのXSSが存在します。
- ブラウザの防御は存在しますが、頼るべきではありません。 WAFとサーバーヘッダーについても同様です。
- エンコーディングは、入力を受信するときではなく、印刷するときに発生します。
- コンテキストは本当に重要です。状況によっては、HTMLエンコーディングでは不十分です。
- JavaScriptとCSSのエスケープ/エンコードは困難です。既存のライブラリを使用することをお勧めします。
- すべてのパラメーターをエンコードする必要があります。安全ではないように見えるパラメーターのみをエンコードするのは良い方法ではありません。
- 追加の入力フィルタリングを強くお勧めします（たとえば、整数が必要な場合は、それが実際には整数であり、理想的には一部の入力クラスにローカライズされていることを確認してください）。
しかし、私の意見で最も重要な点：HTMLエンコーディングはデフォルトで行われる必要があります、デフォルトですべてのパラメーターをエンコードするテンプレートエンジンを使用することによって。
エンコーディングが至る所で発生する場合、一度だけ忘れることは簡単です。もちろん、HTMLエンコーディングでは不十分なすべての状況に対処することは依然として重要ですが、ほとんどのXSS脆弱性はデフォルトのエンコーディングによって防止されます。
教えるべき最も重要な2つの教訓は次のとおりです。
- マークアップまたは他の構造化テキスト表現（JSON、SQL、URLクエリ文字列など）をアドホックな方法で文字列を連結して生成している場合は、実行中の処理を停止しますすぐに、centralizedおよびsafeマークアップまたはDOM生成用のライブラリ。
- 次のいずれかを実行する必要があるXSS防止戦略を信用しないでください。
- 攻撃者が何を試みるか、さもなければ攻撃者を裏切ろうとするかを推測します。特に、入力側のフィルターは攻撃者に裏打ちされた歴史があり、疑わしいと見なされるべきです。
- さまざまなコンテキストで何度も繰り返し特定します。どの変数が「信頼できない」入力であり、例外的に処理する必要があります。 （むしろ、すべての入力はデフォルトで信頼できないようにする必要があります。オプトインではなく、XSS保護をオプトアウトする必要があります。）
私の最初のポイント：ほぼすべてのインジェクションの問題は、間違ったレベルの抽象化での作業から発生します：プログラマーは、より高い値を使用する必要がある状況で文字列を連結しています正しい方法から抽象化するレベルレベルの操作。これは次のことを意味します。
- プログラマーは、まったく同じ、トリッキーな問題に何度も取り組みます（挿入されたコンテキストでの文字列値の正しいエスケープ）。毎回正しく実行されたとしても（たぶんそうではありません！）、ソリューションは再利用されません。
- 文字列値を正しくエスケープする責任は1つの場所に集中するのではなく、コードベース全体に分散されるため、セキュリティのコードの監査と問題の修正は数桁難しくなります。
2番目の点については、入力側のフィルタリングに依存することの危険性についての良い教訓は、OWASPの XSS Filter Evasion Cheat Sheet を参照することです。そのページを、入力側のフィルタリングを通じてXSSを解決する際の失敗の試みと、攻撃者がそれを回避するために使用できる巧妙さを文書化していると考えてください。
また、「信頼できない」入力とそれらを処理する方法について多くのアドバイスをよく目にしますが、これには危険が伴います。
- 信頼できる入力を特定することは、特に何度も何度も実行する必要がある場合、多くの作業です。
- 信頼できる入力を誤って判断する可能性があります。
- 今日信頼できる入力は、明日は信頼できないかもしれません。
OWASPの XSS防止に関するチートシート は、私の2つのポイントに続くもう1つの本当に優れたドキュメントです。 安全に動的に生成されたHTMLに任意文字列を挿入する方法に焦点を当てています、 CSSおよびJavaScriptドキュメント。その問題を1つの場所（サードパーティのライブラリまたはコードベースのいずれか）で解決し、その解決策を一貫して適用すると、非常にうまく機能し、XSSの脆弱性の「ごまかし」をなくすことができます。
あなたはすでに最も重要な概念のいくつかを挙げました-私が追加する唯一のものは、XSS脆弱性のテストの遍在性と容易さです。多くの場合、XSSは最初に教えられた脆弱性であり、SQLインジェクションの後はおそらく最も有名です。スキャンするのも簡単で、burpやw3afなどの多くのアプリケーションスキャナーはXSSを自動的に検出できます。
Xssがまだ存在する理由の概要を説明しているため、この重要性を理解してください。ほとんどすべてのサイトに、何らかのxss保護が設定されていますが、開発者が忘れていたユーザー入力を巧妙なテスターまたはスキャナーが見つけられる場合は、依然として脆弱です。 xssフリーソフトウェアを安全に開発するには、開発者は奇数のベクターを使用してペイロードを送信する攻撃者（たとえば、 HTTPヘッダー、ドロップダウンメニュー、HTTPプロキシで編集できるもの。
IMHOで最も重要なポイントは、変数（またはデータベースフィールド）に何が含まれるかを知っておく必要があることです。テキスト（およびその場合、文字セット/エンコーディング）か、HTML（または、別のタイプのデータであるHTML属性）か、SQLなどかを知っている必要があります。
次に、一方から他方に移動する必要がある場合は、適切な変換に適用する必要があります。
大きな問題は、多くの場合、テキストの一部（おそらく、操作できる最も一般的なタイプのデータ）は、テキスト、HTML、SQLなどであっても同じです（テキスト「abc」は同じです） HTML abcまたはSQL 'abc'）として、このため人々は何も変換せずにビットを連結する傾向があります。
しかし、コンテキストの1つで特別な意味を持つ文字に遭遇するとすぐに、それは壊れます。これは、セキュリティの問題（XSSとSQLの両方のインジェクション）につながるだけでなく、フォーマットの問題にもつながります（<などのHTMLエンティティが<を表示する必要があるときに、HTMLエンティティの表示を開始するすべてのサイトを目にしました）。人々は変換を忘れるか、それを何度もするので。
実際のHTMLの入力を許可する必要があることは非常にまれです。ほとんどの場合、テキストが必要です。テキストをそのままにして、そのまま操作してください。ただし、それを（HTMLページに）表示したい場合は、HTMLに変換します（標準およびテスト済みライブラリー/フレームワークを使用して、即席の正規表現ベースの検索および置換ではありません）。
同様に、SQL要求を作成するときに（できればパラメーター化されたクエリを使用して）変換します。しかし、それをそのまま正確に保管します。
多くのフレームワークは、これらを実際に使用する場合、これらすべてを「隠す」抽象化レイヤーを追加します。しかし、最高のツールを使用しても、常に誰かが自分で少しのHTMLを作成しようとすることになるので、そうした場合に何をする必要があるかを知っておく必要があります。
実際のHTMLを操作する必要がある場合は、XSSの問題に関して完全に異なる次元を入力します。 1時間でカバーできることを確認してください...
XSSは深刻です
XSSのデモンストレーションを実行して、alert('xss')を超えて、実際の影響があることを示します。
XSSは私たちに影響を与えます
いくつかの統計を提供します。過去1年間の侵入テストで、製品のXSS欠陥が17件確認されました。
ソリューションはエスケープしています
エスケープしないコードおよび脆弱なコードと、エスケープするコードの違いを示します。もう一度デモを試してみて、どのように失敗するか確認してください。
適切なコーディング方法
会社で使用されている言語とフレームワークでエスケープを実行する良い方法を示します。理想的には、自動エスケープを実行するテンプレートエンジン。会社全体で単一の言語/フレームワークを使用している場合、これは簡単です。それ以外の場合は、例を示し、使用している特定のフレームワークについて読むように伝えます。
よくある落とし穴
ページのコンテキスト。エスケープテンプレートエンジンがある場合でも、<script>タグ内の信頼できないデータによりXSSが発生する可能性があります。
信頼できないデータは何ですか？たとえば、外部サイトからRSSフィードを取得する場合、直接のユーザー入力ではありませんが、それでもXSSのリスクがあります。
DOM XSS-JavaScript evalおよびdocument.writeを使用すると、XSSが発生する可能性があります。
多層防御
CSPは優れた多層防御ですが、実装が難しい場合があります。
Cookieオプションとリクエストの検証は簡単に実装できますが、部分的な防御にすぎません。
助けを求める
ユーザーがコメントで限られたHTMLタグを使用できるようにするなど、難しいことをするときは、セキュリティ専門家に支援を求めてください。