セキュリティレビュー：「HTTPヘッダーのユーザーエージェントが（何か）に設定されています」
PHPコードのセキュリティレビューが行われました。彼らのチームは（特に）レポートでこれを助言しました）：
/appdir/
Details
The HTTP header user-agent has been set to \" .
Request
GET /appdir/ HTTP/1.0
Accept: */*
User-Agent: \"
Host: localhost
Cookie: PHPSESSID=08rtvlq03bd9d57qor4abjg7q4
Connection: Close
Pragma: no-cache
Response
HTTP/1.1 200 OK
Date: Sat, 18 Dec 2010 09:35:40 GMT
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_Perl/2.0.4 Perl/v5.10.1
X-Powered-By: PHP/5.3.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
HTTPヘッダーのユーザーエージェントを\ "に設定できるかどうかは重要ですか？
user-agent（またはそのリファラー）値への注入は、いくつかの点で潜在的な脅威になる可能性がありますが、現在の状況が実際にはシステムの全体像を見ない限り、脆弱性を特定することは困難です。
何らかの方法でユーザーエージェントを使用するシステムをよく目にします。多くの場合、最も使用されているブラウザなどに関する情報を格納するために使用されます。ボットとして知られているユーザーエージェントは別の方法で扱われることがあります。多くの場合があります。
注射
ユーザーエージェントフィールドでXSS攻撃が試行されることは珍しくありません。たとえば、少し前にテストしていたサイトから、自分に関する少しの情報が得られました。
興味深いのは、ユーザーエージェントが出力されたことです。ユーザーエージェント'FooBar"> <img src="javascript:alert('document.cookie')'を挿入すると、警告が表示されました。
この攻撃を他のユーザーに利用するために、サイトには統計ページもあり、1日の平均ユーザー数、最も一般的なブラウザーなどが表示されていました。数字はリクエストの数に基づいているようです。 XSSで十分なリクエストを作成する簡単なスクリプトを作成すると、ユーザーエージェントがトップ100リストに追加され、ベクターは永続的で他のユーザーに対して機能するようになりました。
SQLインジェクションでも同じことが可能です。 useragent Im Harmless";DROP TABLE usersで実行してみてください。多分あなたはいくつかのシステムを壊します。
脆弱性の調査
例のように/ "を入力して、何が起こるかを確認します。エラーメッセージが表示されるか、サイトの他の場所で何かが発生した可能性があります。
非常に古いユーザーエージェントまたは検索エンジンのユーザーエージェントを使用するとどうなるかを確認すると、非常に役立つことがあります。これがサイトのコンテンツの一部をロック解除し、そのコンテンツの脆弱性を調査する唯一の方法である場合があります。
たとえば Burpsuite を使用することで、後者は自動化が非常に簡単で、すべての異なる要求をすばやく確認して違いを見つけることができます。
EDIT：特定の例では、リクエストを行っているクライアントがユーザーエージェントを\ "に設定しているようです。これが意図的にである場合、バグまたはユーザーエージェントを非表示にしている人を特定するのは難しいですが、私は間違いなくこのユーザーが行った他のリクエストを調べます。
エスケープされた引用符をユーザーエージェント文字列に挿入することがどのように脆弱性になるかはわかりません。
これが事実であるかどうかはわかりませんが、もっと情報が必要だと思います。私が考えられる唯一のことは、彼らがセッションハイジャックの可能性を露呈している可能性があるということです。
基本的に、PHPSESSID = 08rtvlq03bd9d57qor4abjg7q4は別のユーザーのセッションに属し、Cookieを介してこのセッションIDをスプーフィングしており、ユーザーエージェントが元のユーザーから変更されていても、通常の応答を取得しています。
明確化：
ユーザーAは、次のユーザーエージェント文字列を使用してWebサイトを開きます。
Mozilla Compatible (MSIE)
次に、ユーザーAに次のセッションIDが割り当てられます。
08rtvlq03bd9d57qor4abjg7q4
次に、ユーザーB（悪者）は、自分のCookieに同じセッションIDを持つCookieを使用してサーバーにリクエストを送信しますが、ユーザーエージェント文字列は次のとおりです。
\"
アプリケーションは、これが同じユーザーでないことを認識し、セッションを破棄する必要があります。
ユーザーエージェントは簡単にスプーフィングされているため、これが状況であるかどうかは決してわかりません。また、ユーザーエージェントを監視してセッションハイジャックを防ぐことはできませんが、ここで確認できるのはこれだけです。
彼らはあなたに価値のないものを売ろうとしています。
HTTPプロトコルでは、この種のものを使用できます。 User-Agent（別名、「どの種類のブラウザを使用していますか？」）を"User Agent: User Agent: User Agent: Trust no one"に設定できます。
ご使用のソフトウェアが最新の方法でコードインジェクション（SQL、スクリプトなど）を考慮に入れていない場合、これは問題。しかし、ベストプラクティスを使用してソフトウェアを記述し、すべての入力を正しくサニタイズし、データベースアブストラクションレイヤーを使用していますright？
セキュリティを改善する方法に関しては、Origin、リクエストの頻度、リクエストのプロファイル、ユーザーエージェントのチェック、リファラーページのチェック、すべてのチェックなどを監視することで、セキュリティを強化することができます。これが彼らにあなたに言わせようとしていたとは私は信じていません（アレックスの回答の一部として）、「これを変更できます」というだけです。これは、HTTPを十分に理解している人にとってはまったく「無理」です、しかし、おそらくいくつかの付加価値のある綿毛を怖がらせるための方法にすぎません。
したがって、PHPコードで、ユーザーエージェント文字列を含むすべての入力が適切にサニタイズされずにDBに挿入され、データベースアブストラクションレイヤーが使用できる場合、次のようになります。本当に悪い日を過ごすために。
freeのヒントをお伝えします。リファラーヘッダーは次のように設定できます。
Referrer: \' -- TRUNCATE `Users`
問題は、これらのヘッダーを設定できることではなく、アドレスフォームで「名前」と同じくらい簡単にそのデータを送信できることです。
だからここに質問があります、あなたがどこかにテーブルにいないユーザーエージェントである人々にあなたのウェブサイトを使わせないようにしたいですか？ hackerはとにかく有効なものに設定できるので、おそらく愚かな考えです。
答えは簡単です。最初にクレンジングせずに、リクエストのコンテンツにレスポンスに渡されるヘッダー値を含めないでください。そのため、最初にデータをクレンジングせずに、ユーザーが提供したデータを決して使用しないでください。常に入力をサニタイズします。
コンテンツにクライアントから渡されたヘッダー値を含めない場合は、この警告を無視できます。
ウェブサイトのセキュリティをテストするために雇われており、おそらくかなりの時間をかけて作業していた人々が、これがサイトをどのように脆弱にするのか説明できないが、セキュリティの弱点であると断言できる場合あなたのサイトでは、あなたはそれらに多くの時間と努力を無駄にしたように思えます。ペンテストを実行するためにスクリプトキディを雇ったようです。
あなたが公開した詳細にはアドバイスはありません。分析はありません。
また、「localhost」に対してテストを実行しているように見えるという事実は、彼らが何をしているのかを知らないことを示唆しています。
そして
Pragma: no-cache
ヘッダー応答では、コードを書いた人は誰でもHTTPを理解していないことを示唆しています。から rfc 2616 ：
注：「プラグマ：応答ヘッダーフィールドとしてのno-cache」の意味は実際には指定されていないため、応答内の「Cache-Control：no-cache」の信頼できる代替にはなりません。
ヘッダーフィールドを検証するように指示されている場合は、機能仕様を確認する必要があります。
機能仕様では、許容される動作を定義する必要があります。それはあなたがそれを受け入れる必要がある場合、受け入れられるものとして任意/すべてのユーザーエージェントを定義するかもしれません。ユーザーが送信したすべてのデータと同様に、ヘッダーデータは潜在的に危険であることに注意してください。