使いやすさとセキュリティの悪意のあるファイルのアップロード
脆弱性管理と同様の機能を持つWebアプリケーションを設計していましたが、Webアプリケーションの機能は次のように簡単に説明できます。
- 脆弱性を一覧表示するプログラムを起動できるパネルがあります
- ボブは私たちのウェブアプリケーションを通して彼のプログラムを立ち上げます
- アリスは悪意のあるファイルの脆弱性を報告します
- ボブは悪意のあるファイルを含むレポートを受け取り、ダウンロードが相対的な結果をもたらす可能性があることを示す警告を受け取ります
- ボブは悪意のあるファイルをダウンロードし、アリスの犠牲者になります
今、機能性/使いやすさに従って、私の開発者はそれを主張しています。
アプリケーションのコア機能として、悪意のあるファイルのアプリケーションへのアップロードを許可できます（アリスは概念実証として脆弱なファイルをアップロードします）
すべてのユーザーが技術に精通しているため、ユーザーが悪意のあるファイルをダウンロードするのを防ぐのに十分な警告メッセージを表示していました
今私の議論は次のとおりでした：
- 攻撃者はこのプラットフォームを使用して、対応チームをソーシャルエンジニアリングできます（ここではボブが感染します）
- 責任あるベンダーとして、クライアントは私たちを信頼し、ファイルをダウンロードします
- また、私は参照しました 無制限のファイルアップロード
したがって、上記の状況を考慮すると、クライアントが攻撃者の犠牲になるのを防ぐための最善の策は何でしょうか。
ファイルのアップロードを許可しない場合、研究者は概念実証を他の場所でホストし、リモートリソースへのリンクを提供するため、基本的に同じ問題が発生します。
一般的な方法はさまざまです。人気のあるプラットフォーム HackerOne （これはあなたが説明したサービスのほとんどを提供します）ファイルのアップロードを許可しますが、ダウンロードを提供する前に適切な警告が含まれています。一方、Googleのバグ報奨金プログラムでは、は バグレポートフォーム へのアップロードを許可していません。
いずれにせよ、応答チームはサンドボックス環境およびで動作する必要があります必要な場合にのみファイルを開きます。アップロードが「コア機能」であることに同意しません。多くの脆弱性は添付ファイルなしで、プレーンテキストとインラインコードスニペットを介して説明できますが、顧客はそうではないと思うかもしれません。
添付ファイルを安全にホストするはそれ自体のトピックですが、最も重要なことは、すべてのユーザーアップロードをWebアプリケーションとは別のサーバーに保存する必要があります。