web-dev-qa-db-ja.com

URLパラメータの操作と注入

2つのサイトのシナリオがあります。サイト1はmysite.comで、サイト2はsecondurl.comです。

サイト1はWordpressを使用しています。そこで、与えられたurlパラメータが入ってくるかどうかをチェックするJavascrit/jQueryルーチンを実行しました。クエリ文字列にパラメータ "p"が存在する場合、サイト2を指す私のホームページのすべてのURLを置き換えます。これは、次のように、クエリ文字列を介して取得した値を提供します。

<a href="secondurl.com">Link </a>

に

<a href="secondurl.com?p=value">Link </a>

前に述べたように、「値」は、サイト1にアクセスしたときにクエリ文字列を介して得られるものです。お気に入り：

mysite.com?p=123

クエリ文字列は扱いません。pの値を取得し、そのパラメーターを使用して2番目のURLを生成します。両方のサイトは同じサーバー上にあり、サイト1はwordpressおよびサイト2の純粋なPHPを使用しています。

JQueryを使用してこのURLを置き換えると、両方のサイトを持つサーバーに脆弱性が生じますか？はいの場合、誰かがその脆弱性を使用して私のサーバーにpythonまたはphpスクリプトを置く可能性がありますか？

phpjavascriptinjectionpythonwordpress
4
churros

tl/dr：反映されたXSSの脆弱性があるかどうかは、データを追加するために使用する正確な方法によって異なります。したがって、選択した方法を具体的にチェックして、安全であることを確認する必要があります。最新のJavaScriptフレームワークは通常、これらのことを自動的に処理しますが、jQueryは処理しません。そのため、詳細に注意することが重要です。

特に、サイト1とサイト2の相互作用について心配する必要はありません。理由は、サイト2は、とにかくすべての通常の方法（準備されたクエリなどを使用）で安全である必要があるためです。悪意のあるユーザーは、サイト1を使用してサイト2を攻撃することはありません（この場合）。攻撃したい場合は、サイト2を直接攻撃することができるからです。

したがって、ここでの主な問題は、サイト1が脆弱かどうかです。明確にするために、懸念は反射されたXSS攻撃の可能性にあります（これはExecutionByForkが回答で言及しているものです）。簡単な例を挙げると、ユーザーがこのURLにアクセスするとどうなりますか。

_http://mysite.com?p="><script>alert(1)</script>
_

pパラメータを他のすべてのリンクに追加する方法で、そのコンテンツが暗黙的にHTMLとして扱われる場合、実際のscriptタグがページに挿入され、従来の方法で攻撃者のJavaScriptが実行されます 反射されたXSS攻撃 。

したがって、問題は、データをHTMLとして扱う可能性のある方法でpパラメータを追加する（脆弱性を作成する）か、それとも安全な方法で追加するかです。その質問に対する答えは、データを追加するために使用する特定の方法に帰着します。 2つの例を挙げましょう。

非常に安全：.prop（）

JQuery _.prop_メソッドの使用は、対応するDOMノードのプロパティの設定に依存するため安全です。このようにすることで、プロパティコンテキストをエスケープする機会がなくなります。本質的に、_.prop_メソッドに送信するものはすべて、文字列としてのみ処理され、実行の機会はありません。したがって、このようなコードは、反映されたXSS攻撃から安全ですis：

_var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))
_

ただしこれは、ユーザーが最後のhrefを完全に制御できる場合は安全ではありません（たとえば、追加しなかった場合、代わりに、ユーザー入力のみに基づいてhrefを設定します）。その場合、ユーザーは次のようにリンクを切り替えてJavaScriptを実行できます。

_http://mysite.com?p=javascript:alert(1)
_

これにより、次のようなコードの脆弱性が発生します。

_link.prop('href', injected_data))
_

すでにそこにあるものにデータを追加している限り、これは不可能です。ただし、hrefタグが以前は空だった場合は、脆弱性が発生する可能性があります（ページをロードするだけでなく、ユーザーがリンクをクリックした場合にのみ起動します）。

もちろん、これでも安全性は保証されません。潜在的に悪意のあるデータがアプリケーション内に隠れて問題を引き起こしているためです。 hrefにユーザーデータが含まれていることを忘れている可能性があります。他のJavaScriptがリンクからhrefを取得し、それを使用して何かを行おうとすると、問題が発生する可能性があります。また、この悪意のあるデータは誰かがリンクをクリックしたときにサイト2に渡されるため、サイト2自体を適切に保護する必要があることに注意してください（とにかくこれは真実でしたので、まだ知らないことはありません）。

安全ではありません：.replaceWith（）

ただし、他の多くのJavaScriptメソッドでは、文字列をHTMLとして扱うことができるため、XSSが反映されます。実際、安全な方法よりも危険な方法がおそらくあるので、使用している方法が実際に安全かどうかを確認する必要があります。それでも、例を示すために、.replaceWith()は文字列をHTMLとして評価します。したがって、このようなものは危険です：

_link = $('a').first();
old_href = link.prop('href');
link.replaceWith('<a href="' + old_href + '?p=' + injected_data + '">click here</a>');
_
5
Conor Mancone

Webサイトは reflected XSS attack に対して脆弱である可能性があります（値の設定方法とデータの解釈方法によって異なります）。たとえば、次のURLにアクセスするとします。

_mysite.com?p="></a><script>malicious_code()</script><a href="
_

あなたのサイトがこれを変換する場合：

_<a href="secondurl.com">Link </a>
_

これに：

_<a href="secondurl.com?p="></a><script>malicious_code()</script><a href="">Link </a>
_

そして、ユーザーのブラウザーが更新されたHTMLを解析すると、malicious_code()がブラウザーですぐに実行されます。これはnotがXSSを実行する唯一の方法であることに注意してください。最終的には、サイトがユーザーデータを取得してhref属性に追加する方法に依存するため、この特定のシナリオで_<script>_タグが機能しない場合でも、他の方法で簡単に実行できます。例として OWASPのXSSフィルター回避チートシート を見てください。

これが、後でコードとして解釈されるデータに含まれる場合、ユーザーからのデータalwaysを確実にサニタイズすることが重要な理由です。ユーザー入力が指示として利用されていない場合は、通常、そのデータを無害化しない方が安全です。ただし、注入は下流のどこでも発生する可能性があることに注意してください。ユーザーから直接取得されていないデータはサニタイズされない可能性があるため、忘れがちです。

これによりサーバーが危険にさらされる可能性はありますか？直接ではありませんが、パッチを適用する必要のある大きなセキュリティホールです。 XSSを使用して、攻撃者はyouリンクを送信してyourマシンでJavaScriptを実行する可能性があります。あなたがたまたまログインしている場合、彼らはセッションCookieを盗み、それを使用してwordpressサイトに本人であるかのようにアクセスします。これにより、通常の管理パネルにアクセスできます。アクセス権があり、そこから特権をエスカレートできます。

注：もう1つ考慮すべきことは、_secondurl.com_に渡されるパラメーターをどのように使用するかです。これは、最終的にユーザーによって制御されるため、サイトへのアクセスを許可する可能性のあるもう1つのベクトルです。

4
ExecutionByFork