3

私はこれについて何度も考えていて、Facebook で簡単なテストを行いました。あなたが Facebook のようなサイトを持っていて、それを画像とプロフィールに分解したとします。友達と共有するかしないかを選択した画像。明らかにDBには、メタデータが共有されているかどうか、誰と共有されているかなど、メタデータに適用される値があります。

ここで、特定の画像を表示すると、そのリソース (この例では画像) の HTTPS URL が得られたとします。その時点で、ログインしたり、何らかのトークンを取得したりしなくても、リソースを表示できます。URL を取得して任意のブラウザーにロードすると、そのリソースが表示されます。確かに、それは SSL レイヤーで提供され、かなり長くて複雑な名前を持っていますが、認証なしで表示できます。

考えずにはいられません、これができる最善のことですか?このタイプのコンテンツを保護して、直接 URL を持っている場合にそれをロードできないようにすることはできますか? より機密性の高いファイルについてはどうですか? 誰かがパスを持っている場合、そのリソースに永遠にアクセスできますか? この場合、OAuth は役に立ちますか?

これらのリソースを保護する方法について大声で考えているだけだと思います。そのため、URL に直接アクセスしても、認証されずにそのリソースを常に取得できるとは限りません。不足している可能性のある別のプロセスまたは方法はありますか? もしそうなら、パフォーマンスとセキュリティの適切なバランスとは何か、またトレードオフは何か? スケーラブルなオプションを検討したいと思います。

4

1 に答える 1

2

リソース アクセスの実装では、これは脆弱性と見なされます。ほぼすべての Web アプリは、要求されたリソースが認証および承認されたユーザーにのみ配信されるように制御できます。これが当てはまらないのは、セッション追跡を行わない単純なサーバーの場合だけです。Facebook や評判の良い Web サイトが 2013 年にこれに対して脆弱であることは非常に悲しいことです。これは 90 年代から 2000 年代初頭にかけてよく見られた脆弱性です。

ほとんどの Web アプリケーションは、何らかの形式でユーザーのセッションの状態を維持します。リソース (URL による画像など) が要求されると、セッション トークン (またはその他の方法) がチェックされ、ユーザーが認証されていること、およびユーザーがそのリソース (アクセス制御) を要求する権限を持っていることが確認されてから、リソースが返されます。 . ユーザーがチェックしない場合、リクエストは拒否されます。

于 2013-05-16T00:10:26.247 に答える