私は、クロスサイトスクリプティングに関する開発者(そのうち100人まで)の1時間のトレーニングを支援しています。それらを理解するために不可欠であると思う概念は何ですか?今私たちは持っています:
そして何よりも、脆弱性の潜在的な影響。
開発者の観点から見ると、最初の2つのポイントはあまり関係ありません。保存されたXSSとリフレクトされたXSSは同じ緩和策を備えています。つまり、出力するものをコンテキストに応じて適切にエスケープします。防御層は、この緩和策を適切に実装していない場合の言い訳としてのみ見なされる可能性があります。「WAFは私にそれをキャッチします。」
代わりに、これらのコードの衛生習慣に焦点を合わせてください。
jsstringsafeEmail
、htmlattrsafeColor
、htmltextsafeFullName
など。それらを理解するために不可欠であると思う概念は何ですか?
ほかに何か?リストから欠落している大きなことは、これらの潜在的な脆弱性を軽減するためにすべて使用できる非常に多くのツールとテクニックがあることです。多層防御は、可能な限りそれらを使用することを示唆しています。
基本のほとんどをカバーしました。あなたのポイントを少し拡張するために(これらのいくつかはここでほとんどの読者に明白に見えるでしょうが、必ずしもすべての開発者に明白であるとは限らないかもしれません):
しかし、私の意見で最も重要な点:HTMLエンコーディングはデフォルトで行われる必要があります、デフォルトですべてのパラメーターをエンコードするテンプレートエンジンを使用することによって。
エンコーディングが至る所で発生する場合、一度だけ忘れることは簡単です。もちろん、HTMLエンコーディングでは不十分なすべての状況に対処することは依然として重要ですが、ほとんどのXSS脆弱性はデフォルトのエンコーディングによって防止されます。
教えるべき最も重要な2つの教訓は次のとおりです。
私の最初のポイント:ほぼすべてのインジェクションの問題は、間違ったレベルの抽象化での作業から発生します:プログラマーは、より高い値を使用する必要がある状況で文字列を連結しています正しい方法から抽象化するレベルレベルの操作。これは次のことを意味します。
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タグを使用できるようにするなど、難しいことをするときは、セキュリティ専門家に支援を求めてください。