web-dev-qa-db-ja.com

APIコンシューマーがデータベースに保存されている主キーを決定できるようにすることのセキュリティ上の意味は何ですか？

物語

HTTP PUTを使用してエンドポイント経由でデータベースに保存されたオブジェクトを作成または変更（つまり、アップサート）できるようにするAPIを開発しています。

この方法で格納されたオブジェクトの主キーは、将来の競合の可能性を防ぐために、自動インクリメント番号の代わりにGUIDであり、GUID =オブジェクトの作成中と変更中の両方のシナリオで、APIコンシューマーによって提供される必要があります。

このアプローチの利点により、作成または変更を区別することなく、オブジェクトを格納する意図に集中できることが通知されます。

質問

この場合、APIコンシューマがGUID=をオブジェクト識別子として渡すことを期待しています。また、格納されているオブジェクトの主キーを他の誰かが決定できるようにすると、セキュリティ面で何が問題になるのでしょうか？

私は提供されたGUIDを候補キーとして扱い、別の一意の識別子を内部的に生成することを理解しているかもしれませんが、冗長で、それがもっともらしいアプローチかどうか疑問に思っています。

httpdatabasesapisecurity-by-design
3
Zephyr

場合によります。

オブジェクトは秘密です

これらのGUID=と見なされるデータがsecretと見なされる場合、ユーザーが同じGUIDを共有することは望ましくありません。そのため、別の識別子を含める必要があります。主キーで、各顧客が独自のGUIDのセットを持っていることを確認します。つまり、Conorがコメントで述べたように、すべてのユーザーがGUID 12345と顧客は、別の顧客がGUID 12345。

顧客IDをGUIDに追加して、顧客ごとにオブジェクトを識別することにより、これを簡単に行うことができます。

この場合、データは秘密なので、ユーザーを識別する方法も含めることに注意してください。ユーザーがログインしたときにユーザーに与えられた文字列のような長いUUID、またはユーザーの資格情報（ユーザーのサーバーだけがサーバーにアクセスする場合にのみ機能します）。

オブジェクトはパブリックです

オブジェクトがいずれにせよパブリックである場合、実際のセキュリティ問題はありません。ただし、クラッシュが原因でアップロードが失敗した場合、クライアントは新しいGUIDを生成します。

現在、GUIDは一意でなければならないので、衝突の可能性は最小限に抑えられています。ハッカーがオブジェクトを見つけようとしているため、ハッカーが存在することを知らないはずです。

ただし、データは公開されているため、ハッカーがそれを見つけても大したことではありません。何らかの方法で利用できます...

識別子

インクリメントされる識別子のアイデアは多く使用されており、それはまだ多く使用されています。

識別子が参照するデータが公開されている場合、このように番号を1つずつ増やすことは重要ではありません。

ただし、いくらか秘密にしておくべきものは、そのような番号を使用しないでください。これは、ハッカーが次のようなURLを使用してすべてのオブジェクトを簡単にチェックできるためです。

http://example.com/user/1
http://example.com/user/2
http://example.com/user/3
   ...
http://example.com/user/n

これで、ハッカーがすべてのユーザーを見つけることができることがわかります。ユーザーのアカウントが公開されている場合、ユーザーは自分の名前を確認でき、その名前を使用して、ランダムなパスワードでログインを試みることができます。したがって、攻撃のベクトルはsimplifiedです。

作成と変更

はい。このメカニズムは、多くのシステム、特にNoSQLの世界で使用されています。たとえば、Cassandraを使用すると、INSERTまたはUPDATEを使用してコンテンツを作成または変更できます。

Cassandraには、PRIMARY KEYと呼ばれる列が1つあります（SQLの場合と同様に、列を複数にすることはできません）。そのPRIMARY KEYは、データのインデックス付けに使用されます。これは、あなたのGUIDと同じですが、バイナリデータを含め、絶対に何でも可能です。

2
Alexis Wilke