19

内部 ID を外部に公開してはいけないと言う人が何人かいるのを聞いたことがあります (たとえば、auto_increment'ng プライマリ キー)。

ルックアップの代わりに使用するある種の uuid 列を持つことを提案する人もいます。

なぜこれが提案されるのか、それが本当に重要なのか、本当に疑問に思っています.

代わりに uuid を使用すると、基本的に ID が難読化されます。ポイントは何ですか？私が考えることができる唯一のことは、auto_incrementing 整数が明らかに私の db オブジェクトの順序を示しているということです。あるものが別のものの前後に作成されたことを外部のユーザーが知っているかどうかは重要ですか?

それとも、ID を難読化することで、特定のオブジェクトに対するさまざまな操作での「推測」を防ぐことができるのでしょうか?

これは、外部向けの API を設計するときに考えるべき問題ですか?

4

3 に答える 3

14

内部の自動インクリメント ID を公開したくない別の理由を追加します。
競争力のある企業として、毎週/日/時間に獲得する新規ユーザー/注文/その他の数を簡単に測定できます。ユーザーや注文を作成し、前回取得したものから新しい ID を差し引くだけです。
したがって、セキュリティ上の理由だけでなく、ビジネス上の理由もあります。

于 2016-03-01T11:34:39.007 に答える
9

アプリケーションとそのレイアウトに関して悪意のあるユーザーに提供する情報はすべて、アプリケーションに対して使用される可能性があり、使用されることになります。(Web) アプリケーションのセキュリティで私たちが直面する問題の 1 つは、プロジェクトの初期段階では無害に見える設計上の決定が、プロジェクトが大きくなるとアキレス腱になることです。攻撃者がエンティティの順序について十分な情報に基づいて推測できるようにすると、次のようにやや無関係な方法で悩まされる可能性があります。

  1. エンティティの ID は、アプリケーションのある時点で必然的にパラメーターとして渡されます。これにより、ハッカーは最終的に、通常はアクセスできないアプリケーションの引数にフィードできるようになります。私は個人的に (非常に人気のある小売業者のサイトで) 注文の詳細を表示することができました。私は自分の正当な注文からアプリに連番を入力しただけです。

  2. 主キー フィールド値の限界または少なくとも進行を知ることは、SQL インジェクション攻撃の非常に貴重な餌食となりますが、その範囲についてはここでは説明しません。

  3. キー値は、RDBMS システムだけでなく、他のキーと値のマッピング システムでも使用されます。JSESSION_ID Cookie の順序を事前に決定または推測できるとしたらどうでしょうか。反対側の親指を持つ人は誰でも、Web アプリでセッションを再生します。

そして、ここにいる他の人々が思いつくと確信している多くのこと。

SEAL チーム 6 は、必ずしも 6 つのアザラシ チームが存在することを意味するわけではありません。敵を推測させ続けるだけです。そして、潜在的な攻撃者が推測に費やす時間は、どのように切り分けても、より多くのお金をポケットに入れます。

于 2012-09-12T07:10:29.567 に答える
6

多くのセキュリティ関連の問題と同様に、それは微妙な答えです.kolossus は良い概要を提供します.

攻撃者が API をどのように侵害する可能性があるか、およびセキュリティ違反がいくつ発生するかを理解するのに役立ちます。

ほとんどのセキュリティ侵害はバグや見落としが原因であり、攻撃者はそれらを探します。API を危険にさらそうとする攻撃者は、まず API に関する情報を収集しようとします。これは API であるため、おそらく詳細な使用方法のドキュメントを公開しているはずです。攻撃者はこのドキュメントを使用して、さまざまな方法でサイトをクラッシュさせたり (運がよければ、より多くの情報を公開したり)、予期しない方法で反応したりします。

攻撃者には十分な時間があり、あらゆる手段を試すように攻撃をスクリプト化するものと想定する必要があります。時間に制限がない泥棒が家中を歩き回り、すべてのドアと窓を試し、すべての試みから学習するロック ピックを使用するように。

したがって、API が のようなメソッドを公開し、getUserInfo(userid)userID が整数である場合、攻撃者はスクリプトを作成して 0 から上に向かって反復し、何人のユーザーがいるかを調べます。彼らは負の数を試しますmax(INT) + 1. これらすべてのケースでアプリケーションから情報が漏洩する可能性があり、開発者が特定のエラーを処理するのを忘れた場合は、意図したよりも多くのデータが公開される可能性があります。

API に特定のデータへのアクセスを制限するロジックが含まれている場合 (たとえば、フレンド リスト内のユーザーに対して実行が許可されているgetUserInfo場合)、攻撃者はバグや見落としのためにいくつかの数字で幸運に恵まれる可能性があり、攻撃者はその情報が彼は有効なユーザーに関連付けられているため、アプリケーションの設計方法のモデルを構築できます。これは、すべてのロックが 1 つのメーカーのものであることを知っている泥棒と同じです。

これ自体は、攻撃者にとって何の利点もないかもしれませんが、攻撃者の生活を少しだけ楽にしてくれます。

UUID やその他の無意味な識別子を使用する努力を考えると、攻撃者にとって物事を難しくする価値があると思われます。もちろん、これは最も重要な考慮事項ではありません。おそらく、攻撃者から API を保護するためにすべきことのトップ 5 にはなりませんが、役に立ちます。

于 2012-09-12T09:08:57.563 に答える