APIに乱数を用いることによるセキュリティー上のメリットについて

Question

こちら記事を読んでいた際に疑問な箇所があり質問させて頂ました。
テーブルのIDカラムに乱数を用いるメリットとして、以下のように説明がありました

このようにitemのIDの値が整数の場合、値の予測が簡単であるため、外部からの攻撃を受けやすくなります。

しかし、そもそもURLのパラメーターには機密情報を含めることはセキュリティ上ないと思う為、こちら何故問題なのかが分からない状況です。
どなたか、こちらの疑問点につきまして、ご助言頂けましたら幸いです

Answer 1

質問者さんの感覚は正しいと思います。仮に秘密情報で他の人が見てはいけないものであれば、IDのランダム化ではなく、認可制御として実装すべきものです。

また、脆弱性を作り込みにくくする際に重要なこととして、シンプルさを保つことは重要です。「こちらの方がちょっと安全になる」からといって、ソフトウェアを複雑にしてしまうと、バグが増える要因になりますし、ひいては脆弱性の原因になります。

そもそも、一連番号のIDを避けるべきなのであれば、DjangoやRuby on Railsがはじめからそのように実装されているはず（べき）です。DjangoやRailsのようにメジャーなフレームワークがバージョンを重ねても一連番号のIDを用いていることは、世界中の多くで「それで差し支えない」と認められている証拠です。

なので、セキュリティ要件を満たしている限り、フレームワークは「あるがままに」使うことをおすすめします。

以下の記事は、「デフォルトをさらに安全にしようとしたら致命的な脆弱性が混入した」例です。このようなケースを私は多く見てきました。シンプルさを保つということはとても重要です。

bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点 | 徳丸浩の日記

Comments

[jjj001]

ご回答ありがとうございます。
例えばなのですが、RESTfulなAPIのケースでは、リソースを特定する識別子がURLの一部となるために、攻撃者が推測されにくいUUID形式にしておくことで、多少のセキュリティの向上が見込まれる、ということはありますでしょうかね...?

[ockeghem]

認可制御不備の脆弱性は割とあるものなので、その際に被害緩和として働く可能性は十分考えられます。

[jjj001]

ありがとうございます。
> 被害緩和として働く可能性は十分考えられます。
UUIDを使用するか否かで迷っていたので、大変参考になりました。

Answer 2

URLに含めるかどうかは関係ありません。
IDなどのAPIのパラメータ値はクライアント側に秘匿することはできません。

それが仮に1からの連番のようなものであれば「次」は2であると容易に推測できます。
そこで例えば攻撃者は値を2としたリクエストを送り、2に紐づいた結果を得ることができるかもしれません。
これを推測しにくいUUIDにすることで、このような攻撃に強くなります。

参考：Webアプリケーションのセキュリティ

推奨：ユーザIDをシーケンシャルに生成しない。

ユーザIDが連番になっていると、別ユーザのユーザIDを容易に推測可能なので、たとえばリバースブルートフォース攻撃によりアカウントを奪われる可能性が高まります。

なお、いわゆるIDをUUID化すべきかはケースバイケースでしょう。
たとえばユーザーIDなどはそうすべきでしょうが、都道府県IDのような推測されても問題ないものはその必要はないでしょう。

追記

同じような質問が見つかったので提示しておきます。
Django 2.x: Is using the Primary Key of a Model in the URL pattern a security concern?

おおむね、IDが連番であることによるセキュリティ上の懸念は考えられるが
そもそもそのIDが指すモノに対する取得、閲覧、変更などの認可制御を適切に処理する仕組みがあるのでそれを使うべき。

といった回答がついています。

また安全なウェブサイトの作り方の1.11 アクセス制御や認可制御の欠落にも同様な記載がされていました。

これも、認可制御が実装されていないために生じる脆弱性です。データベースを検索するための注

文番号が、ログイン中の利用者に閲覧を許可された番号であるかどうかを常に確認するように実装し
てください。

UUID化のメリットとしては「他のIDの推測を回避できる」点くらいです。
よってコピーサイトの作成などを目的としたデータの一括取得対策にはなるでしょう。
ただしIDの指すモノに対するセキュリティはシステムで用意された認可制御を用いるべきです。

Comments

[jjj001]

ご回答ありがとうございます。
>それが仮に1からの連番のようなものであれば「次」は2であると容易に推測できます。
そこで例えば攻撃者は値を2としたリクエストを送り、2に紐づいた結果を得ることができるかもしれません。
こちらなのですが、例えば、会員登録サイトなどではそもそも認証が必要な為、他のユーザーの情報を知ることは出来ない上、会員登録サイトでなかった場合は、そもそも公開しているデータな為、知られたとしても問題がないのではないかと思うのですが、ちょっと見当違いのこと言ってしまっていますでしょうかね...?

[8524ba23]

要するにID（の規則性も含めて）がバレてもよい類のものであればUUID化する必要はありません。
しかしたとえば会員のログイン（認証）時点でユーザーIDとパスワードなりを求められるケースにおいて
IDが連番であれば、順番にパスワード固定「123456」なりのブルートフォース攻撃が成功する可能性があります。

[8524ba23]

たとえば食○ログのような口コミサイトの公開されたAPIにおいて、店舗を識別するIDについて考えてみてください。
API（店舗検索）では、指定された住所やジャンルからその条件に合致した店舗IDの一覧を取得できるものとします。
API（店舗詳細）では、指定された店舗IDの店舗の詳細を得られるものとします。
この店舗IDはUUID化すべきでしょうか？私ならUUID化します。

[jjj001]

度々ご説明頂き、ありがとうございます。
>この店舗IDはUUID化すべきでしょうか？私ならUUID化します
こちらですが、APIを利用する開発者側の立場としましては、UUID化されていた方が良いと思いました。
理由としましては、連番だと間違えて違うIDを指定しまい、目的の店舗の店舗詳細が得られない可能性があると思ったからです。
ですが、脆弱性が潜んでいるかと言われたら、何かUUID化していないことによって不正にデータを取得されることもないと思った為、連番のままでも良いと思いました。

[8524ba23]

広義の「セキュリティ」においては、「誰」が「何」を守りたいのか？という視点が大切です。

API利用者にとってはUUID化の有無はどちらでもよいでしょう。しかし「サイト運営者」から考えたら…
私が攻撃者なら、API（店舗詳細）に連番でリクエストを送り、そのサイトが持つ店舗詳細の全情報を得ようとします。
「サイト運営者」にとっては外部によって「店舗の全情報」が奪われるというリスクは避けたいでしょう。

[jjj001]

ありがとうございます。
> そのサイトが持つ店舗詳細の全情報を得ようとします。
重ね重ね恐縮なのですが、こちら店舗の全情報が渡ったとしても、それは公開している情報である為に、サイト運営者としても情報を取得されるのが遅いか早いかの違いな為、特段問題がないように思えてしまいます...

[8524ba23]

結局、サイト運営者が「何を問題とするか」によります。
「全店舗の全情報を容易に取得してもよい」という考えであれば問題ないです。

ただ、それらの店舗情報がコストをかけて集めた情報の場合、
ジャンルなどの検索APIにより「店舗の一部」を取得するのは許すが
店舗の全情報を「容易に」取得されるのは避けたいと思います。

[8524ba23]

なお、ockeghemさんの回答を読んだうえで思ったのですが、少し話が脱線してきているようです。
（脱線させたのは私の責任ですが…）
特定のフレームワーク、セキュリティ要件を具体的に明確にした問題を設定したうえで
あらたに質問を立てて議論したほうがよいと思います。

[jjj001]

> ただ、それらの店舗情報がコストをかけて集めた情報の場合、
ジャンルなどの検索APIにより「店舗の一部」を取得するのは許すが
店舗の全情報を「容易に」取得されるのは避けたいと思います。

理解しました。
こちら確かに、おっしゃる通りだと思います。

[jjj001]

> なお、ockeghemさんの回答を読んだうえで思ったのですが、少し話が脱線してきているようです。
いえ！実は、アプリケーションを開発する上で少々悩んでいたことなので、単純なセキュリティ上の脆弱性の観点からではなく、「サイト運営者」の立場になった際の、デメリットについても知ることが出来、参考になりました。
ありがとうございました。

[8524ba23]

脱線ついでに回答追記しました。
こちらもこの質問によっていろいろと勉強になりました。
ありがとうございました。