アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点

© 2025 GMO Flatt Security Inc. All Rights Reserved. HANDBOOK
UPDATE 2025.04 アプリケーション固有の「ロジックの脆弱性」を防q 開発者のためのセキュリティ観r 認可制御、ファイルアップロード機能など、機能開発で考慮すべきセキュリティ

© 2025 GMO Flatt Security Inc. All Rights Reserved. 目次
INDEX e 本資料についS e アプリケーション固有のロジックの脆弱性と共通d qe ログイン機能のセキュリティ観d e ファイルアップロード機能のセキュリティ観d Ge セキュアなURL生w Ue クーポン機能のセキュリティ観d Be 認可制御のセキュリティ観d 7e マイページ機能のセキュリティ観点

© 2025 GMO Flatt Security Inc. All Rights Reserved. GMO
Flatt Securityでは、2025年２月、弊社の脆弱性診断サービスの提供を通じてお客様に報告した 1000件以上の脆弱性データを分析し、検出された脆弱性の実態を明らかにしましたその結果、ソフトウェアの仕様やビジネスロジックに起因する「ロジックの脆弱性」と総称される脆弱性の検出数が半数以上を占めていることがわかりました。※s 「ロジックの脆弱性」とは、サービスの仕様では想定されていない動作が引き起こされることで、問題となる脆弱性を指します。具体例としてこれらの脆弱性により、「有料限定コンテンツの制限を回避して閲覧が可能になる」「URLやトークンなどリンク共有用の文字列が推測可能で、不正アクセスが可能になる」等の事象が引き起こされますそこで、本スライドではこのようなロジックの脆弱性を未然に防ぐために、開発時に考えるべきセキュリティの観点を機能別にまとめ、開発組織のための資料して整理しました。※2 ※1 GMO Flatt Security Top 10 - 2025年版 ※2 セキュリティ観点や紹介する機能は網羅的ではなく、あくまでも代表的な例を挙げることを目的としています。 https://blog.att.tech/entry/att_top10_202g はじめに INTRODUCTION

© 2025 GMO Flatt Security Inc. All Rights Reserved. LOGIC
VULNERABILITIES AND COMMON POINTS アプリケーション固有X ロジックの脆弱性と共通点

© 2025 GMO Flatt Security Inc. All Rights Reserved. ロジックの脆弱性とは何か
LOGIC VULNERABILITIES AND COMMON POINTS 一般的な脆弱性アプリケーションのコンテキストに寄らず、Webアプリケーションで一般化しやすいため、知識も体系化されており、ツールを用いて発見可能な脆弱性もある。共通して発生しやすい脆弱性{ XS SQLインジェクションロジックの脆弱性同じ事象でも、一般化・体系化は難しく、検知にはセキュリティエンジニアによる手動診断が必要であることが多い。アプリケーションのコンテキストによって脆弱性となったり、脆弱性にならなかったりするÄ # 管理者が招待する事による登録フローしか想定されていないのに、ユーザー自身がサインアップできる

© 2025 GMO Flatt Security Inc. All Rights Reserved. ロジックの脆弱性によく見られる共通点
(1/2) LOGIC VULNERABILITIES AND COMMON POINTS 1 クライアントサイドを信頼しすぎているクライアント側の制御は、ご存知のようにブラウザの開発者ツールや専用のプロキシツールを用いれば閲覧も改ざんも簡単です´ 知識を持った悪意のある攻撃者には、単にUIから見えないことは何のハードルにもならず、APIとの通信内容やヘッダに何が入ってるかなどもすべて確認可能なのでこのような方針でセキュリティを担保するのは不十分と言えるでしょう。 2 認可制御が不十分 (1から派生して起こりえる) 「管理者からの操作しか受け付けてない」「特定のテナント内同士での処理しか受け付けてない」「特定のユーザーからの操作しか受け付けてない」といった認可制御が「UI上で隠す」という方法で実装されていたとします。さらに、パラメータにそれらの操作対象リソースのID等を含んでいて、かつ送信元ユーザーと操作対象リソースの所有関係の確認を行わないまま処理が進められていたとします。この時、悪意のある攻撃者のパラメータ改ざんによって認可制御不備を突いた攻撃が起こり得ます。

© 2025 GMO Flatt Security Inc. All Rights Reserved. ロジックの脆弱性によく見られる共通点
(2/2) LOGIC VULNERABILITIES AND COMMON POINTS 3 推測可能な値をパラメータに用いてしまう「A社のユーザーがアップロードしたファイルを、A社のユーザーだけがみられるようにしたい」というような場合に、URLが「/ img/2022/06/30/A-Company/pdf/000000001.pdf」となるような形でアップロードして、システムから呼び出しているようなケースを想定します¯ 「クライアントからはブラウザで遷移させない形でダウンロードしているからURLが露出することは無いし大丈夫だろう」のように考えていると推測で当該URLにアクセスされ、情報漏えいに繋がります。 4 レスポンスやエラーメッセージに余分な情報が含まれているレスポンスやエラーメッセージはユーザーにとっても開発者にとっても重要な情報を含んでいる場合がありますが、不必要な情! は攻撃者にとってのヒントとなる場合があるので注意しましょう。

© 2025 GMO Flatt Security Inc. All Rights Reserved. Login
Security ログイン機能のセキュリティ観点

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターンA:
シンプルなメールアドレスとパスワードのみのログインフォーム Login Security

© 2025 GMO Flatt Security Inc. All Rights Reserved. 観点1:
レスポンスの差分からメールアドレスの存在が確認可能 Login Security ログインに失敗したときに「データベース内のメールアドレスの存在を確認できる」ようなレスポンスによるリスクです。このような仕様は「当該メールアドレスを持つユーザーがサービスに登録している」という情報が漏洩するだけでなく、リスト型攻撃の手がかりとして利用されます。エラーメッセージに差異がある「このメールアドレスは存在しません」と表示するなど、失敗時にユーザーに再試行を促すためのエラーメッセージが、登録済メールアドレスとそれ以外とで違う場合、メールアドレスの存在を攻撃者への手がかりとなるリスクがあります。レスポンスヘッダに差異がある「メールアドレスがデータベース内に存在する場合にはパスワードが間違っていてもステータスコードが200になるが、メールアドレスが存在しない場合は400 になる」といった出し分けを行っていると、存在を確認できます。処理時間に差異があるメールアドレスが存在しない場合、すぐにエラーを表示するが、メールアドレスが存在する場合はハッシュ値の計算を行う等の処理を行う場合、応答時間の差分を計測することで判別可能になる場合があります。リスクがある３つの仕様のパターン

レスポンスの差分からメールアドレスの存在が確認可能 Login Security エラーメッセージ、レスポンスヘッダの対策ユーザーに開示される文言やブラウザの開発者ツールで確認可能な範囲でのレスポンスに差分が出ないように処理を統一してください。エラーメッセージであれば「メールアドレスかパスワードが間違っています」に統一したり、ログイン失敗時にはレスポンスは常に400を返したりという処理を行ってください。処理時間の対策データベース内にメールアドレスが存在しない場合も入力されたパスワードに対して同等のハッシュ値計算等の計算処理を行ってからレスポンスを生成してください。メールアドレスをログインIDとして使用しないフォームから第三者に対して「このメールアドレスがこのサービスで利用されている」という情報が伝わらなければよいので、メールアドレスとは別にログインのためのID等の利用状況が外部に漏れても問題のない情報を別途用意して生成しそれをログイン時に用いるようにすることでも、今回のような問題に対処することが可能です。対策

フォームに試行回数制限がなく、ブルートフォースアタックが可能 Login Security この場合、攻撃者が機械的にログイン成功するまであらゆるメールアドレスとパスワードのパターンを入力し続ける「ブルートフォースアタック」が可能になります。攻撃者がログインに成功してしまった場合、そのサービスにおいて被害者の情報が窃取または改ざんされるなど非常に危険な状態になります。多要素認証を導入する多要素認証を導入することで、攻撃者が正しいメールアドレスとパスワードの入力に成功してしまった場合でもそれだけでログインすることを防ぎます。 reCAPTCHAを導入する reCAPTCHAを導入することで、攻撃者が用意したスクリプト等による機械的なログイン試行を防ぎます。 IPアドレス単位のアクセス制限「10分以内に5回失敗したらそのIPアドレスからの入力を受け付けなくする」というような回数制限をIPアドレス単位で行うことで多数のログイン試行自体を防ぎます。対策

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターンB:
メールアドレスとパスワードの入力後に、PINコード入力画面に遷移し入力してもらう Login Security パターンAのフォームに多要素認証としてのPIN コード入力を求めているパターンです。多要素認証を導入しているため一見セキュアに見えますが、このPINコード入力に関してもいくつか注意すべき点が存在します。

PINの桁数が少ないため確率的に突破できる可能性が高まってしまう Login Security PINの入力桁数が少ないため無作為に入力をした場合に成功してしまう確率が高いというものです。例えば4桁ですと 0000から9999で1万通りしかないので、でたらめに入力しても単純に1/10000の確率で成功してしまいます。何度も入力できるフォームの場合は回数の分だけ成功しやすくなってしまいます。 PINの桁数を小さくしすぎない単純に桁数を増やしましょう。6桁や8桁の入力を採用するサービスが一般的です。対策

PINの入力回数に制限がないので総当りで回避できてしまう Login Security 対策1が完了したとしても、無制限に試行ができるフォームであれば効果が低くなってしまいます。簡単なスクリプトで 100万回の試行をされれば6桁の入力でも確実に突破されてしまいます。 PINの入力にも回数制限を入れる 30秒以内かつ1度発行したPINに対しては5回まで」のような制限を入れることで総当りを物理的に困難にします。対策

PIN入力の成否をサーバー側で管理していないことにより PIN入力をバイパスできてしまう Login Security PIN入力についてサーバー側で入力の成否状態を保持しておらずフロントエンドに一致の成否を返しているだけの実装になっている場合を想定しますこの時、右のような「自らのアカウントであらかじめ取得しておいた『PIN成功レスポンス』を利用する」手順でPIN入力を突破することが可能になってしまいます。

PIN入力の成否をサーバー側で管理していないことにより PIN入力をバイパスできてしまう Login Security 対策 PINの入力の成功を確認してからログインセッションやトークンをクライアントに対して発行する Email/PWと2段階認証の成否をサーバー側で管理していて、両者が成功しているとサーバー側で確認できたときに初めてログインセッションやトークンをクライアントに対して発行し、それを受け取ることでクライアントがその後の処理をすすめるような実装に変更する必要があります。

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターンC:
メールアドレスの入力後にログイン用リンクが登録メールアドレスに送信され、そのリンク先にアクセスすることでログインが可能になる Login Security パスワードを使わずに本人を確認する認証方式として、いくつかのWebサービスで見られる仕様パターンです。

ログイン用リンクが推測可能 Login Security 第三者が容易に閲覧不可能な経路で送信したにも関わらず、あるユーザーに対して生成したリンクが容易に推測可能であれば意味がありません。例えば以下のようなリンクが発行されていると容易に推測可能であることがわかります¨ https://example.com/[email protected]&time=164242187® こちらの例ではクエリストリングのemailにログインしようとしているユーザーのメールアドレスを、timeにはログイン試行した時間をunixtimeで入力して試せば成功しそうなことが見て取れます。対策推測されないような生成方法を用いるなんらかの外部から推測と再現が困難な識別子を用いてリンクを生成しましょう。「サーバー内で疑似乱数をキーにして発行した SHA-256」や「UUID等の標準化された一意な値」をストレージに保存し、その値をクエリストリングに付与してユーザーに通知し、アクセスされた際にその値を照合するというような方法があります。

発行されたログインリンクに利用期限が設定されていない Login Security 「ログインリンクが何度でも利用できる」や「発行されたリンクの有効期限が無制限もしくは非常に長い」といった場合、リンクを攻撃者が何らかのタイミングで取得した際に何度でも活用できてしまうというリスクが存在します。対策ログインリンクの利用可能期間の制限を設ける「一度使用したログインリンクを無効化する」「ログインリンクの有効期限をできるだけ短くする」という対策を行いましょう。

攻撃者の用意したリンクによる強制ログイン Login Security 攻撃者がリンクを用意して被害者にアクセスさせることで、強制的に攻撃者のアカウントとしてログインさせることが可能です。対策送信先メールアドレスの再確認を求める以下のような手順でリンクにアクセスしてきたユーザーが本来想定していたユーザーかどうかを確認することで対策が可能です ¤ 送信前にフォームに入力されたメールアドレスをブラウザのローカルストレージに保存してお¾ ¡¤ ログインリンクにユーザーがアクセスした際、ローカルストレージをチェックし、メールアドレスが存在するならばそれをサーバーに送信する値としてセットす® ¤ サーバーにメールアドレスを送信し、メールアドレスがデータベース上のメールアドレスと一致していればログイン処理を継続する

© 2025 GMO Flatt Security Inc. All Rights Reserved. File
Upload Security ファイルアップロード機能I セキュリティ観点

アイコンや写真のアップロード File Upload Security SNSや掲示板サイトなどでよく見るシンプルな画像ファイルのアップロード機能ですこの場合、画像ファイルのみを受け入れてそれ以外のファイルは適切に拒否される必要があります。

拡張子のチェックに不備があり、画像ファイル以外がアップロード可能 File Upload Security アップロードされるファイル形式が適切に制限されていない場合、画像ファイル以外のファイルがサーバーに設置されることによりサイトの改竄やサーバーの乗っ取りといった攻撃が行われる危険性があります例えばApacheなどで動いているサービスに対して任意のPHPファイルを設置できる場合、PHPを経由してWebサーバーに対してシェルコマンドの実行を行うことができます。リスクがある３つのパターンクライアントサイドのみチェックブラウザでアップロードするファイルの表示設定を変更することによって画像ファイル以外をアップロードしたり、リクエストを書き換えることでチェックを掻い潜ることが可能前方一致によるチェック後方一致による正規表現のチェックでない場合、example.jpg.phpのような二重拡張子がついているファイルを用いることによってチェックを回避される危険性があります。有名でない拡張子を利用した回避一般的でない拡張子を利用する事により拒否リスト型の拡張子の制限を回避される危険性があります例：phpの場合、.phtml , .php3等

拡張子のチェックに不備があり、画像ファイル以外がアップロード可能 File Upload Security サーバーサイドでのチェックファイルが意図された適切な種類のものかのチェックは原則としてクライアントサイドではなくサーバーサイドで実行します。後方一致でのチェック拡張子のチェックは前方一致や部分一致ではなく、後方一致によって行うことで二重拡張子などによるチェックの回避を防ぐことができます。許可リストによるチェック利用できる拡張子の制限は拒否リストではなく許可リストによって行ってください。それにより想定外の拡張子のファイルがアップロードされる事を防げます。対策

© 2025 GMO Flatt Security Inc. All Rights Reserved. 観点2:ファイル名のチェックに不備があり、ディレクトリトラバー
サルによる任意のファイルの書き換えが可能 File Upload Security 細工をしたファイル名を送信する事により意図しない場所にファイルを設置される危険性があります。設定ファイルの書き換えによるサーバーの乗っ取りや、Webサイトの書き換えを行うことが出来てしまいます。対策ファイル名のチェックアップロードされたファイルのファイル名に対して、「/」「\」「:」などの利用するとディレクトリトラバーサルが可能な記号が含まれていない事を確認してください。

悪意のある画像ファイルをアップロード可能 File Upload Security 例1 / 巨大なファイル巨大なファイルをアップロードする事によってサーバーのリソースを意図的に消費したり、サーバーでの処理に負荷をかけることにより正常な操作を行えなくしたりするDoS攻撃が発生する危険性があります。例2 / ミドルウェアの脆弱性を攻撃するファイル画像ファイルを編集するソフトウェアの脆弱性を攻撃する方法も存在していますÎ 例えば、ImageMagickは毎年多くの脆弱性が報告されています。脆弱性の中には任意コード実行(RCE)が可能な非常に危険なものも含まれています。対策ファイルサイズの制限サーバーの設定にてリクエストボディサイズの制限を行う事によって巨大なファイルを処理してしまう事を防ぎます。多くの場合は言語やフレームワークごとに設定方法が用意されています。ミドルウェアの適切な利用 ImageMagickのポリシーから必要なファイルフォーマットのみを許可し、最新のバージョンのImageMagickを利用することで、既知の脆弱性を利用した攻撃を防ぐ事が可能です。

画像ファイルからの個人情報の漏洩 File Upload Security 画像ファイルに登録されている情報を適切に削除しない場合、画像ファイルにアクセスできるユーザーに意図せずファイルに紐づく情報を取得される危険性があります。それにより、個人名や撮影場所や撮影時間といった情報が漏洩する危険性があります。対策 Exifの削除サーバーに画像ファイルがアップロードされた際に、写真を撮影した場所や時間の特定に利用できるExif情報を削除してください。ファイル名を変更するファイル名に氏名などが使われている場合、そこから意図せず個人情報が漏洩する危険性があるため、例えばランダムな文字列などにファイル名を変更してください。

業務データのCSVデータのインポート File Upload Security 業務アプリ等でデータを移行する際にCSV形式のファイルを利用するパターンです。BtoB SaaS等で良く見られる実装です。

信用できないデータによる攻撃 File Upload Security データを移行するために作成されるCSVファイルは多くの場合ユーザーが作成するのではなく、信用できるWebアプリケーション上で作成されたものをインポートして利用されます CSVファイル自体は信用できるWebアプリケーションが生成したものであっても、CSVファイルを攻撃者が直接加工できる場合や、CSVファイルに集計されることを見越して元々悪意のある値がアプリケーションに渡っていた場合にはリスクが発生します。対策適切な値のチェック右図のように攻撃者が悪意のある値を含めたファイルをアップロード可能なため、CSVファイルから受けとった値に対しても通常のWebアプリケーションで行うような、特殊記号のエスケープ処理や値のチェックのような対策を行ってください。

CSV Excel Macro Injection File Upload Security 悪意のある値を含むCSVファイルを第三者がダウンロードできる形にすることにより、ExcelでCSVファイルを開いた第三者に対してExcelの関数を実行させることが可能です例えばWebフォームのアンケート機能において、最終的にCSVファイルに集計されることを見越して悪意のある値を入力すると、エクスポートされたCSVファイルがExcelで開かれた時に関数が実行される場合があります。対策特殊記号が先頭に来ないようにする CSVファイル内の値がExcelによって関数だと認識されないように=/+/-/@/Tab(0x09)/改行コード(\n,\r)/フィールド区切り文字(;/,)が値の先頭に来る場合にはシングルクオーテーション(')を先頭につける事により関数ではなく単なる文字列と扱わせる処理を実装してください。

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターンC:
本人確認書類をアップロード File Upload Security 免許証や健康保険証などによる本人確認を行う際に利用される本人確認書類のアップロード機能では、これまでの対策に加えて第三者による閲覧を防ぐための対策が必要になります。 toCの金融系サービスやマッチングアプリでほぼ必須と言える機能です。

古い画像が正しく削除されない File Upload Security 本人確認実施後そのまま本人確認書類をWebアプリケーション上に保存していた場合、潜在的なリスクとなります。何かしらの攻撃により攻撃者に本人確認書類が漏洩した際に、適切に不要な本人確認書類の消去が行われていた場合影響は小規模なものになります。しかし、古い本人確認書類を削除していないと、最悪の場合サービス利用者全体にまで影響が拡大する危険性があります対策不要なデータの削除不要な機密情報は適切に削除することにより攻撃が発生した際の潜在的なリスクを低下させてください。

© 2025 GMO Flatt Security Inc. All Rights Reserved. 観点8:他者のデータが閲覧可能
File Upload Security パターンAで紹介したようなアイコン画像のアップロードであれば、その画像が他のユーザーに見えることが期待される挙動のことも多いでしょう。しかし、本人確認書類のような機微な情報が他のユーザーから閲覧可能だと大きなリスクとなります。対策適切なアクセス制限よくあるアンチパターンとしては、そもそもアクセス制限が行われておらずファイルに割り振られたIDがわかれば誰でもアクセスできる場合や、Cookieの値などユーザー側が変更可能な値を元にアクセス制御が行われている場合があります。ファイル名を推測困難にする対策1を行なった上でアクセス制限を回避された場合の緩和策として、ファイル名を推測困難にするというのがあります。ファイル名に対してUUIDなどを割り当てる事により第三者がファイル名を推測することが難しくなります。

© 2025 GMO Flatt Security Inc. All Rights Reserved. Secure
URL Generation セキュアなURL生成

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターン:
記事配信のWebアプリケーション SECURE URL GENERATION 右記のような記事配信のためのWebアプリケーションを想定したときに、「下書き」や「期間限定公開」された記事など、公開時期・対象が限定された内容のURLを生成する際の仕様を考えます。

© 2025 GMO Flatt Security Inc. All Rights Reserved. 観点1：URLが推測可能かつアクセス制御に不備がある場合
SECURE URL GENERATION 未公開のつもりの記事下書きページURLが第三者から容易に推測可能であれば、第三者からの意図しないアクセスが行われる可能性があります。このとき正しくログインユーザーと記事を紐付けたアクセス制御が行われていれば問題ありませんが、行われていない場合には情報漏えいに繋がります。推測可能なURLの例連番になっている単純に記事番号などをそのままURLに用いてしまっている場合です³ 例：https://example.com/username/1 日付が入っている記事の作成日時をURLに用いてしまっている場合です。もう少し詳細にして秒やミリ秒単位のものが含まれていても同様に推測可能になるでしょう³ 例：https://example.com/ username/2022/02/05 単純な値で変換されたハッシュ値一見推測不可能なランダムの文字列に見えますが、変換前文字列の捜索を行うツールを用いたり、自分で簡単な実験をしてみることで推測される可能性があります³ 例：https://example.com/username/ c4ca4238a0b923820dcc509a6f75849b

URLが推測不可能だがアクセス制御に不備がある場合 SECURE URL GENERATION 第三者から推測不可能なURLになっていてもアクセス制御の不備が存在していると、Webページの利用者の予期していない方法でURLが漏洩して第三者にアクセスされることがあります。情報漏洩につながるパターン未公開URLを外部ブックマークビスでブックマークしてしまう記事の予約投稿時に発行された未公開 URLをはてなブックマークのようなソーシャルブックマークサービスでブックマークしてしまっていた場合は、未公開 URLの情報が第三者に知られてしまいます。ソースコードやAPIレスポンスからの漏洩 HTMLの<a>タグのhref属性に未公開URL が含まれてしまっており、DevToolsなどを用いて容易に確認できてしまう場合や、HTMLには含まれていないがAPIレスポンス上に未公開URLの情報が含まれている場合などのケースも考えられます。総当りでのアクセスランダムな値がURLに含まれていても、ランダム値の桁数が小さい場合や文字種が少ない場合です。このような場合は推測不可能であってもプログラムなどを用いて総当りでアクセスされることで非公開ページにアクセスされる可能性があります。

URLが推測不可能だがアクセス制御に不備がある場合 SECURE URL GENERATION 処理を自前で実装する他、AWS S3 署名付きURL（一定の時間のみ、本来権限を持っていないユーザーがあるアクションをできるようにするために発行するURL）を利用するなども1つの手段です。厳密にアクセス制御する場合の実装例 URLにアクセスした際にサービスへのサインインとユーザー単位での認可を必須にする URLを共有されたユーザーはURL先にアクセスするために、アカウント作成が必須になるため、ユーザビリティの考慮が必要です。 URLの発行時にユーザーにパスワードを発行する URLにアクセスするユーザーの認証をしなくて良いため、URLを共有されたユーザーはアカウントを作成する必要がありません。しかし、 URL生成時に発行されるパスワードの共有範囲を間違えないようにパスワードの取り扱いには要注意です。一時的にアクセスを許可する場合の実装例

© 2025 GMO Flatt Security Inc. All Rights Reserved. Coupon
Security クーポン機能のセキュリティ観点

広く公開され一回しか使えないクーポン Coupon Security 1人1回のみ利用できるクーポンが複数回利用できる場合、不正に無料でサービスを利用され金銭的な損失につながる事は明らかですこのような「広く公開され一回しか使えないクーポン」のセキュリティ観点と対策を考えます。

1度のみ利用の制限回避 Coupon Security クーポンコードが入力された場合クライアント側で利用状態を確認し、すでに利用されていた場合はエラーメッセージを表示し購入ボタンを押せなくする事でクーポンの複数回の利用を制限するという実装が考えられますが、このようにクーポンの利用状態をクライアント側で管理することは多くの場合脆弱になり得ます。対策サーバー側でアカウントのクーポン利用状態の管理クーポンの利用状況をクライアント側で確認している場合、制限を回避される危険性があるため、サーバー側でクーポンの利用状況を確認してくださいÂ なお、クーポンコードがユーザーごとに違う場合、利用済みクーポンコードとの比較だけでは対策として十分ではありません。何らかの手段で手に入れた他人のクーポンコードを入力する事で初回クーポンの特典を複数回利用可能です。そのため、クーポンコードの利用条件を含めた利用状況のチェックを行なってください。

Race Conditionによる利用回数制限回避 Coupon Security 複数の処理が同じデータに同時にアクセスした際に意図しない動作を起こすことをRace Conditionと言います。これを利用して、同時に複数のクーポン利用のリクエストを送信する事により、クーポンの利用回数制限を回避できる可能性があります。対策排他制御を行う「クーポン利用履歴のチェック」と「クーポンの利用履歴をデータベースに書き込む処理」の間に、異なるリクエストが「クーポン利用履歴のチェック」の処理を行えないようにデータベースに対してロックをかける事により排他制御を行なってください。

公開されていないクーポン Coupon Security 公式LINEを登録している人限定や、アカウント登録している人限定など、一般に公開されていないクーポンコードの取り扱いです。

クーポンコードの推測 Coupon Security クーポンコードは入力の際の利便性を考えてあまり長すぎない桁数のものが多いです。そのため総当たり攻撃などによりクーポンコードの推測が行われる危険性があります。対策クーポンコードの推測困難性を高めるクーポンコードが連番になっている場合や日付+連番のように次のクーポンコードが推測できる場合、第三者によって本来限定された人にしか公開されていないクーポンコードが利用される可能性があります。英数字混合にしたり、パスフレーズを用いたりすることで推測困難性を高めてください。試行回数制限を設けるクーポンコードの入力に何回も連続して失敗した場合など不正な挙動を検知した場合、一時的にアカウントを停止するなどの対策を行なってください。

© 2025 GMO Flatt Security Inc. All Rights Reserved. Authorization
Control 認可制御のセキュリティ観点

© 2025 GMO Flatt Security Inc. All Rights Reserved. パターン:
マルチテナントのToBサービス Authorization Control 次のような一般的なBtoB SaaSの仕様を元に考えますe d ユーザーの種別に「管理者ユーザー」「一般ユーザー」があ d 「管理者ユーザーには各種機能に対する『読み取り、書き込み、削除、更新』の権限があり、一般ユーザーは『読み取り』の権限がある」というような差分があるものとす d 管理者ユーザーは新規ユーザー作成機能等の特権機能を持っている

権限を持たない機能の操作が可能 Authorization Control あるユーザーの権限状態が正しくチェックされておらず本来行えない操作ができるという状態です。脆弱性を生む実装のパターン GUIから機能を隠しているだけになっているブラウザの開発者ツールから通信の履歴を取得し、アーキテクチャ等からAPIの構造を推測してリクエストを生成し実行される可能性があります。操作元ユーザーのIDをリクエストに含んでしまっているリクエスト内のユーザーを指定できる箇所にユーザーID等のユーザーを特定する情報を含んでしまい、かつその値が容易に推測可能なパターンです。操作権限に関する情報をリクエストに含んでしまっているユーザーの特定はセッションやAPIキーのような形で他者から推測が不可能な形で管理されているが、操作権限に関する情報がリクエストに含まれてしまっているパターンです。

他テナントのデータの操作が可能 Authorization Control ユーザーが管理者権限であるかどうか等のチェックは行えているが、「そのテナントの所属者であるかどうか」をチェックできていない場合にはテナントを超えた操作が行えてしまいます具体的には「ある企業Aのユーザーが別の企業Bのデータを操作できないか」ということを考慮する必要があります。 ToBサービスであれば機密情報の漏洩などの大きな問題に発展することが考えられます。

権限の昇格が可能 Authorization Control 「管理者ユーザーかどうかの認可制御」が正しく行われていても、「一般ユーザーが管理者ユーザーとして振る舞える」ような状態になるのであれば意味がありません。このような「権限の昇格」が行われる原因のパターンを紹介します。脆弱性を生む実装のパターン一般ユーザーの権限情報を変更可能例えば、自分のユーザー情報を更新しようとして送信されたリクエストにrole_idという権限情報が含まれている場合、管理者権限のユーザーのrole_idを指定できれば権限昇格ができてしまうような状況ですこれは、データ更新の権限の管理を「このユーザーの所有するデータかどうか」だけで行っている場合起こり得ます。一般ユーザーが管理者ユーザーを作成可能一般ユーザー自身が管理者ユーザーの権限を得られなくとも、一般ユーザーが管理者ユーザーを作成できて認証が可能であればそれは立派な権限昇格です「観点1: 権限を持たない機能の操作が可能」のような実装がユーザー登録機能等の新規のユーザーを作成する部分に行われていれば起こりえます。一般ユーザーが管理者ユーザーの認証情報を変更可能例えば「管理者ユーザーのパスワードを自分が知っているパスワードに変更してしまう」というような、既存の管理者ユーザーの認証情報を自分が知っているものに書き換えられる状態です前述の「観点1: 権限を持たない機能の操作が可能」のような実装が前項同様に行われていれば起こり得ます。

© 2025 GMO Flatt Security Inc. All Rights Reserved. 認可制御の不備の対策
Authorization Control 「GUI上で表示しない」は認可制御にならないと理解する GUIから導線を隠すのは単にユーザビリティの問題であってシステムとしての認可制御にはなりません。必ずサーバー側でユーザーごとに利用できる機能の検証等を行ってください。クライアントの生成したリクエストの値を信用しないクライアントが生成して送信する値はどのような値でも必ず改ざんされる可能性があります。送信に際してサービス上の機能を使うとは限らないので「フォームでバリデーションを行う」も認可制御や値のコントロールにはなりません。リソース同士の関連付けを適切に行い、チェックする URIのパスに含まれたリソースのIDやクライアントから送信されたIDは必ず送信元のユーザーに操作権限のあるリソースかどうかを必ずサーバーで検証してください。今回のアプリケーション例で言えば、「あるユーザーの送信したID等に関する情報が本当にそのユーザーと紐付いているかどうか」もサーバー側でチェックしてください。

© 2025 GMO Flatt Security Inc. All Rights Reserved. 前提:
自分自身のプロフィールを表示する機能 My Page Security Webアプリケーションでは、ログイン機能が存在し、自分自身のプロフィールを表示する機能があるものとします。本稿では、自分自身のプロフィールを表示する機能のことをマイページと定義しますユーザーはログインした後に、マイページを表示したり、他人のプロフィールを閲覧できます。ログイン方法は、JWT等を用いる認証ではなくCookieを用いるようなセッション認証とします。

ユーザーごとの絶対的なURLが存在する場合 My Page Security

認可制御の不備 My Page Security あるユーザーアカウントのマイページを更新する場合、[PUT] /users/{id} というリクエストを送るという仕様の際、認可制御に不備があると、リクエストに含まれるidの値を書き換えることによって、どのアカウントでも好きなリソースに対して更新操作が行えてしまいます。対策送信元ユーザーと変更対象の整合性を確認する HTTPリクエストで更新を試みている対象のリソースが「ログイン中のアカウントが、正当な権限をもっているか」を確認しなければなりません。例えば、ログイン中のアカウントが、更新を指定されたid自身であるかどうか確認するなど、「実行しようとしているアカウントが、その操作を実行するための権限があるかどうか」をその都度確認することが実装上重要と言えます。

不要・不適切なリソースへのアクセス権 My Page Security マイページの表示に必要な情報を取得する際、下記のように連番となっているidやパスワードのハッシュ等、外部から見られることを想定していないフィールド情報がレスポンスとして含まれる場合、リスクにつながります。 ¢ "id":523 "user_id":"¥att-security" "password_hash": "839dbee0768ef7870d0ceabfec2b7c4d624b04cd2f70881499f3bde632611c87" } 対策必要最低限の情報に絞ったレスポンス実際はUI上に表示しない情報であっても、レスポンスに不要なフィールドが含まれている場合、コンソール上から個別のレスポンスを直接見ることで、情報を読み取ることができてしまいます。そのため、レスポンスで情報を返す場合は、その権限・要件に応じた必要最低限の情報のみに絞るべきです。

URLで使用されている予約語をidとして使用できる My Page Security 例えば、Xでは、ユーザーページを表示する際に、/{id} という形式を採用しています。また、他のページ、たとえばトップページでは、/home というパスになっており、ダイレクトメッセージの一覧では、/messagesというパスを使用していますすなわち、ユーザーが自由に設定できるIDと、その他のルーティングが同じ階層に存在しています。この場合、ユーザーがIDを設定する際に、他のルーティングで使用している文字列を禁止しなかった場合、静的に割り当てられているURLが優先され、ユーザー情報の表示や更新などが正しくできなくなります。対策拒否リストによる管理やURL設計による対処専用の名前空間(パス)を持った設計にすることが有効です。/users/{id} のように、ユーザーが設定できる文字列のprexにより名前空間を付与することができます。設計思想上、どうしても他のパスと同じ名前空間にユーザーIDを設定したい場合には、パスには利用しない記号や文字列などをユーザーIDに付与する、という仕様も考えられます。

自分自身のプロフィールを表示する相対的なURL My Page Security 相対的なURLでは、GET /me のようなURLで、マイページを表示する際に、ユーザーの識別子をリクエスト中に含まないため、ログイン時にアカウントと紐付けられたセッションや、トークンから対象リソースを割り出すことになります。

不適切なキャッシュ・CDNの公開範囲 My Page Security Webアプリケーションでは、サーバーやデータベースへの負担を減らすため、しばしば、CDNや、さまざまなレイヤーにおけるキャッシュを用いますこれらの機構は、ログイン判定を含むサーバーのロジックの外で動作することもあるため、設定によっては認証後のユーザー自身のみが知るべき情報が乗り、権限外のユーザーに配信されてしまうこともあり得ますキャッシュは静的ファイルであるが故に、認証済みかどうかをチェックすることはできません。そのため、「キャッシュする情報」の公開範囲については、設定・実装する際に注意し、権限を持たないユーザーに対して誤って配信されることがないようにしなければなりません。

© 2025 GMO Flatt Security Inc. All Rights Reserved. セキュリティ診断AIエージェント「Takumi」
ABOUT TAKUMI l 高度なセキュリティレビューはTakumiにお任q l Pull Reuqest等を元に自律的にリスクの判断をしますf Ú 実装についての情報収集を自律的に行うため、旧来の静的解析ツールにできなかったロジックの脆弱性の診断から設計レビューまで様々な業務が可能³ Ú Slackからの依頼がなくとも、GitHubのPull Requestや Shisho Cloud byGMO等のイベントを元にリスクを判断して診断を行うことができます。 Takumiは、Slackからいつでもセキュリティの相談ができる、AIセキュリティエンジニアですP Vim等の著名OSSに10件以上の0-day脆弱性を発見しているなど、診断能力の高さも折り紙付きです。

© 2025 GMO Flatt Security Inc. All Rights Reserved. Takumiにこんなお願いもできます
ABOUT TAKUMI 仕様のセキュリティ相談実装予定の仕様がセキュリティ観点で懸念がないか、ドキュメントやテキストを元に相談することができます。認可制御不備のチェック自動的に診断することが難しいロジックの脆弱性も、機能仕様を理解することでリスク評価することが可能です。設計のセキュリティレビューアーキテクチャ設計の際のセキュリティレビューや、セキュリティに関する非機能要件の壁打ち相手として役立ちます。 Dependabotのトリアージ自社のコードベースに対する影響を加味した上で、依存関係の更新を行うべきかを評価することが出来ます。 CVEや既知の脆弱性の影響調査ニュースで話題になっている既知の脆弱性が自社のコードベースに影響があるのか無いのかをクイックに調査することができます。採用予定のOSSのレビュー OSSのソースコードを連携しリスクを評価することで、OSSを採用すべきかどうかの判断をサポートします。

© 2025 GMO Flatt Security Inc. All Rights Reserved. Our
Mission エンジニアの背中を預かるソフトウェアプロダクトの開発組織とそこで働くエンジニアにとって最適なセキュリティサービスを提供し、「背中を預けられる」存在になることがGMO Flatt Securityの使命です。会社名 GMO Flatt Security株式会社代表代表取締役CEO 井手康貴所在地東京都渋谷区桜丘町26-1 セルリアンタワー6階設立 2017年5月23日資本金 4億3042万円（資本準備金含む）

© 2025 GMO Flatt Security Inc. All Rights Reserved. 「重点的で高度」な手動脆弱性診断と
自動脆弱性診断SaaSを提供W 両者を組み合わせることで、コストパフォーマンス良くリスクを洗い出せます。「継続的で広い」高度・手動診断コード・仕様の分析も行いj 専門家が脆弱性を網羅的に発見高度・手動診断コード・仕様の分析も行いj 専門家が脆弱性を網羅的に発見継続・自動診断クラウド・Webアプリをまるご継続的に診断するSaaS 継続・自動診断クラウド・Webアプリをまるご継続的に診断するSaaS 開発組織のための脆弱性診断サービスを提供 GMO FLATT SECURITY

© 2025 GMO Flatt Security Inc. All Rights Reserved. ソースコード解析を交え、ロジックの脆弱性を高度・効率的に診断
GMO FLATT SECURITY ソースコード解析（ホワイトボックス診断）h 織り交ぜた高付加価値な診断ブラックボックス診断(外部からの擬似攻撃)のみ行う”という業界慣習にとらわれない独自の診断で、することが可能。より効率的に脆弱性を発見クラウドをはじめとし´ のセキュリティに強みモダンな開発技術 GraphQLを用いたAPIやサーバーレスなアーキテクチャなど、モダンな開発技術固有のセキュリティ観点にも対応。

アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点

アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点

More Decks by GMO Flatt Security

Other Decks in Technology

Featured

Transcript