web-dev-qa-db-ja.com

ランダムURLトークンは、添付ファイルやその他のユーザーコンテンツに対して十分に安全ですか？

たとえば、さまざまなファイルがユーザーによって追加され、機密性の高い架空のシステムがあるとします。プライベートメッセージの添付ファイルを言ってみましょう。添付ファイルは複数のオブジェクトなどに追加できるため、通常は（実装の観点から）アクセス権を確認するのは簡単ではありません。それを実装する一般的な方法は次のようなものです。

mysite/file？id = DFD -... FDFD

使用されるIDは、secure PRNG（GUIDではない）を使用して生成されており、事実上推測できないとしましょう。適切なセキュリティを提供するか、URLが公開されるリスクは、かなり高い？

考えられる問題には、これらのURLを公開しているユーザーが含まれるため、推測できないURLを使用しても、添付ファイルに機密データが含まれている場合は安全とは言えませんが、セキュリティの専門家の考えを知ることは興味深いことです。

追伸私はこれを発見しました [〜＃〜] url [〜＃〜] この露出が実際のケースであるgithubで。開発者は、URLが保護され、公共の場所で公開されていると考えていましたが、そうではないようです。

web-applicationcryptographyfile-accessurl
4
Ilya Chernomordik

それは確かにある程度のセキュリティを提供しますが、それでも、開発しているアプリケーションのタイプに依存するかどうかに関係なく、多くのセキュリティホールを残します。完全ではないリストの場合：

  • コンテンツを特定のユーザーグループに限定することを意図している可能性があります。

  • GETパラメータを含むURLは、多数の場所に保存されます-たとえば、ウェブ履歴

  • instawallet fiasco など、Googleが意図しないものをクロールするときに、大きな問題が発生することがあります。
  • サイトの他の場所にあるセキュリティの脆弱性によりリンクが公開される可能性があり、追加のセキュリティがなければ公開されます。

私があなたなら、ファイルにアクセスできる可能性のある特定の人/グループにファイルを結び付け、コンテンツを提供する前にセッションを確認することで、追加のセキュリティを実装したいと思います。

5
William Dunne

ファイルへのアクセスを提供するためのシークレットとして長いランダムトークンを使用すると、効果的なセキュリティを提供できます。ランダムに推測できる範囲から完全に外れるようにするには、128ビット以上をお勧めします。特に悪い推測に基づいてIPをレート制限する場合は、ビット数を減らして問題を回避できる可能性があります。たとえば、64ビットまたは80ビットのトークンと10億のファイルがあり、それぞれが10分ごとに10回の推測を試行できる100万の異なるIPアドレスを持つボットネットに攻撃された場合、IPを10分間禁止したとします。 10回の誤った試行の後、単一のランダムファイルを見つけるのに約12日（64ビットトークン）または2300年（80ビットトークン）かかります。

ただし、これを安全な方法で行うには、いくつかの注意点に留意する必要があります。

  1. HTTPSを使用します。ネットワーク盗聴者は、HTTP経由のトラフィックを確認（または密かに変更）できます。
  2. ドキュメントに他のWebページへのリンクがあり、ユーザーがそのリンクをクリックした場合、反対側のWebサーバーは通常、HTTPリクエストにHTTP Refererヘッダーを表示し、完全なURL（シークレットを含む）を提供します。これは、シークレットが https://www.google.com?q=secret のようなクエリパラメータにある場合でも発生し、ユーザーがプライベートブラウジングモードの場合にも発生します。
  3. ランダムトークンは、おそらくコンピューターブラウザーの履歴に保存されている可能性があります（プライベートモードで参照してセッションを終了しない限り）。
  4. 一部の検索エンジンは、ランダムトークンを取得してインデックスを作成します。
  5. キーをユーザーに通知するメカニズムは、キーを第三者に漏らす可能性があります。電子メールは暗号化されずに交換される可能性があり、サードパーティの電子メールプロバイダーを使用している場合、その電子メールプロバイダーの管理者は秘密鍵にアクセスできます。多くのユーザーは、暗号化されていないディスクを使用してプレーンテキストの電子メールをコンピューターに保存する（たとえば、ハードドライブを取り外したり、誰かがライブCDを起動してディスクの内容を読み取ったりする）か、コンピューターを電子メールアカウントにログインしたままにします。

問題4は通常、robots.txtを維持し、ディレクトリを禁止することで回避できます。

User-Agent: *
Disallow: /private/

HTTPでドキュメントをリクエストするようユーザーに要求することで、問題2と3を軽減できますPOST（HTTPS経由）。次のようなリンクをクリックする代わりに：

<a href="https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw">File</a>

次のようにHTMLメールに埋め込むことができます。

<p> Click the button below to get your file:
<form action="https://example.com/private_file/" method="post">
  <input type="hidden" name="token" value="LfliQdgOAkjs9H0Oi5ZZcw">
  <input type="submit" value="Get File">
</form>
<p>Or go to https://example.com/private_file/ and cut and paste the token <pre>LfliQdgOAkjs9H0Oi5ZZcw</pre>.

これにより、シークレットがブラウザの履歴に表示されなかったり、リファラーリンクを受信できなくなります（URLは単にhttps://example.com/private_file/になるため）。

または、https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw形式のリンクを許可し、実際にプライベートhttps://example.com/private/documentを提供するときにユーザーを別のURLにリダイレクトすることもできます。これにより、Refererヘッダーの問題＃2が防止されますが、ブラウザーの履歴にリンクが残る場合があります。

2
dr jimbob

この種の質問はときどき出てきます。

本質的に、これはobscurityによるセキュリティです。

推測するのが難しいという事実は、1つのタイプの問題だけに対処します。それはに対して保護しません：

  • ユーザーが誤ってリンクを共有したり、リンクにブックマークを付けたりした。
  • ユーザーが誤ってGoogleまたは別の検索エンジンにURLを入力したため、インデックスに登録されました。
  • 外部監視またはネットワークトラフィックの傍受、キャッシング

あなたはこれに興味があるかもしれません DropBoxと同様の例 数年前のもの：

この脆弱性は、Google AdWordsキャンペーンのクラウドベースのファイルロッカーイントラリンクによって発見されました。このサービスでは、競合他社（この場合はBoxとDropbox）を識別するキーワードを使用してサービスが宣伝されています。この脆弱性は、ユーザーが共有リンクを介してファイルを共有し、その後ブラウザーの（URLバーではなく）検索ボックスに挿入される場合に存在します。これにより、イントラリンクスはAdWordsキャンペーン管理インターフェースでデータを収集できました。

同様に、Dropboxがこのシナリオ例で概説しているように、ユーザーはHTTPリファラーヘッダーのリレーを含むわずかに異なる攻撃に対して脆弱です。

Dropboxユーザーは、サードパーティのWebサイトへのハイパーリンクを含むドキュメントへのリンクを共有します。ユーザーまたはリンクの承認された受信者が、ドキュメント内のハイパーリンクをクリックします。その時点で、リファラー[sic]ヘッダーは、サードパーティのWebサイトへの元の共有リンクを開示します。サードパーティのWebサイトのWebマスターなど、そのヘッダーへのアクセス権を持つユーザーは、共有ドキュメントへのリンクにアクセスできます。同じ投稿で、Dropboxは検索ボックスの問題は「よく知られており、脆弱性とは考えていない」と述べています。結局のところ、共有ファイルの唯一の保護は、アクセスが困難であり、アクセスに非常に長いURLを必要とすることです。つまり、あいまいさによるセキュリティです。

金庫の前に写真を置くことは、金庫をロックすることと同じではありません...

実際の認証の実装を回避しようとしているようです。実際のアクセス制御（認証と承認）だけでなく、情報の権利管理などの実装を検討する必要がある場合があります。

少なくとも、アクセスを提供する前にファイルがゲートウェイとしてロードされるときに、コード、トークン、またはIDを要求することができます。たとえば、リンクをメールで送信すると、メールを再度入力した場合にのみ、実際のファイルにアクセスできます。偶発的なインデックス作成からある程度の保護を提供しますが、他のケースでは提供しません。

1
Eric G