ランダムなURLはプロフィール写真を保護する安全な方法ですか？
ユーザーIDをシーケンシャルからランダムに変更したいので、プロフィール写真を公開することができます。つまり、example.com/profilepics/asdf-1234-zxcv-7890.jpg。
リンクが付与されていないユーザーの写真を誰かが見つけられないようにするには、ユーザーIDはどのくらいの期間必要ですか？
16の小文字と0から9は、適度な複雑さを提供しますか？私はこれを36に基づいています16 = 8x1024、100億のユーザーアカウントを控えめに見積もると、スペースが8x10に減少します。14。 1000推測/秒では、アカウントを見つけるのに25000年かかります。何か見落としているのでなければ。
それはあなたが「安全」で何を意味するかに完全に依存します。
唯一の懸念が攻撃者がURLを推測することである場合、16の英数字はおよそ8,000,000,000,000,000,000,000,000の可能なアドレスを提供します。これはランダムな推測を停止するのに十分です。ユーザーは1年で、毎秒100兆回の試行を行う必要があります。これは、AmazonやGoogleのようなものでもダウンさせるのに十分なトラフィックです。
ただし、URLがリークする方法は他にもあります。URLを電子メールやブログの投稿に入れたり、Webクローラーが適切に保護しなかったページを見つけたりするなどです。本当に何かを保護する必要がある場合は、それを他のWebサイトと同じ種類のセキュリティで保護する必要があります。
個人的には、推測しにくいURLを作成するために、GUID/UUIDを使用します。検索スペースはとてつもなく巨大で、複数のサーバー間で生成を調整する必要はありません。ほとんどの言語には、それらを処理するための標準ルーチンがあります。
多分あなたの質問への答えではないかもしれませんが、あなたがウェブサイト上のあなたのプロフィール写真の場所を「隠したい」ならば、あなたは画像をデータURIとして埋め込むことができます。画像パスを公開する代わりに、サーバー上で画像をbase64エンコードしてWebサイトに文字列を埋め込むことができます。
説明とデモについては、 http://css-tricks.com/data-uris/ および http://css-tricks.com/examples/DataURIs/ を参照してください。
すでにDropboxを導入しているので、これを行うことが悪い考えである理由を少なくとも1つ挙げることができると思います。
納税申告書が最終的にGoogleに表示された後、Dropboxは古い共有リンクを無効にします
Boxにも存在するとされているこの欠陥は、ハイパーリンクを含む共有ファイルに影響を与えます。 「DropboxユーザーはDropbox内の任意のファイルまたはフォルダーへのリンクを共有できる」と同社は昨日指摘し、脆弱性を確認した。
リンクを介して共有されたファイルには、リンクを知っている人だけがアクセスできます。ただし、次のシナリオでは、ドキュメントへの共有リンクが意図しない受信者に誤って開示される可能性があります。
- Dropboxユーザーは、サードパーティのWebサイトへのハイパーリンクを含むドキュメントへのリンクを共有します。
- ユーザーまたはリンクの承認された受信者が、ドキュメント内のハイパーリンクをクリックします。
- その時点で、リファラーヘッダーは、サードパーティのWebサイトへの元の共有リンクを開示します。
- サードパーティのWebサイトのWebマスターなど、そのヘッダーへのアクセス権を持つユーザーは、共有ドキュメントへのリンクにアクセスできます。
基本的に、URLを何人のユーザーが使用しているかを考えると、URLがうっかりリークするのは簡単すぎる方法です。ユーザーがこれについて教育を受けており、これらの問題を回避している場合、それはかなり安全だと思いますが、それは大きな前提です。
他の答えは一般的には良いですが、別の考慮事項は輸送です。プレーンhttpやその他の暗号化されていないプロトコルを使用している（またはURLを電子メールで送信している）場合、これらのURLを含め、送受信するすべてのデータは、セキュリティの観点から完全に公開されていると見なす必要があります。ユーザーの大部分（統計を持っている人はいますか？）は、暗号化されていないパブリックwifiアクセスポイントにあり、そのようなネットワークのアクティブなURL /画像スクレイピングが一般的です。
他の人が述べたように、特定の画像のURIは、長さや複雑さに関係なく、遅かれ早かれリークされます。ログインしたユーザーだけに表示を制限したい場合は、たとえば.../image/profile.php?u=12345directなしでユーザー12345の画像を表示します。==一般の人に回すために利用できる写真へのURI。 （ログインしていない）ランダムな人々がprofile.phpから何も返さないと想定されています。ログインしているユーザーがその画像を保存して（特にキャッシュされている場合）、それを渡すことを妨げるものは何もないことに注意してください。キャッシュコントロールヘッダーなど、または画像をFlashに配置するなどの処理が行われる可能性がありますが、画像が他のユーザーのブラウザーで表示できる場合は、十分な作業を行うことで、画像を取得して保存できます。
あなたのスキームの問題は、URLの多数のユーザーがおそらくこれらのユーザーが機密情報を含んでいると推測しないことです。そして、その問題の一部は、ユーザーベースがどれほど大きいかまったくわからないということです。これらのURLの場合、ユーザーには次のものが含まれます
ユーザーと考える人。
ブラウザのプラグイン/アドオン/拡張機能。
サイト上のサードパーティのコンテンツ（広告、分析、ソーシャルプラグインなど）は、何らかの方法で、問題のURLをサードパーティに通知する可能性があります。
URLを参照URLと見なしている一見ランダムなWebサイト（ユーザーがブラウザーのアドオンを介してWebサイトに呼び込む奇妙な追加リンクを本当に知っていますか？）.
経験的証拠によると、パスワードに相当するものとしてアドバタイズされたhttpsのみのURLは、Googleによって繰り返しインデックスが作成されます。パスワードなしのビットコインオンラインウォレット Instawallet の場合（彼らは銀行の手に負えなくなったので、有効なSSL証明書さえ手に入らなくなったことに注意してください）。
上記の誰もが答えたようにいくつかの重要なポイントを追加すると、それらのいくつかを逃したようです。
- 人々はパスワードが機密であることを知っているので、うっかりURLを公開する可能性はパスワードを公開するよりも高いです。
- FacebookのようなWebサイトは、誰も推測できないほど複雑なCDN URLを使用しますが、セキュリティの観点からは、ユーザーがプライバシー設定を変更するとアクセスの取り消しが不可能になるため、危険であるように見えます。バックエンドにAmazon Webサービスs3ストレージを備えたWebサイトを含む一部のWebサイトは、定期的に検証されるタイムスタンプ付きの署名付きURLを使用します。
- Googleキャッシュ！検索エンジンは、おそらくプライベートな画像をクロールする可能性があります。 FacebookのCDNからの結果のみが表示されるdorksを使用して検索すると、驚くでしょう。