質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

Q&A

2回答

2644閲覧

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

jjj001

総合スコア55

Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

PostgreSQL

PostgreSQLはオープンソースのオブジェクトリレーショナルデータベース管理システムです。 Oracle Databaseで使われるPL/SQLを参考に実装されたビルトイン言語で、Windows、 Mac、Linux、UNIX、MSなどいくつものプラットフォームに対応しています。

セキュリティー

このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

0グッド

4クリップ

投稿2021/10/16 02:50

編集2022/01/12 10:55

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

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

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

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

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

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

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

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

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

投稿2021/10/16 04:53

ockeghem

総合スコア11701

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

jjj001

2021/10/16 05:12

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

2021/10/16 07:02

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

2021/10/16 08:41

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

0

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

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

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

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

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

なお、いわゆるIDUUID化すべきかはケースバイケースでしょう。
たとえばユーザー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の指すモノに対するセキュリティはシステムで用意された認可制御を用いるべきです。

投稿2021/10/16 03:29

編集2021/10/17 01:29
can110

総合スコア38233

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

jjj001

2021/10/16 04:02

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

2021/10/16 04:13

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

2021/10/16 04:33

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

2021/10/16 04:58 編集

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

2021/10/16 05:20 編集

広義の「セキュリティ」においては、「誰」が「何」を守りたいのか?という視点が大切です。 API利用者にとってはUUID化の有無はどちらでもよいでしょう。しかし「サイト運営者」から考えたら… 私が攻撃者なら、API(店舗詳細)に連番でリクエストを送り、そのサイトが持つ店舗詳細の全情報を得ようとします。 「サイト運営者」にとっては外部によって「店舗の全情報」が奪われるというリスクは避けたいでしょう。
jjj001

2021/10/16 05:26 編集

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

2021/10/16 05:49

結局、サイト運営者が「何を問題とするか」によります。 「全店舗の全情報を容易に取得してもよい」という考えであれば問題ないです。 ただ、それらの店舗情報がコストをかけて集めた情報の場合、 ジャンルなどの検索APIにより「店舗の一部」を取得するのは許すが 店舗の全情報を「容易に」取得されるのは避けたいと思います。
can110

2021/10/16 05:58

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

2021/10/16 08:35

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

2021/10/16 08:40 編集

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

2021/10/17 01:30

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問