web-dev-qa-db-ja.com

脆弱なフレームワークとIISサーバーのバージョンがサードパーティアプリケーションのエラーページに表示される

私はセキュリティテスターとして、サードパーティアプリケーションのセキュリティ設定の誤りが私たちにとってリスクであることを報告し、正当化する必要があります。

以下はシナリオです。

1.）顧客がアプリケーションを提出するために使用するサードパーティのアプリケーションがあります。サードパーティのアプリケーションからデータを受け取り、さらに処理します。

2.）その特定のアプリケーションでは、ハイパーリンクをクリックすると、次の情報を含むエラーページが表示されます。

a) Source file path (however it is forbidden when tried to access)
b) .Net framework version which is vulnerable ASP.Net Forms Authentication Bypass
c) IIS server version (7.5) which has exploits as per my knowledge.

この構成ミスのリスクは何ですか？それを正当化する方法は？

注：このエラーページは、ユーザーがログインした後にのみ表示されます。これは、公開アプリケーションです。

penetration-testasp.netiisvulnerability-assessment
5
Sai Dutt Mekala

ソースファイルのパスは必ずしも問題ではありません。ただし、これは悪い習慣であり、他の問題の悪用に役立つ可能性のある情報を漏らします。

IISサーバーバージョン（7.5）。私の知る限りではエクスプロイトがあります。

IIS 7.5は2020年まで拡張サポートの対象です。つまり、セキュリティ更新プログラムを受け取る必要があるため、これは必ずしも問題ではありません。サードパーティにパッチ履歴をリクエストする必要があります。

脆弱なASP.Netフォーム認証バイパスである.Netフレームワークバージョン

再び これはパッチされました 。バージョン番号だけでは何も意味しません。

この構成ミスのリスクは何ですか？それを正当化する方法は？

クライアントはあなたに正確に何を提出しますか？ある場合、アプリケーションの実行可能ファイルは公開されていますか？それともサーバー側のアプリケーションですか？そして、彼らは署名されていますか？

私が見ることができる最大のセキュリティリスクは、誰かがアプリケーションの欠陥を自分自身に提出する前にパッチを当てたかどうかです。したがって、クライアントには脆弱性があり、それをクライアントに認識させることはできません。

1
Hector

セキュリティのベストプラクティスとして、システムに関する情報をパブリック/正当なユーザーに漏らさないことが常に推奨されます。

ハッカーがこの情報を使用してシステム/アプリケーションの穴を見つけることができる可能性があるため、これはセキュリティ違反につながる可能性があります。

たとえば、IIS 7.5には多くの脆弱性があります。参照してください https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3436/version_id- 92758/Microsoft-IIS-7.5.html 。

ASP.NETにはいくつかの脆弱性があります。 https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3091/Microsoft-Asp.net.html を参照してください。

したがって、システムのバックエンド情報を保護することは常に推奨されます。

0
Sayan