私が使用するサービスは、セキュリティ上の理由から、UserAgentを提供しないHTTPリクエストをブロックすることにしました。
私の知る限り、UserAgentは、主に統計情報に使用される標準形式のない文字列であり、さまざまなページバージョン(モバイルなど)を提供し、ボットをブロックします。 RFCは、送信する必要がある(必須ではない)と述べています。
Shellshockがuseragent文字列で機能する理由 は、悪意のあるUserAgentが作成される可能性があることを示していますが、サービスはUserAgentなしでリクエストをブロックしています。
知らないUserAgentヘッダーに脆弱性はありますか?
いや、あなたの理解は正しいようです。ほとんどすべてのWebブラウザー(および他のほとんどのHTTPクライアント)はユーザーエージェント文字列を送信するため、間違いなく、リクエストなしで到着する要求はかなり大雑把に見えます。一方、それを送信するのには基本的に何もかかりません(たとえば、curl
を使用する場合は、-A引数を使用します)。真実との関係は保証されません。ブラウザーを含むほとんどのクライアントでは、ユーザー(ユーザー)が望むとおりにUA文字列を偽装できます。
もちろん、サーバーにIE 5をWindows CEで実行していることを伝えると、本当にひどいひどいHTML/JSが返される可能性があります-多くのWebサーバーはUA文字列を使用して異なるバージョンを送信しますリクエストを行うブラウザの期待される機能に基づいたWebページの数-しかし、それはサーバーの問題ではなく、あなたの問題です。UA文字列をまったく送信しない場合も同様です。
セキュリティ面では、UAなしまたは信頼できないUAで要求をブロックすることにより、攻撃者の方法にスピードバンプを置くことができますが、攻撃者がしなければならないことは、たとえば=の現在のバージョンのUAを偽るだけです。 Chrome(これは見つけやすく、使いやすい)スピードバンプにすぎません。迂回するのは簡単なので、多層防御とは言いません。
あなたのサービスプロバイダーは本当にセキュリティを侵害しておらず、私が「正当なユーザーなし」という誤解に陥っていると思います(「真のスコッツマンなし」と混同しないでください)。それは次のようになります。「OK、つまりユーザーが[Xを実行する]とセキュリティ上の脅威がありますか。まあ、正当なユーザーがそうすることはないので、私たちは安全です。」この場合、[does X]は「クライアントのUA文字列をスプーフする」ようです。多くの人々は、攻撃者が悪用されるまで違いを確実に見分けられないほど、攻撃者が正当なユーザーになりすますことができることを理解していません。
まあ、それとも、彼らはUA文字列がほとんど意味がなく、簡単に編集できることを認識していません。