セキュリティ研修【MIXI 26新卒技術研修】

2026卒セキュリティ研修セキュリティ室 2026年4月30日セキュリティ室⼩笠原 ©MIXI 匠 ©MIXI

本資料についてこの資料は2026年度の新卒向けセキュリティ研修１日目のスライドをもとに社外公開用に一部削除/追記/調整したものです 2 ©MIXI

講師の自己紹介小笠原 • セキュリティ室 • 前職 • • Webアプリやスマホアプリの脆弱性診断関係の仕事を約6年今
• 3 匠です。脆弱性診断/啓発,教育に関係することなど ©MIXI

研修の目的目的 4 • 情報セキュリティの定義/必要性を知る • エンジニア業務で必要とされる情報セキュリティの観点を知る • セキュリティにも興味をもつ ©MIXI

アジェンダ Day 1 情報セキュリティの基本を知ろう MIXIで取り組んでいる情報セキュリティ対策を知ろうセキュアに開発するにはどうしたらいいか知ろう with ハンズオン Day 2
KENROを用いた脆弱性対策演習 5 ©MIXI

本研修では実際に悪用すると不正アクセス禁止法に抵触する内容を含んでいます悪用厳禁！ 6 ©MIXI

タイムテーブル ※適宜休憩/昼休みを挟みつつ。時間内容種別 10:40-11:00 情報セキュリティの基本を知ろう座学 11:00-11:20 MIXIで取り組んでいる情報セキュリティ対策を知ろう
座学 11:20-11:50 (開発の前提) 開発の前提部分をまずセキュアに 11:50-16:20 (サービスのサーバ側) メジャーな脆弱性を知ろう座学座学 + ハンズオンセキュアに開発するにはどうしたらいいか知ろう 7 16:20-16:50 (サービスのサーバ側) 外部ライブラリ等の脆弱性情報の見方を知ろう座学 17:00-17:10 (サービスのクライアント側) クライアント側のセキュリティリスクを知ろう座学 17:10-18:30 (管理画面や開発環境など) アクセス制御の考え方とやり方を知ろう座学 + ハンズオン ©MIXI

第一章情報セキュリティの基本を知ろう 8 ©MIXI

情報セキュリティとは下記の３要素のことを言う。 • 情報セキュリティにおいて「セキュアである」とは、下記３つのうちひとつも侵害されていない状態のこと。 9 • 機密性 •
完全性 • 可用性 ©MIXI

情報セキュリティとは機密性とは • 許可された者だけが情報にアクセスできること。機密性が侵害されている例 • あるECサイトにて、アクセス権の検証に不備があり、他ユーザの購入履歴を参照できる状態になっていた。 10 ©MIXI

情報セキュリティとは完全性とは • 情報が正確であること。改ざんされたり破壊されたりしていないこと。完全性が侵害されている例 • 11 会社のホームページが不正アクセスされ、見た目やリンクが改ざんされている。 ©MIXI

情報セキュリティとは可用性とは • 情報が必要なとき、いつでもそれにアクセスできること。可用性が侵害されている例 • 運営しているWebサービスに対し、負荷の大きなリクエストを大量に実行され、耐え切れずサーバがダウンしてしまっている。 12 ©MIXI

可用性を上げるために • バックアップ/復旧手段を持っておこう • サービスが停止した際にすみやかに復旧できるよう、サービスが稼働するためのデータ（ユーザデータ、コード etc..）はバックアップしておこう • いざというとき慌てないように復旧手段をドキュメントや頭の中に残しておこう
（説明できるようになっていると Good） • プラス、自分のサービスやデータの性質を考慮しよう • 止まると人命に関わる /災害時に動かないと困るようなもの等は、例えばロケーション分散等することでそもそも止まらないように。 13 ©MIXI

何のために情報セキュリティを学ぶのかサービスを利用する「利用者」と、それを提供する「自分たち」を守るためです。利用者を守る自分たちを守る 14 ©MIXI

情報セキュリティを守れず、事故が起きると...... 15 利用者は…… 自分たちは…… 実害的なダメージ自分や自分の家族等の個人情報が漏洩する。課金していたゲームの資産が無駄になる。必要だったサービスが受けられない。 etc 実害的なダメージ
賠償や訴訟に発展することがある。業務自体が停止する。売上への悪影響。信頼的なダメージ「MIXI」というブランドへの信頼が低下する。ユーザが今後ミクシィのサービスを利用したくなくなる。コラボ等のビジネスチャンスを信頼失墜で失う。 ©MIXI

事故が起きたら 16 • 事故が起きたらCSIRTまで報告しよう • 不安だったら先輩や相談用Slack chなど、まずは相談しよう ©MIXI

第二章 MIXIで取り組んでいる情報セキュリティ対策を知ろう 17 ©MIXI

情報セキュリティに対する脅威には何があるか？ 18 順位個人組織 1 インターネット上のサービスからの個人情報の窃取ランサム攻撃による被害 2 インターネット上のサービスへの不正ログイン
サプライチェーンや委託先を狙った攻撃 3 インターネットバンキングの不正利用 AIの利用をめぐるサイバーリスク 4 クレジットカード情報の不正利用システムの脆弱性を悪用した攻撃 5 サポート詐欺（偽警告）による金銭被害機密情報等を狙った標的型攻撃 6 スマホ決済の不正利用地政学的リスクに起因するサイバー攻撃（情報戦を含む） 7 ネット上の誹謗・中傷・デマ内部不正による情報漏えい等 8 フィッシングによる個人情報等の詐取リモートワーク等の環境や仕組みを狙った攻撃 9 不正アプリによるスマートフォン利用者への被害 DDoS攻撃（分散型サービス妨害攻撃） 10 メールやSNS等を使った脅迫・詐欺の手口による金銭要求ビジネスメール詐欺引用元：https://www.ipa.go.jp/security/10threats/10threats2026.html, (2026/1/29). ©MIXI

情報セキュリティに対する脅威には何があるか？ 19 順位個人組織 1 インターネット上のサービスからの個人情報の窃取ランサム攻撃による被害 2 インターネット上のサービスへの不正ログイン
サプライチェーンや委託先を狙った攻撃 3 インターネットバンキングの不正利用 AIの利用をめぐるサイバーリスク 4 クレジットカード情報の不正利用システムの脆弱性を悪用した攻撃 5 サポート詐欺（偽警告）による金銭被害機密情報等を狙った標的型攻撃 6 スマホ決済の不正利用地政学的リスクに起因するサイバー攻撃（情報戦を含む） 7 ネット上の誹謗・中傷・デマ内部不正による情報漏えい等 8 フィッシングによる個人情報等の詐取リモートワーク等の環境や仕組みを狙った攻撃 9 不正アプリによるスマートフォン利用者への被害 DDoS攻撃（分散型サービス妨害攻撃） 10 メールやSNS等を使った脅迫・詐欺の手口による金銭要求ビジネスメール詐欺色々あってカオス引用元：https://www.ipa.go.jp/security/10threats/10threats2026.html, (2026/1/29). ©MIXI

3つのアタックサーフェスについてアタックサーフェス対策の主体セキュリティ室の支援の例事故対応脆弱性診断（外注 / 内製）自社サービス事業部門
アプリインフラ関連ツール等 IaaS監視（AWS / Google Cloud）新卒エンジニア研修ゼロトラスト支援（導入 / 啓発） EDRの共同運用、PFW設定見直し社内システム端末全社ツール社内NW オフィス設備等社内システム部門 IDPの共同運用 CSIRT パスワードマネージャの共同運用ゼロトラスト支援（導入 / 啓発）人間アカウント運用脳内の情報等 20 全職種向け研修各人・各部各種啓発や周知（全体朝会等）業務委託監督の支援（教育資料等） ©MIXI

3つのアタックサーフェスについてアタックサーフェス対策の主体セキュリティ室の支援の例事故対応脆弱性診断（外注 / 内製）自社サービスアプリ
インフラ関連ツール等事業部門 IaaS監視（AWS / Google Cloud）弊社では攻撃の狙われどころを新卒エンジニア研修３パターンに分けて防御策を実施しゼロトラスト支援（導入 / 啓発）ている EDRの共同運用、PFW設定見直し社内システム端末全社ツール社内NW オフィス設備等社内システム部門 IDPの共同運用 CSIRT パスワードマネージャの共同運用ゼロトラスト支援（導入 / 啓発）人間アカウント運用脳内の情報等 21 全職種向け研修各人・各部各種啓発や周知（全体朝会等）業務委託監督の支援（教育資料等） ©MIXI

3つのアタックサーフェスについてアタックサーフェス対策の主体セキュリティ室の支援の例事故対応脆弱性診断（外注 / 内製）自社サービス事業部門
アプリインフラ関連ツール等 IaaS監視（AWS / Google Cloud）新卒エンジニア研修ゼロトラスト支援（導入 / 啓発）セキュリティ室が行っている支援をご紹介社内システム端末全社ツール社内NW オフィス設備等社内システム部門 EDRの共同運用、PFW設定見直し IDPの共同運用 CSIRT パスワードマネージャの共同運用ゼロトラスト支援（導入 / 啓発）人間アカウント運用脳内の情報等 22 全職種向け研修各人・各部各種啓発や周知（全体朝会等）業務委託監督の支援（教育資料等） ©MIXI

社内システムの情報セキュリティ対策の例 • • ゼロトラスト • システムに対するアクセス制御施策。 • 詳しく後述。 EDR •
Endpoint Detection and Response • エンドポイントにおける脅威の監視/検出技術 • 会社支給PCにて不審な挙動 (マルウェアが疑われるファイルの実行等) がみられるとアラートが上がる • エンジニアが使うツールは割とアラート上がりやすい (使い方を間違えると事故に陥りやすいとも言える) 23 ©MIXI

サービスの情報セキュリティ対策の例 24 • 脆弱性診断 • IaaS監視 • コードスキャン • 公開エンドポイントの脆弱性チェック（後述）
©MIXI

脆弱性診断の紹介 • 脆弱性診断とは • アプリケーションに潜む脆弱性を探す検査。 • • 25 疑似的な攻撃を仕掛け、挙動を診て脆弱性を探る。セキュリティ室で行っている脆弱性診断関連のサポート
• 予算やスケジュール感に応じて診断内容（外注/内製）の提案と診断実施 • 診断の準備や実施にあたり必要になる手続き/環境準備等のサポート ©MIXI

脆弱性診断の紹介例えばこんな脆弱性が見つかります。 26 他人の登録情報を盗めるデータベースを不正操作できる他人になりすましができる有料ガチャを不正に回し放題アイテムを不正に入手できる不正にコードを実行できる ©MIXI

セキュリティ室で行っているIaaS監視 • 今のところAWS, Google Cloud, Azure, GitHubを対象にしています • 攻撃が来るとアラートが上がります！ •
• 27 • 不正なアウトバウンド通信が起こっている • マイニングが起こっている設定面での不備があるとアラートが上がります！ • 二要素認証を設定していないユーザがいる • バケットがインターネット公開になっている「Wiz」という製品を使用して監視しています。 ©MIXI

コードスキャン（Code-to-Cloud） WizではGitHubとの連携により、コードスキャン機能が使えるようになっています。単にコードの問題点を検出するだけでなく、脆弱性のあるライブラリ利用やIaCの問題点、APIキーのハードコード等を検出できるため、非常に強力な機能となっています！また、IaaS監視とコードスキャンが包括的にカバーされていることで、デプロイしたクラウドの環境まで加味してリスクを評価することができます。（これは「Code-to-Cloud」という考え方）例: 「この SQL インジェクションの脆弱性があるコードは、本番
AWS アカウントのインターネット公開された EC2上の API で実際に動いている」 →直ちに修正が必要 28 ©MIXI

人の情報セキュリティ対策の例 29 • パスワードマネージャ等のソリューション導入 • 啓発/教育活動 • E-learning • 朝会
©MIXI

パスワードマネージャのススメ製品によるが下記のようなメリットがあったりします。 • • セキュア！ • 偽サイトに対してはサジェストが働かないため、フィッシング対策となる • 保存してあるパスワードの安全性をチェックしてくれる（使い回しが無いかや桁数が少なくないか等
• 安全なパスワード値をサイトごとに生成してくれる • メモ等で管理して無くす心配がない便利！ • 30 いちいち覚えたり調べて入力したりしなくてよくなる ©MIXI

フィッシングクイズ間違い探し！ 31 ©MIXI

偽物 32 ©MIXI

本物 33 ©MIXI

お分かりいただけただろうか 34 ©MIXI

違いはココ ※偽物証明書情報無料で有名な Let’s Encrypt ※本物証明書情報 35 ©MIXI

フィッシングサイトでログインを試みるとどうなるか • 裏で本物のGoogleログインを試行しているため、認証の成功/失敗も本物と同様に再現されている。実在しないID 36 ご丁寧にbot対策まで実在するID ©MIXI

フィッシングで気をつけること見分けの指針 • 差出人 • • • メールアドレスのドメインは問題なさそうか？ • 正規のドメインか（本物っぽいが微妙に違うケースなど
• メールアドレスを交換したことがあるか • フリーメールアドレスか • 送信元と署名が合っているか内容・本文 • 個人情報や認証情報を要求していないか？ • リンク先への誘導や、添付ファイルの開封を促していないか？リンク先URL • リンク先ドメインは問題なさそうか？ • 表示URLとマウスをかざした際の実際の遷移先URLが異なっている • HTTPSでない場合はより一層警戒 • • 添付ファイル • 37 ※ 正規のHTTPサイトやフィッシングのHTTPSサイトもある Excel, Word等のマクロ、実行形式ファイル、ショートカットファイル、二重拡張子(doc, exe) ©MIXI

フィッシングで気をつけること見分けの指針 • 差出人 • • • メールアドレスのドメインは問題なさそうか？ • 正規のドメインか（本物っぽいが微妙に違うケースなど
• メールアドレスを交換したことがあるか • フリーメールアドレスか • 送信元と署名が合っているか内容・本文個人情報や認証情報を要求していないか？ • リンク先への誘導や、添付ファイルの開封を促していないか？リンク先URL • リンク先ドメインは問題なさそうか？表示URLとマウスをかざした際の実際の遷移先URLが異なっている • HTTPSでない場合はより一層警戒 ※ 正規のHTTPサイトやフィッシングのHTTPSサイトもある添付ファイル • 38 例えばLet’s Encrypt等の取得が容易な証明書は、それ自体が悪いわけではないが、無料でお手軽なのでフィッシングで利用しやすいのも事実ではあるので注意。 • • • 逆にいうと自分たちの開発においてはフィッシングと見間違われないようにしたい。 • Excel, Word等のマクロ、実行形式ファイル、ショートカットファイル、二重拡張子(doc, exe) ©MIXI

安全に配慮し調査＆キャプチャを行っています！怪しいサイトに興味本位でアクセスしないように 39 ©MIXI

第三章セキュアに開発するにはどうしたらいいか知ろう 40 ©MIXI

前提となる考え「セキュアに開発業務」をするために守らなければいけないもの • • 開発の前提 • インフラ(AWS, GoogleCloud)の環境。NW設定等。 • 作業環境。PCやクレデンシャル等。
• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 41 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 42 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境などセキュリティ室の戦略指針をもとにサービスの守り方を整理した感じです ©MIXI

セキュアに開発する（インフラ）開発をするにあたりNWを準備したりサーバを建てたりなどなどインフラを構築します。最近ではAWS, GoogleCloudを使うことが多いと思うのでその前提で説明します。 44 ©MIXI

セキュアに開発する（インフラ）クラウドを使っていても全部丸投げというわけではない！ 45 • クラウドそのものはIaaS側の責任 • クラウドでしていることはMIXI側の責任引用元：https://aws.amazon.com/jp/compliance/shared-responsibility-model/,(2025/4/27) ©MIXI

セキュアに開発する（インフラ）下記関連の設定やらかしはあるあるだと思うので注意しておきましょう • NW関連の設定 • • 想定外のアクセスが許可されないようにする。FWのinbound公開範囲を適切に。ストレージ等の公開設定 • S3、GCS、CloudRun、Lambdaなどなど
• 公開想定のバケットでもリスティング機能は有効化しないようにする。 • • うっかり機密なファイルをアップしてしまった際にそのファイルのパスがバレるバレないは分水嶺になりうる IAMの運用 • 二要素認証を設定して不正アクセス対策。 • アクセスキーを正しく管理。無闇に作らず、権限を最小化し、使わなければ破棄。 ↑上記がセキュアになっているかは一定セキュリティ室で監視しています 46 ©MIXI

セキュアに開発する（インフラ）侵害や事故が起こったときの影響が最小限に閉じるように、環境は分けておこう。分離できるところは分離しよう。 • AWSアカウント, Google Cloudプロジェクトを開発/脆弱性診断/ステージング /本番など用途ごとに分ける
• 47 ネットワークセグメントも連携が不要なら分けておく ©MIXI

セキュアに開発する（インフラ）ログは取って保存しておかないと無い（当たり前）ので、できるだけ取って保存しておこう • 取っておくべきログの例（インシデント時の侵害痕跡調査に役立つ） • • 監査ログ（システムの操作イベントのログ） • Google
Cloud→自動で一定cloud loggingに保存される設定になっている • AWS→セキュリティ室の監視設定時にCloudTrailログをS3に保存する設定を入れている • ユーザーログイン履歴などのアプリケーションログ • 送信元IPなどのアクセスログ保存場所 • サーバ内だけでなくクラウド上(cloudwatch, cloudlogging, s3, gcs等)等インスタンス外にもリモートバックアップしておくとGood 48 ©MIXI

セキュアに開発する（インフラ）マネージドサービスも選択肢に入れよう • 開発業務環境構築のために、クラウド上にサーバを建てたりすることがあります。 • その際、自前環境を守るためには例えばゼロトラスト構築やOS等の脆弱性管理などが必要になり、構築/運用コストがかかりますが、マネージドサービスによってはこれらがサービス側で提供されているといったメリットがあるため、選択肢の一つとして持っておきましょう •
例）機械学習関係の業務環境としてJupyterを使う • • 選択肢として下記があります • 自分でサーバを建てJupyterを導入(構築)する • AWSが提供しているSageMakerサービスを使う SageMakerサービスを使うとセキュリティ上で下記のようなメリットが有ります (※) • IAMで認証が行われるため、それ自体が不正アクセスされない限り第三者にアクセスされることが無くなる • パスワード管理が不要に • サーバのOSやミドルウェアの脆弱性管理が不要になる ※…署名付きURLというSageMakerならではの取り扱い注意な要素もある 49 ©MIXI

セキュアに開発する（インフラ）マネージドサービスも選択肢に入れよう • マネージドサービスを使おう！と単純に言いたいわけではなく、どういうインフラが最適かはケースごとに費用 ,セキュリティ,構築&運用コスト等で総合的に決めるべきですが、マネージドサービスを使うことでメリットもあるのでご一考くださいという案内でした。 50 ©MIXI

セキュアに開発する（インフラ）【参考】AWSとGoogle Cloudのセキュリティベストプラクティス AWS • https://aws.amazon.com/jp/architecture/security-identity-compliance/?cards-all.sort-by=item.additionalFields.sortDate&cards-all.sortorder=desc&awsf.content-type=*all&awsf.methodology=*all Google Cloud • 51
https://cloud.google.com/security/best-practices?hl=ja ©MIXI

セキュアに開発する（各自の作業） • 業務端末のFWは閉じておこう • アクセスキー等のクレデンシャルの取り扱いには注意！ • GitHubにアップロードして漏洩など。パブリックに公開するとすぐに使われる可能性があります。 • •
secretlintなどを使う等することでミスを防ぐ仕組みを入れるとGood OS/ツール等のバージョンアップデートを忘れず • 再起動時に自動アップデートされるものなどもある。業務終了後のシャットダウンを習慣化しよう。 53 ©MIXI

セキュアに開発する（各自の作業） • 安全性が高いと言い切れないツールを安易に入れない • chrome拡張等。公式のストアであっても悪性のものが紛れていることがあります。 • 公式が配布しているツールやレビュー件数が多いメジャーなもの等でない場合、一歩踏みとどまりましょう。 • 手元のPCでなくリモートサーバ側で仕事をする場合(RDP,
SSH, CloudIDE等) • 会社貸与PCではEDRやADでの制御など、一定のセキュリティを確保しています。その保護からは外れるということは認識して、しっかり自衛しましょう • • アクセス制御はしっかり。特にRDP。 • 不要なことをしない。不要なプログラムを入れない。クラウドなら安心...ではないので注意！ • • 54 責任共有モデルを思い出そう有事の際に備え、できるだけログは残るように。 ©MIXI

セキュアに開発する（データの取り扱い）業務において様々なデータを扱うと思いますが、前提としてどんなデータでも適切に守らなければいけません。データの種類によって取り扱いルールが変わってきます。自分たちが扱うデータが何なのかまず把握しよう。アンテナを張っておこう。 56 ©MIXI

セキュアに開発する（データの取り扱い）例えば個人情報なら、個人情報保護法遵守のために下記のような事項を守らないといけません。 - 利用目的を特定しあらかじめ公表もしくは本人に通知しなければならない。基本的に利用目的の達成に関係のない取り扱いはしてはならない。詐欺などの不正手段により個人情報を取得してはならない。適切な管理を行う。本人の個人情報の開示・訂正・停止の求めや苦情に対して何らか応じなければならない。グッズの配送目的で収集した住所に新サービスの案内を送る、のような行為は NGになります。
57 ©MIXI

セキュアに開発する（データの取り扱い）ちなみに、、次のうち個人情報に該当する可能性が高いものはどれでしょうか？ 58 - 氏名 - 指紋 - 趣味
- メールアドレス ©MIXI

セキュアに開発する（データの取り扱い）ちなみに、、次のうち個人情報に該当する可能性が高いものはどれでしょうか？ - 氏名 ← 特定の個人を識別できる（同姓同名でも他の情報との組み合わせることで識別できる） - 指紋 ←
身体の一部の特徴を電子処理のために変換した符号も個人情報 - 趣味 ← きわめて特殊な趣味でなければ個人情報では無い可能性が高い - メールアドレス ← [email protected]と[email protected]とでは識別可否が変わる個人情報保護法において「個人情報」とは、生存する個人に関する情報で、氏名、生年月日、住所、顔写真などにより特定の個人を識別できる情報をいいます。個人情報とは、「当該情報に含まれる氏名、生年月日その他の記述等（文書、図画若しくは電磁的記録（電磁的方式（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式をいう。次項第二号において同じ。）で作られる記録をいう。以下同じ。）に記載され、若しくは記録され、又は音声、動作その他の方法を用いて表された一切の事項（個人識別符号を除く。）をいう。以下同じ。）により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）」 59 ©MIXI

セキュアに開発する（データの取り扱い）個人情報を例として軽く触れましたが、データ取り扱いについての法律や基準が存在することがあります。また、社内ルールとしてもどの情報をどう扱うかについての社内ガイドラインとして下記があります。自分が扱うデータが何なのか把握し、適切に扱おう！ 60 ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 62 サーバ側次はここ！ • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など ©MIXI

前提となる考え「セキュアに開発業務」をするために守らなければいけないもの • • • クライアント側にあるモノは見られる /触れる/ 改造できる。だから完璧に守ることは困難とインフラ(AWS, GoogleCloud)の環境。NW設定等。いう前提がある。
• 作業環境。PCやクレデンシャル等。 • データの取り扱い。個人情報等。開発の前提開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 63 だから、大事なデータ /処理はサーバ側に寄せる。そして、サーバ側を鬼のように守り抜く必要がある。サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 64 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側まずはここの話をしてゆく！公開しないもの = 管理画面や開発環境など ©MIXI

サーバ側で作りこんでしまった脆弱性が悪用されたときの被害 • 個人情報漏洩 • サーバ停止 • 他人を攻撃するための踏み台として利用 • データの破壊、変更、挿入 •
Webサイト改ざん • アカウント乗っ取りによる、なりすまし • 非公開情報へアクセス • 不正購入多岐にわたる 65 ©MIXI

多岐に渡る脆弱性を知り、対策するには、、「これだけ気をつけていればOK」は無い。まずはメジャーどころを知っておこう。メジャーな脆弱性を知るために今日の研修ではOWASP Top10(API/Web)を抑えておこう。 • OWASPとは • 「Open Worldwide
Application Security Project」の略 • Webをはじめとするソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。 • • 66 引用元：https://owasp.org/www-chapter-japan, (2025/4/27) OWASP Top 10とは • OWASPがクリティカルだと考える10種類の脆弱性のこと。 • ことサーバサイド開発においては、API/Webアプリケーションの2種類、計20種類がある。 ©MIXI

OWASP Top10の脆弱性たち API Web ◦ Broken Object Level Authorization ◦
Broken Access Control ◦ Broken Authentication ◦ Security Misconfiguration ◦ Broken Object Property Level ◦ Software Supply Chain Failures ◦ Cryptographic Failures ◦ Injection ◦ Insecure Design ◦ Authentication Failures ◦ Software and Data Integrity Failures ◦ Security Logging and Alerting Failures ◦ Mishandling of Exceptional Conditions Authorization ◦ Unrestricted Resource Consumption ◦ Broken Function Level Authorization ◦ Unrestricted Access to Sensitive Business Flows ◦ ◦ 67 Server Side Request Forgery Security Misconfiguration ◦ Improper Inventory Management ◦ Unsafe Consumption of APIs ©MIXI

脆弱性を知り、対策する Owasp Top 10の脆弱性を、ハッキングを実際に試しながら勉強していきましょう！ 68 ©MIXI

どうやってハッキングするのかブラウザリクエスト Webアプリ HTTP レスポンスクライアントサーバここのリクエスト部分をいじって、結果をみて脆弱性を見つける！ 69
©MIXI

どうやってハッキングするのかリクエストを改変ブラウザ Webアプリローカルプロキシツールクライアントサーバ今日使うBurp
Suiteもローカルプロキシツール！ 70 ©MIXI

演習に使うWebアプリケーション • OWASP Juice Shop • https://github.com/juice-shop/juice-shop MIXIでの新卒研修時にはCloud Run +
Cloud Load Balancing + IAP構成でしたがお好みの形でデプロイしてみてください 71 ©MIXI

演習に使うローカルプロキシツール • Burp Suite • 72 https://portswigger.net/burp ©MIXI

Burp Suiteのセットアップ 73 • Temporary projectを選択。 • Cofigurationはあれば選択。無ければDefault • Start
Burp ©MIXI

Burp Suiteのセットアップ • 74 「Proxy」→「Open Browser」 ©MIXI

Burp Suiteのセットアップ 75 • ブラウザが立ち上がります！ • 自分の環境のURLにアクセスしてみましょう ©MIXI

Burp Suiteのセットアップ • 76 アクセスできたらOK！ ©MIXI

おさえておきたいBurpSuiteの機能基本的なもの • • • 77 Proxy>Intercept －通信のキャッチ •
Intercept is on：通信をキャッチ • Intercept is off：通信をキャッチしない（通過） • Forward：キャッチした通信を送信 Proxy>HTTP history －通信の履歴確認 • Request：要求 • Response：応答 Repeater －リクエストの再送 • 挙動の確認に使う • 使い方 • historyで再送したいリクエストに対しcontrol + クリック • Send to Repeater選択 • Repeater タブが光る！ • Repeaterタブに移動 • 「Send」で再送 ©MIXI

Juice Shopを触ってみよう（通常動作確認） 1. 商品検索 • 2. アカウント登録 • 3. 任意のメアド「[email protected]」などで会員登録
ログイン • 4. キーワード「Apple」などで検索作成済みアカウントでログイン商品購入 • ログイン後＞Basketに入れる＞Checkout BurpのHistoryを確認しながらサイト巡回してみよう。 78 ©MIXI

おさえておきたいBurpSuiteの機能ちょっと発展的なもの • Intruder • 様々な試験値を試したいときに使う • 使い方 i. 試験したいリクエストを
「Send to Intruder」。 ii. Intruder画面にて、試験したい箇所を「§」で囲む。 79 ©MIXI

「Send to Intruder」。 ii. Intruder画面にて、試験したい箇所を「§」で囲む。 iii. 下記の試験値サンプルをコピーし、「Payloads」→「PayLoad Options」の「Paste」をクリック。 80 • hoge • huga • piyo ©MIXI

「Send to Intruder」。 ii. Intruder画面にて、試験したい箇所を「§」で囲む。 iii. 下記の試験値サンプルをコピーし、「Payloads」→「PayLoad Options」の「Paste」をクリック。 iv. 81 • hoge • huga • piyo 「Start attack」をクリック。 ©MIXI

「Send to Intruder」。 ii. Intruder画面にて、試験したい箇所を「§」で囲む。 iii. 下記の試験値サンプルをコピーし、「Payloads」→「PayLoad Options」の「Paste」をクリック。 • hoge • huga • piyo iv. 「Start attack」をクリック。 v. 「§」の箇所に試験値が送信される。その結果を一覧で確認できる。 82 ©MIXI

OWASP Top10の脆弱性たち API Web ◦ Broken Object Level Authorization ◦
Broken Access Control ◦ Broken Authentication ◦ Security Misconfiguration ◦ Broken Object Property Level ◦ Software Supply Chain Failures ◦ Cryptographic Failures ◦ Injection ◦ Insecure Design ◦ Authentication Failures ◦ Software and Data Integrity Failures ◦ Security Logging and Alerting Failures ◦ Mishandling of Exceptional Conditions Authorization ◦ Unrestricted Resource Consumption ◦ Broken Function Level Authorization ◦ Unrestricted Access to Sensitive Business Flows ◦ ◦ 83 演習をしながら脆弱性を体感してゆく！ Server Side Request Forgery Security Misconfiguration ◦ Improper Inventory Management ◦ Unsafe Consumption of APIs ©MIXI

第一問他人のカート(basket)を覗き見しよう 84 ©MIXI

第一問ヒント自分のカートにアクセスした時のHTTP通信を見てみよう。（/rest/basket/{0}） 85 ©MIXI

第一問他人のカート(basket)を覗き見しよう答え /rest/basket/6 の数字部分（カートID）を改変する。例えばidに3を指定すれば、ユーザIDが3のユーザのカート情報が見られる 86 ©MIXI

第一問問題点 • アクセス制御が適切に行われていない対策 • ユーザと紐づく情報を取得する際に、正当性検証を必ず行う • そもそもカートIDが必要か？ •
87 も吟味するセッションから参照でよいならその方がセキュア ©MIXI

第一問 OWASP Top10でいうと下記あたり。 • (API) Broken Object Level Authorization •
(API) Broken Function Level Authorization • (Web) Broken Access Control 総じて、「アクセス制御を適切に行いましょう」という点が肝。 88 ©MIXI

アクセス制御の不備とは？アクセス(認証、認可、セッション管理など)の制御不備のこと。本来その人がアクセスできないはずの情報にアクセスできてしまう問題。管理者用ページ本来はアクセス不可のはずが本来はアクセス不可のはずがアクセス可能な状態.. アクセス可能な状態.. 攻撃者(ユーザID:hoge) hogeではないユーザのプ
ロフィールデータ 89 ©MIXI

アクセス制御の不備によって想定される被害 • 非公開情報の漏洩 • 権限外機能の操作など（多岐にわたる 90 ©MIXI

コード的な話＜脆弱なコード例1（Ruby）＞ • 他ユーザの情報を見られちゃうコード(表示コンテンツの取得個所にて..) user_id = requestobj.param[:user_id] # リクエストのパラメータ値は改ざん可能！ユーザから送信された値を使って
userprofile = User.where(user_id).profile プロフィール情報を取得し view(userprofile) • それを表示している！攻撃者が他ユーザのuser_idを指定してリクエストを送信すると、プログラムはそのuser_idと紐づいた情報を表示してしまう • 91 以下のようなことに気を付ける必要がある • リクエストパラメータにuser_idを含ませる必要はあるか？セッションIDで十分ではないか？ • 含ませるならその妥当性は検証しなくて大丈夫か？ ©MIXI

コード的な話＜脆弱なコード例2（Ruby）＞ • 管理者ページにアクセスできちゃうコード(セッションの検査個所にて..) session = get_session(req.header[:cookie]) #「,admin: true」を入れていない！ if
session.nil? raise “セッションがありません！” end do_adminsomefunction • adminじゃなくてもif文に引っ掛からず処理が進行してしまう • ログイン直後の画面でだけ権限確認をするのではなく、そこから辿れるリンク先の画面でも都度検証しましょう 92 ©MIXI

対策（気をつけること） • 権限管理をしっかりするためには、権限管理をしっかりしましょう（身もふたもないが..） • 銀の弾丸は無い.. • 93 しっかり問題意識を持っておけば気づきやすくなるはず！ ©MIXI

第二問クロスサイトスクリプティング • 94 「javascript:alert(`xss`)」このJavascriptを注入できる場所を探し、サイト上で動かしましょう！ ©MIXI

クロスサイトスクリプティングとは動的なページ生成時に攻撃者によってスクリプトが埋め込まれ、被害者のブラウザ上でそのスクリプトが動作してしまう脆弱性。参考 • (IPA) 安全なウェブサイトの作り方 • 95 https://www.ipa.go.jp/files/000017316.pdf
©MIXI

クロスサイトスクリプティングによって想定される被害 • なりすまし • フィッシングサイトへの誘導 • など勘所 • 96
Webページが攻撃者によって任意に改ざんされるということ • 閲覧したユーザのCookie情報を攻撃者に送信するスクリプトを仕込む • 偽フォームを埋め込んで認証情報を攻撃者に送らせる ©MIXI

第二問クロスサイトスクリプティング • 97 「javascript:alert(`xss`)」←このJavascriptを注入できる場所を探し、サイト上で動かしましょう！ ©MIXI

第二問クロスサイトスクリプティング • 「javascript:alert(`xss`)」←このJavascriptを注入できる場所を探し、サイト上で動かしましょう！ヒント1 • クロスサイトスクリプティングは「入力値を使ってHTMLを構築する際に、外部からJavaScriptを注入できる」という問題でした。ということは、「入力値を使ってHTMLを構築している場所」が攻撃場所になりそう！？ 98
©MIXI

第二問クロスサイトスクリプティング • 「javascript:alert(`xss`)」←このJavascriptを注入できる場所を探し、サイト上で動かしましょう！ヒント2 • 99 https://[環境URL]/#/search が怪しい...？ ©MIXI

第二問クロスサイトスクリプティング • 「javascript:alert(`xss`)」←このJavascriptを注入できる場所を探し、サイト上で動かしましょう！ヒント3 • 100 検索フォーム（https://[環境URL]/#/search）に以下を入力して結果を見てみましょう • 例1）<s>123</s>
• 例2）<iframe src="https://mixi.co.jp"> ©MIXI

第二問クロスサイトスクリプティング • 「javascript:alert(`xss`)」←このJavascriptを注入できる場所を探し、サイト上で動かしましょう！答え • 検索フォームにて、下記を入力する。 • <iframe src="javascript:alert(`xss`)">
※ <script>タグはバリデーションされているため攻撃には使えない。 101 ©MIXI

第二問 alert(`xss`)以外のスクリプトも動かしてみよう • お試し1 • • <iframe src=javascript:alert(document.cookie)> お試し2 •
(ログイン中のcookie情報取得) (他サイトへ移動させる） <img src=1 onerror=window.location.href="https://mixi.co.jp"> この応用で、攻撃者は好きなJavaScriptを動作させることができる...！ 102 ©MIXI

クロスサイトスクリプティングの対策 • 「<」,「>」,「"」,「'」など、ブラウザにとって意味を持つ文字（特殊文字）はエスケープ（文字列として解釈させる形式化）して出力する。 • 今回のケースもこれが対策になる。 • 保険的対策として入力値検証やCSPヘッダの設定も有効。 • XSSは複数の種類があり、種類に応じて対策も異なる場合があるので注意
• • JavaScriptスキームを悪用するパターン • Dom構築時にスクリプトが仕込まれるパターン JavaScriptライブラリに問題がある場合は、使用しているライブラリを更新する。動的にHTMLページを生成する際は、「レスポンスに攻撃者のスクリプトが埋め込める余地は無いか」というアンテナを張っておくこと！ 103 ©MIXI

コード的な話＜脆弱なコード例＞ • ユーザが入力した検索ワードをレスポンスに表示する keyword = requestobj.param[:keyword] # keywordにScriptなどが入力されると ..
responsehtml = “<body>” + keyword + “の検索結果一覧” + ”</body>” ここに入力した Scriptがそのまま埋め込まれる！ ※例であって、Juice Shopのコードがこの通りになっているというわけでないです！ 104 ©MIXI

コード的な話＜脆弱なコード例＞ • ユーザが入力した検索ワードをレスポンスに表示する keyword = requestobj.param[:keyword] # keywordにScriptなどが入力されると ..
responsehtml = “<body>” + escape(keyword) + “の検索結果一覧” + ”</body>” エスケープ用の関数を経由させて出力させよう ※例であって、Juice Shopのコードがこの通りになっているというわけでないです！ 105 ©MIXI

第二問 OWASP Top10では 106 • (API)Injection • (Web)Injection • 攻撃コードを「注入」し実行させること全般を指す。
• SQL injection • Cross site scripting • OS command injection • etc ©MIXI

第三問安く（不正に）購入してみよう • 普通、商品の個数は1個以上しか買えない（当然）ものです。しかしJuice Shopでは実はマイナスの個数の注文ができます！ 107 それを行ってみましょう。 ©MIXI

第三問安く（不正に）購入してみようヒント • カート内の数量変更時の通信を見てみよう。 • 108 https://[環境URL]/api/BasketItems/{n} ©MIXI

第三問安く（不正に）購入してみようさすがにマイナスの値段で決済が進むとは考え答え • 数量にマイナスをつける • にくいけれど、 {"quantity":-2} 100円の商品Aを
-9個と、 1000円の商品Bを1個とを併せて買えば、 100円でBを1個買えるのは現実的かも？おとく！ 109 ©MIXI

第三問安く（不正に）購入してみようさすがにマイナスの値段で決済が進むとは考え答え • 数量にマイナスをつける • にくいけれど、 {"quantity":-2} 100円の商品Aを
-9個と、 1000円の商品Bを1個とを併せて買えば、 100円でBを1個買えるのは現実的かも？おとく！ Juice Shopのような現物を取引するサービスならば発送段階などで攻撃に気づけるかもしれないが、電子マネーのチャージやゲーム内通貨など、現物やり取りが行われないサービスの場合、気づくこともできない可能性があるので注意！例えばオーブでガチャをまわすとき、オーブ数量をマイナス指定するとオーブが増えたりするとか..... 110 ©MIXI

第三問問題点 • 入力値の検証が適切に行われていない対策 • 入力値検証では「仕様的におかしくないか？」もチェックする • Syntax的におかしくないか？は検証していても（[0-9]+じゃないと弾かれる等）、「仕様や意味を考えた
ときにおかしい値の検証」が漏れることもあるので注意。 • 例えば生年月日なら、仮に自然数の入力であったとしても、2200年生まれと主張するユーザがいたらおかしくないか？ 111 といった観点でもチェックしよう。 ©MIXI

第三問 OWASP Top10では 112 • (Web)Insecure Design • 「設計上の欠陥」に起因する脆弱性全般を指す。 •
安全な設計が行われていない • 暗号化すべき情報が暗号化されていない • ロジックの検証が不十分なため仕様外の操作が可能になっている ©MIXI

第四問 adminユーザとして会員登録しよう（権限昇格）普通に会員登録すると、当然ながら作成したユーザはユーザ権限しか持ちません。しかしうまく脆弱性を突くと、管理者権限を有するユーザを作成できるぞ！ 113 ©MIXI

第四問 adminユーザとして会員登録しよう（権限昇格）ヒント1 • 会員登録フォーム（https://[環境URL]/api/Users）の通信を見てみよう。どこか怪しいところはない？ 114 ©MIXI

第四問 adminユーザとして会員登録しよう（権限昇格）ヒント2 • 115 レスポンスの「"role":"customer"」部分が怪しい！ ©MIXI

第四問 adminユーザとして会員登録しよう（権限昇格）答え • 「,"role":"admin"」を無理やりjsonに付与した、下記のような値で会員登録する。 {"email":"[email protected]","password":"hogehoge","passwordRepeat":"hogehoge","securityQuestion":{"id":4,"question":"Father's birth date? (MM/DD/YY)","createdAt":"2021-04-20T09:20:42.365Z","updatedAt":"2021-04-20T09:20:42.365Z"},"securityAnswer":"f","role":"admin"} 会員登録時のレスポンスのJsonを確認し、"role"がadminになっていればクリアー！
116 ©MIXI

第四問問題点 • role という追加パラメータの内容が解釈されて、ユーザ権限では本来実行できない会員作成が行われてしまった。対策 • ユーザ権限によるリクエストの場合は、「"role":"customer"」部が変更され得ないようにする。 •
Juice Shop側（作り手側）としては「"role":"customer"」は本来の処理では送られてこないパラメータなので、対策観点から漏れやすい問題なのかもしれません。だからこそ注意をはらう必要があります。 117 ©MIXI

第四問 OWASP Top10では • (API) Broken Object Property Level Authorization
• 入力値のフィルタリングを行わずにデータにバインディングしてしまう問題のこと。 • 今回の出題のように、「role」プロパティの値を指定する入力値を追加された際、それをフィルタリングせずに評価してしまい、結果、意図しない権限を付与してしまう等 118 ©MIXI

総合演習攻撃者の気持ちになって、管理者アカウントに不正アクセスする流れを再現しよう！やっていき 119 ©MIXI

総合演習流れ 1. 管理者用ページを見つけよう 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみよう 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう
4. 「[email protected]」ユーザでログインしよう 5. adminユーザでログインしよう ※演習前にログアウトしておくことやっていき 120 ©MIXI

総合演習 1. 管理者用ページを見つけようまずは情報収集 121 ©MIXI

総合演習 1. 管理者用ページを見つけようヒント1 • https://[環境URL]/#/search のHTMLソースを見てみよう。まずは情報収集 122 ©MIXI

総合演習 1. 管理者用ページを見つけようヒント2 • https://[環境URL]/#/search のHTMLソースを見てみよう。 • さらにmain.js内のpath部分を見てみよう。まずは情報収集
123 ©MIXI

総合演習 1. 管理者用ページを見つけよう答え • https://[環境URL]/#/administration が管理者ページ • 開発者ツールで、main.js内を「administration」で検索すると見つかる。 •
アクセスしても403エラーになると思います。権限が足りないのでそれでOK。このページに不正アクセスできたら悪さできそうだな 124 ©MIXI

総合演習 1. 管理者用ページを見つけよう答え • https://[環境URL]/#/administration が管理者ページ • 開発者ツールで、main.js内を「administration」で検索すると見つかる。 •
アクセスしても403エラーになると思います。権限が足りないのでそれでOK。このページに不正アクセスできたら悪さできそうだな 125 ©MIXI

総合演習 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみよう不正アクセスのためにSQLインジェクションを狙う 126 ©MIXI

SQLインジェクションとは？アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法のこと。また、その攻撃を可能とする脆弱性のこと。参考 - (IPA) 安全なウェブサイトの作り方 - 127 https://www.ipa.go.jp/files/000017316.pdf
©MIXI

SQLインジェクションによって想定される被害 128 • 非公開情報の漏洩 • 情報の改ざん • データの削除・破壊 • 認証回避による不正ログイン
• など ©MIXI

コード的な話＜脆弱なコード例（Ruby）＞ username = requestobj.params[:name] query = “INSERT INTO users
(name, description) VALUES (username, \“hogehoge\")” SQL.query(query) 129 • この例では、ユーザの入力値をそのままSQLクエリに使用しています。 • 「"」などを挿入されることにより、想定しないSQLクエリが生成されます。 ©MIXI

コード的な話以下のSQL文を入力した場合 • 「joe", "somebody"); DROP TABLE users; --」作られるSQL文は以下のようになります。
INSERT INTO users (name, description) VALUES ("joe", "somebody"); DROP TABLE users; --", "hogehoge"); 上記のSQLインジェクションでusersテーブルが削除されてしまいます。。 130 ©MIXI

SQLインジェクションの対策プレースホルダという仕組みを使うことが対策となる。 INSERT INTO users (name, description) VALUES (username, "hogehoge");
最初にSQL文の構造を決定しておく仕組みが「プレースホルダ」 INSERT INTO users (name, description) VALUES (?, ?); ポイント • SQLを準備する段階で SQL文の構文が確定し、後から SQL構文が変化することがないため安全。 • 「 joe“, “somebody“); DROP TABLE users; -- 」という入力がされた場合、description箇所が当該文字列になるだけになる。 131 ©MIXI

プレースホルダ以外の対策 ※プレースホルダが根本的対策。併せて実施しておくと良いという意味での紹介。 • 入力値チェック • 文字種、桁数、取り得る値のリスト等の範囲を仕様として絞り込める場合、もれなく入力値チェックを行うことは有効である • その際の入力値チェックはブラウザ上で動作するJavaScriptによるのではなく、Webサーバ側のアプリケーションプログラムによって行う必要がある。
• 特殊記号対策 • シングルクォーテーション「'」のエスケープ • 132 例「'」⇒ 「''」等 ©MIXI

余談おそらく実際に皆さんが書く処理はこんな感じ（Rubyの例） username = requestobj.param[:name] userprofile = User.where(username: username).profile
view(userprofile) • あれ？ SQL文いなくない? • フレームワークによってSQLはコーディングから隠蔽されていることが多いかもしれない • 正直、モダンなフレームワークを使っていれば勝手に対策されていることもあるので、SQLインジェクションが作りこまれるケースは少ないかもしれない • 逆に言えばコーディングしているだけでは危険性を知れないかも、とも言えるので、今のうちに原理をちゃんと抑えておきましょう 133 ©MIXI

総合演習 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみよう不正アクセスのためにSQLインジェクションを狙う 134 ©MIXI

総合演習 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみようヒント1 • アプリケーションがSQLを発行していそうな機能を探し、構文を崩す。この辺。 • https://[環境URL]/rest/user/login
• https://[環境URL]/rest/product/search?q=Apple 不正アクセスのためにSQLインジェクションを狙う 135 ©MIXI

総合演習 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみようヒント2 • ログイン時のSQL文（想像） • •
SELECT * FROM xxxx WHERE id = 'test@example' and password = 'password123'; 検索時のSQL文（想像） • SELECT * FROM xxxx WHERE name like = '%Apple%'; 不正アクセスのためにSQLインジェクションを狙う 136 ©MIXI

総合演習 2. SQL Syntaxエラー（SQLITE_ERROR）を出してみよう答え • SQL文に利用される送信パラメータの末尾等にシングルクォーテーション「'」等を入れることで、意図的にSQLシンタックスを壊す。 •
https://[環境URL]/rest/user/login • • の「email」の値を改ざん SELECT * FROM xxxx WHERE id = 'test@example'' and password = 'password123'; https://[環境URL]/rest/product/search?q=Apple の「q」の値を改ざん • SELECT * FROM xxxx WHERE name like = '%Apple'%'; SQLインジェクションできる場所を見つけたぞ！ 137 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう SQLインジェクションでいざ情報奪取！ 138 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そうヒント1 • ログインのリクエストを見てみよう。 • • https://[環境URL]/rest/user/login 先ほどのログイン時のSQLITE_ERROR内容から、テーブル名、カラム名が判明している。つまりこ
こで発行されるSQL文は下記のよう。 • "SELECT * FROM Users WHERE email = '[email protected]' AND password = 'b0baee9d279d34fa1dfd71aadb908c3f' AND deletedAt IS NULL" SQLインジェクションでいざ情報奪取！ 139 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そうヒント2 • UNIONという仕組みを使ってみよう。 SQLインジェクションでいざ情報奪取！ 140 ©MIXI

UNIONとは 2つ以上のSELECT文の結果を統合する仕組みのこと。 name kind nakigoe name kind nakigoe name nickname
syumi pochi dog wanwan pochi dog wanwan yamada yamachaso tozan tama cat nyaaaaaan!!! tama cat nyaaaaaan!!! tanaka nakata nyaaaaaan!!! yamada yamachaso tozan tanaka nakata nyaaaaaan!!! UNION SELECT name,kind,nakigoe FROM animals UNION SELECT name,nickname,syumi FROM friends; 商品テーブルのselect結果は/searchのレスポンスに出力されてくることは分かっている。では、その出力結果にUsersテーブルを結合(UNION)できればUsers情報を抜き出せる！ ※UNIONでつなぐデータの表は、カラム数と型を統一しないとエラーになるので注意。 141 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう答え • 商品検索機能に下記のようなリクエストを送信することで、SQLインジェクションにより商品テーブルとUsersテーブルの情報が結合され、ユーザ情報を取得できます。 • /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8,9%20F ROM%20Users-•
※%27は「'」、%20は「」をそれぞれURLエンコードした値 SQLインジェクションでいざ情報奪取！ 142 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう解説まずはSQLエラーから収集できた情報を整理してみよう。 • 商品検索時のSQLエラーから収集できたProductsテーブルの情報 • SELECT *
FROM Products WHERE ((name LIKE '%APPLE'%' OR description LIKE '%APPLE'%') AND deletedAt IS NULL) ORDER BY name • • テーブル名： Products • カラム名： name, description, deletedAt ログイン時のSQLエラーから収集できたUsersテーブルの情報 • SELECT * FROM Users WHERE email = '[email protected]'' AND password = '79ac8e0c5fbb7fffa893660a9f581303' • テーブル名： Users • カラム名： email, password ← 欲しいのはコレ！ SQLインジェクションでいざ情報奪取！ 143 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう解説次に、ProductsテーブルとUsersテーブルの結合を試してみると。。 • SELECT * FROM Products
WHERE ((name LIKE '%APPLE%')) UNION SELECT email,password FROM Users––%' OR description LIKE '%Apple'%') AND deletedAt IS NULL) ORDER BY name すると、下記のエラーになるはずです。 • SQLITE_ERROR: SELECTs to the left and right of UNION do not have the same number of result columns • UNION時には、連結するカラム数を同じにする必要があります。 SQLインジェクションでいざ情報奪取！ 144 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう解説 name description deletedAt ? ? ?
? ? ? Apple Juice The all-time classic. null ? ? ? ? ? ? Apple Pomace hoge null ? ? ? ? ? ? UNIONするためにはカラム数を統一する必要がある。でもProductsのカラム数は不明。 SELECT * FROM Products WHERE ~~~ email password 3 4 5 6 7 8 9 [email protected] 3c2a~~ 3 4 5 6 7 8 9 [email protected] 963e~~ 3 4 5 6 7 8 9 UNION カラム数を合わせるために、ダミー値の3,4,5...を順番に足していく。 9まで足すとカラム数がそろい、UNIONが成功する。 SELECT email,password,3,4,5,6,7,8,9 FROM Users-- SQLインジェクションでいざ情報奪取！ 145 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう解説つまり、カラム数が合うまで下記のように試行を続けると、エラーが発生しなくなる時が訪れる。それが答え。 1. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password%20FROM%20Users–– 2. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3%20FROM%20Users––
3. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4%20FROM%20Users–– 4. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5%20FROM%20Users–– 5. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6%20FROM%20Users–– 6. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7%20FROM%20Users–– 7. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8%20FROM%20Users–– 8. /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8,9%20FROM%20Users–– SQLインジェクションでいざ情報奪取！ 146 ©MIXI

総合演習 3. SQLインジェクションを悪用して、全ユーザの情報（Eメール、パスワードハッシュ）を抜き出そう答え（再掲） • 商品検索機能に下記のようなリクエストを送信することで、SQLインジェクションにより商品テーブルとUsersテーブルの情報が結合され、ユーザ情報を取得できます。 • /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8,9%20F ROM%20Users-•
※%27は「'」、%20は「」をそれぞれURLエンコードした値ユーザー一覧の情報を奪取できた！ 147 ©MIXI

総合演習 4. 「[email protected]」ユーザでログインしよう試しにこいつに不正アクセスしてみよう 148 ©MIXI

総合演習 4. 「[email protected]」ユーザでログインしよう答え • Emailの値を「[email protected]'--」にする • SELECT * FROM
Users WHERE email = '[email protected]'--' AND password = 'c4ca4238a0b923820dcc509a6f75849b' AND deletedAt IS NULL 不正アクセスできた！ 149 ©MIXI

総合演習 5. adminユーザでログインしよういざ、管理者ユーザーに不正アクセスしてみよう！ 150 ©MIXI

総合演習 5. adminユーザでログインしようちなみに、突破の仕方は2種類あります • なお、パスワードはadmin001 ~ admin999のどれかです。いざ、管理者ユーザーに不正アクセスしてみよう！ 151
©MIXI

総合演習 5. adminユーザでログインしよう答え1 • 先ほど取得したユーザ情報の一覧から、adminユーザのEメールは「[email protected]」と分かる。これに対し、Eメールの値を「[email protected]'--」とし、SQLインジェクションによるパスワード不要でのログインを行う。 • SELECT
* FROM Users WHERE email = '[email protected]'--' AND password = 'XXXXXXXXXXXXXX' ログインできたら、冒頭で見つけた管理者ページ「https://[環境URL]/#/administration」にアクセスしてみよう。アクセスできるようになっているはず！管理者機能にアクセスできた！ 152 ©MIXI

総合演習 5. adminユーザでログインしよう答え2 • BurpSuiteの「Intruder」を利用し、総当たり攻撃を行うことでパスワードを割り出せる。 • ※今回は簡略化のために300通りで値を総当たりしましたが、実際はもっと大量の値を総当たりしたり、既にどこかから漏洩したパスワードのリストを試行する可能性が高いです。管理者機能にアクセスできた！
153 ©MIXI

総合演習 OWASP Top 10でいうところ • (Web)Injection • XSSのときに登場した問題。入力値からコードを注入できてしまう問題。 • SQLインジェクションができてしまった点がこれに該当。
• (API) Broken Authentication • (Web) Authentication Failures • • 認証機能をセキュアに実装できていないという問題。 • SQLインジェクションや総当たりをすることで不正に認証を突破できてしまった点がこれに該当。 (API) Unrestricted Resource Consumption • リソースの要求サイズや数に制限が設けられていないという問題。 • 画像アップロード機能などで巨大ファイルをアップしたり何回も繰り返すことで負荷を掛けたりできちゃう。 • 今回でいうとログイン試行が無数に行える(途中でロックアウトされない)点がこれに該当。 • 154 リソース消費とは意味合いが違うが試行制限が無いことによる問題という点で該当するという解釈 ©MIXI

注意実運用中のWebサーバやWebアプリに対し、絶対にハッキングしないでください。不正アクセス禁止法違反で法的責任に問われる事になり得ます。 155 ©MIXI

【余談】BurpSuiteってどんなツール？ • BurpSuiteってなんでHTTPS通信を見られてるの？ • • 実はBurpSuiteはMan in the middleなツール •
• • BurpSuiteはクライアントともサーバともSSL/TLSをしているブラウザからするとサーバと通信しているつもりがBurpと通信している • • https って暗号化されてるんだから、経路上から見られんくない？サーバからするとブラウザと通信しているつもりがBurpと通信しているあれ、サーバ証明書は？ • 当然、通常のブラウザでは（FireFoxとかで試すと）警告が出ます • ハンズオンではBurpの証明書が自動で信頼されている環境だっただけフリーWiFi等の信頼できないNWって危ない！！復号できます見れますっ SSLセッションブラウザ 156 HTTPSパケット BurpSuite SSLセッション通信先（Webサイトとか ©MIXI

ハンズオンで紹介しきれなかったOWASP Top 10の脆弱性たち API Web ◦ Broken Object Level Authorization
◦ Broken Access Control ◦ Broken Authentication ◦ Security Misconfiguration ◦ Broken Object Property Level ◦ Software Supply Chain Failures ◦ Cryptographic Failures ◦ Injection ◦ Insecure Design ◦ Authentication Failures ◦ Software and Data Integrity Failures ◦ Security Logging and Alerting Failures ◦ Mishandling of Exceptional Conditions Authorization ◦ Unrestricted Resource Consumption ◦ Broken Function Level Authorization ◦ Unrestricted Access to Sensitive Business Flows ◦ ◦ 157 Server Side Request Forgery Security Misconfiguration ◦ Improper Inventory Management ◦ Unsafe Consumption of APIs ©MIXI

(API/Web) Security Misconfiguration 不適切な設定をしてしまったことにより発生する問題全般 • 158 例 • 古いバージョンのTLSが有効なまま •
ライブラリ/フレームワーク等の設定値がセキュアでない ©MIXI

(API/Web) Security Misconfiguration 想定される被害ケース例 • 幅が広いため多岐にわたるが、例えば設定不備に起因する脆弱性が突かれサーバ内部に置いていたファイルが漏洩する 159 等 ©MIXI

(API/Web) Security Misconfiguration 対策 • これ！というものは無い（使っているものによって着眼点は変わるため）が下記は意識を持っておくと良いと思います。 • 開発やQA、本番環境それぞれで同じ設定になるようにする
• • 必要ない機能/コンポーネントは除いておく • 160 検証時はセキュアだったが、本番環境の設定では脆弱だったというリスクを減らすコンポーネントの数だけ設定ミスで穴が開くリスクは増える ©MIXI

(API) Improper Inventory Management 公開想定でないAPIエンドポイントが公開されていて、攻撃者がそこを突いて攻撃してくる脆弱性。 • 161 例 • 古いAPIバージョンが残存したままになっている
• デバッグ用APIが公開されている ©MIXI

(API) Improper Inventory Management 想定される被害ケース例 • https://hoge.fuga/v1/loginへの総当たりについてはRate limitが設けられているが、 • https://hoge.fuga/beta/loginへはRate
limitがされておらず、攻撃者はこちらを使って総当たり攻撃からの不正アクセスを行う 162 ©MIXI

(API) Improper Inventory Management 対策 • 公開するものは守る。守れていないものは公開しない。 • /v1, /v2で例えると、/v1を残存させるならv1は守る。/v1が脆弱なら公開を廃止する。
• それをクリアに把握しておけるように、ドキュメント管理をしっかりしておきましょう。 • このAPIは残っていていいのか？ • 等の判別のため。 ※ドキュメントこそ命という話ではなくて、何を公開して何を守るのかクリアになっているのが肝。ドキュメント管理はそのための手段。 163 ©MIXI

(Web) Security Logging and Alerting Failures ロギング/監視が不十分なため、攻撃が行われた際に適切に対処することができない状況になっている問題。 • 164
例 • ログが無いため、侵入者が何を行ったか分からない。影響範囲が特定できない。 • 監視が無いため、侵入者の存在に気づけない。 ©MIXI

(Web) Security Logging and Alerting Failures 想定される被害ケース例 • AWSアカウントにて、ある日コインマイニングを行っているEC2インスタンスを発見した。 •
原因を調べたところ、EC2を立てる権限を持ったユーザのアクセスキーが漏洩し、不正アクセスされたようだった。 • しかし、該当アクセスキーAPIログを残していなかったため、悪用被害範囲を特定することができなかった。 165 ©MIXI

(Web) Security Logging and Alerting Failures 対策 • ログはできるだけ残しておく。 •
攻撃が行われたら気づけるように監視をする。 • AWS/Google Cloudについてはセキュリティ室側の監視設定を施してあるアカウントであれば、一定の監視/ ログ取得は行われています。 • 攻撃が行われた場合はアラートが鳴る。 • 管理系のログ（ユーザXがhogeというAPIをいつに実行した程度）は取得している。 • 逆に言うと、エンドユーザのアクセスログ等は各自で取得しておくようにしましょう。 • 166 認証失敗や不正行為の疑いのログなど。 ©MIXI

(Web) Cryptographic Failures 暗号化に関連した問題があり、その結果として機微情報が漏洩しうる脆弱性の総称。 • 以前のverのTop 10では「機微な情報の露出」という名前で類似の問題が紹介されていた。「機微な情報」とはなんぞや？どう取り扱うべきか？について顕著な例を二つご紹介。
今回は以下を（簡単に！）取り上げてみます 167 • クレジットカード • パスワード ©MIXI

クレカ情報を取り扱うときには • 非保持化しなさい！（原則） • 保持するならPCIDSS に準拠しなさい！参考 • クレジットカード・セキュリティガイドライン
• 168 https://www.meti.go.jp/policy/economy/consumer/credit/2103creditsecurity.html ©MIXI

非保持化について非保持とは • 『保存』『処理』『通過』をすべて行っていない状態のこと。 • 保存 • • 処理
• • コールセンターにて顧客のクレカ情報をPC入力。etc,, 通過 • 169 DBに保存。スプレッドシートに保存。etc,, 顧客のPC→自社サーバ→決済代行会社サーバという流れでクレカ情報を送信。etc,, ©MIXI

非保持化について「非保持化？保存さえしなきゃいいんでしょ？」 ↑ダメ！！たとえ保存していなくても、例えば以下は『通過』にあたるのでＮＧ。顧客のブラウザやスマホ 1111-2222-3333-4444 加盟店のサーバ
（皆さんのwebサイト等）決済代行会社 1111-2222-3333-4444 決済時は決済代行会社側のシステムに遷移させる等して、カード情報が自分たちのサーバを経由しないようにしましょう！ 170 ©MIXI

PCIDSS準拠について PCIDSSとは • Payment Card Industry Data Security Standard
• クレジットカード会員データを安全に取り扱う事を目的として策定された、クレジットカード業界のセキュリティ基準のこと。 • 国際カードブランド5社(American Express、Discover、JCB、MasterCard、VISA)が共同で設立した PCI SSC(Payment Card Industry Security Standards Council)によって運用、管理されている。「非保持化」をやらないなら、この基準を守れ！ということ。詳細は割愛ｍｍ 171 ©MIXI

クレジットカード情報の流出で想定される被害 • カード利用者への不利益 • • 攻撃者に使われる • 本人認証が弱いプリペイドカードにチャージ • 偽造カードを作成し利用
攻撃者に売られる • • 172 ブラックマーケットで換金事業者への不利益 • お客様へのお詫びコスト • 不正に行われた買い物の損害賠償 • カード決済の一時停止措置 • コールセンター対応コスト • 再発防止コスト • 信頼を失う！ ©MIXI

パスワードを取り扱うときはパスワードを保存する際、そのまま保存しないこと。 • 「データが盗まれてもパスワードは盗まれない」を目指す。 • ソルトと呼ばれるユーザごとに異なる文字列と連結した値を、ハッシュ化したうえで保存するのが良い。 • 単にパスワードをハッシュ化しただけだと解析されてしまう可能性があるので注意。 •
• 引用元：https://www.ipa.go.jp/files/000017316.pdf, (2025/4/27) 173 ©MIXI

クレカとパスワードの話のまとめ • • クレジットカードの取扱い方 • 非保持化する • しないならPCIDSSに準拠(監査なども含む) パスワードの取扱い方 •
盗まれたとしても解析困難な形で保存する • 具体的には「ソルト付きハッシュ」という形式がセキュアな保存形式 • ストレッチングと呼ばれる、ハッシュ化するとき何千、何万回とハッシュ化を繰り返すことでログインに時間がかかり、総当たり攻撃のために必要な時間を増やす手法も併せるとなおセキュア 174 ©MIXI

(Web) Software Supply Chain Failures ソフトウェアサプライチェーンに関する問題全般 • 175 例 •
信頼できるベンダーがマルウェアに感染してしまい、マルウェアを含んだパッチが配布される • 脆弱性が残っているバージョンのライブラリを使用している ©MIXI

(Web) Software Supply Chain Failures 想定される被害ケース例 • • SolarWinds事件（2020年） •
SolarWinds社が攻撃者の侵害を受け、Orionという製品のアップデートにマルウェアが仕込まれた • これにより、世界中の約18,000の組織にマルウェアが配布された JVNDB-2021-005429 • Log4jというJavaライブラリの脆弱性 • 上記脆弱性が存在するバージョンのLog4jを使用していたために、攻撃者からインターネット経由で任意コード実行が行われる可能性 176 ©MIXI

(Web) Software Supply Chain Failures 対策 • 脆弱性情報をウォッチしておく • CVE(Common
Vulnerability and Exposures)やNVD(National Vulnerability Database)など • 177 なお、脆弱性情報の見方については後ほどの章で別途説明します • 不要なコンポーネントは取り除いておく • SBOM（Software Bill of Materials：ソフトウェア部品表）を活用する ©MIXI

SBOMとはソフトウェアを構成するコンポーネントや依存関係などを一覧にまとめたもので、適切に運用することでソフトウェアサプライチェーンのセキュリティ確保に有効とされている • アメリカでは2021年の大統領令で、SBOMの提供が政府調達の必須条件に含まれている • EUでも2024年に発効されたEUサイバーレジリエンス法でSBOMの作成や管理が求められている • • EU圏内でサービスを展開する場合、サイバーレジリエンス法の適用対象になるかもしれない
日本国内でも、JC-STARと呼ばれるIoT製品向けのラベリング制度で、4段階あるうちのレベル3からSBOMの作成と運用が要件に盛り込まれている。経産省 - ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver2.0 https://www.meti.go.jp/policy/netsecurity/wg1/SBOMv2.pdf IPA - SBOM導入・運用の手引き https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/sbn8o10000001y6j-att/sbn8o10000001zcl.pdf 178 ©MIXI

(Web) Software and Data Integrity Failures 悪意あるコードがコンポーネントに含まれている（含まれうる）問題。 • 外部ファイルを読み込む際、悪意あるものを指定されるかもしれない •
読み込んでいるコードは改ざんされているかもしれない • シリアライズデータが改ざんされて攻撃コードを注入されるかもしれない想定される被害ケース例 • あるWebアプリでは、生成したオブジェクトをシリアライズしてCookieに保存し、そのオブジェクトが必要な際、Cookie値をデシリアライズして使用する仕様だった • 攻撃者はCookie値を改ざんし、オブジェクトのデストラクタに攻撃コードを忍ばせたシリアライズデータをWebアプリに送信した • 179 すると、デストラクタ実行時、攻撃コードが実行された ©MIXI

(Web) Software and Data Integrity Failures 対策 • 外部ファイルを読み込む際、悪意あるものを指定されるかもしれない •
外部からのファイルを読み込む際、想定していない外部ファイルを読み込まれない設計にする。例えばクライアントからURLを受け取り、そのURLのコードをそのまま読み込むといった構成を避ける。数値を受け取り、その数値と紐づいたファイルを読み込む等。 • 読み込んでいるコードは改ざんされているかもしれない • • 読み込むコードの署名を検証する。シリアライズデータが改ざんされて攻撃コードを注入されるかもしれない • そもそもシリアライズデータでオブジェクト等のコードを送受信する必要があるか見直す。 • データの暗号化や署名付与を行い改ざんをできなくする。共通するのは「悪性コードを組み込ませられないようにする」 180 ©MIXI

(API) Server-Side Request Forgery (SSRF) アプリケーションを踏み台にして、内部/外部サーバにリクエストすることができる脆弱性。想定される被害ケース • ポートスキャン •
ファイル内容の読取 • DoS 指定されたサーバに処理を中継し、ポートスキャン/ファイル読出/DoS等を行う脆弱なアプリ URLを指定するパラメータに外部サーバのポートやファイルを指定してリクエスト 181 外部サーバ外部サーバからすると、攻撃してきているのは脆弱なアプリのように見える（踏台にされる） ©MIXI

(API) Server-Side Request Forgery (SSRF) 対策 • • ネットワーク層(対策というより被害軽減策) •
SSRFが発生しうる機能をNW的に分離する • 想定している通信先以外への通信をFWでブロックするアプリケーション層 • そもそも、リクエスト先URLをクライアントから直接受け取る構成をやめる。 • 動的にリクエスト先を変えたい場合、固定値を受け取るようにする。例えば数値を受け取り、それに紐づいた URLにアクセスするなど。 • 182 入力値検証を行う。 • ホワイトリスト形式で検証する。 • ブラックリスト形式や正規表現で検証すると、バイパスできる可能性が出てくるため極力行わない。 ©MIXI

(API) Unrestricted Access to Sensitive Business Flows 機密性の高いビジネスフローに攻撃者が何度も(自動化して)アクセスし、ビジネス的損害が出る脆弱性。想定される被害ケース例 •
製品の購入 • • コメント,投稿 • • 攻撃者によりスパム投稿を繰り返される予約 • 183 攻撃者により需要の高い商品の在庫がすべて購入、転売される攻撃者によって片っ端から予約をされ、正常なユーザがシステムを使用できなくなる ©MIXI

(API) Unrestricted Access to Sensitive Business Flows 対策 • ビジネス面
• • システム面 • 184 過度に使用するとビジネスに悪影響を及ぼす可能性のあるビジネスフローを特定。自動化された処理を検出しブロックする • キャプチャ認証 • user-agentなど検証 • Tor出口や既知のブラックリストIPからのアクセスをブロック • ビジネスロジック的に明らかにおかしい挙動をブロック(カートに追加→購入まで1秒未満とか) ©MIXI

(API) Unsafe Consumption of APIs 外部のAPI経由の入力値を過信して検証を疎かにした結果、そこ経由で攻撃される脆弱性想定される被害ケース例 • 被害アプリにはプロフィール情報を、外部SNSのAPI経由で取得し処理するロジックがあるとする •
そのロジックにおいては入力値を信頼しており、検証をいっさい行っていなかった • 攻撃者はSNSのプロフィールに対して事前に攻撃コードを忍ばせておく • • ユーザ名を「'; drop database db;–」とかで登録しておく被害アプリが攻撃者のプロフィール情報を処理するとき、そのAPIから得た入力値を信頼してしまっているので攻撃コードが動作する 185 ©MIXI

(API) Unsafe Consumption of APIs 対策 186 • ユーザからの直接の入力値だけでなく、外部から得る値は必ず疑いの目を持って検証する •
通信経路で改ざんが行われないよう暗号化(TLS)のうえで通信する ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 187 次はここの話！サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など ©MIXI

自分たちでは作り込まないが、脆弱性になりうるもの • ミドルウェアやライブラリ • • 脆弱性が潜んでいて、そこを突かれる可能性があるので適宜バージョンアップが必要外部組織に開発委託した成果物 • 委託したコードの中に脆弱性がある可能性もあるので脆弱性診断等でチェックする必要がある。 •
皆さんが直近の業務で関わる機会は少ないかもしれませんが、委託だから丸投げでOKというわけではなく、きちんと自分たちで品質を確認しなきゃいけないという認識は持っておきましょう。 188 ©MIXI

脆弱性対応時、調査のポイント外部ライブラリ等の脆弱性対応は、 • 脆弱性があったら • それを評価し • 必要に応じそのモジュールをアップデートするという流れになる。その際の評価ポイントは下記になる。 •
どのソフトウェア？ • どのバージョン？ • どんな影響ある？ • どれくらい深刻なの？ • どう対策すればいい？こういった情報の概要がまとまった脆弱性情報メディアに「CVE」がある。 189 ©MIXI

CVEとは？ • Common Vulnerabilities and Exposuresの略。 • CVEとは、米MITRE（マイター）社が提供している、脆弱性を識別するための共通脆弱性識別子。 • 一般的にCVE番号、CVE
IDと呼ばれている。 • 例：CVE-2020-8165 • ※命名規則は、「CVE-YYYY- NNNN…N 」のようになっている。「YYYY」は発見された年数、NNNN…N は一意の番号。 190 ©MIXI

CVEの見方 • 例えば『CVE-2025-55182』なら、下記のようにCVEのサイトのname部分にIDを指定すれば確認できます。 • • https://www.cve.org/CVERecord?id=CVE-2025-55182 見ると良い項目 • Description：脆弱性概要が記載されている。
• CVSS：脆弱性の危険性を表すメトリクスが記載されている。（記載されていない場合もある） • Product Status：ベンダー名や製品名、影響を受けるバージョンが記載されている。 • References：参考URLが記載されている。引用元：https://www.cve.org/CVERecord?id=CVE-2025-55182,(2026/4/30) 191 ©MIXI

詳細な脆弱性情報をみるにはNVD 192 • National Vulnerability Database • NIST(アメリカ国立標準技術研究所)が管理している、脆弱性情報データベースのこと。 • CVEで命名された脆弱性情報の詳細情報をNVDで提供している。
©MIXI

NVDの見方 CVE-2025-55182の例 • URL：https://nvd.nist.gov/vuln/detail/CVE-2025-55182 • 見ると良い項目 • Current Description •
• Severity • • 関連する情報へのリンク。 Known Affected Software Configurations • 193 「CVSS 」の情報。脆弱性の深刻度。 References to Advisories, Solutions, and Tools • • 脆弱性の概要説明。影響を受けるソフトウェアとバージョン。引用元：https://nvd.nist.gov/vuln/detail/CVE-2025-55182, (2026/4/30) ©MIXI

CVSSとは • Common Vulnerability Scoring System • 脆弱性の深刻度をスコア（数値）で表すシステム。 • •
計算式に則り、脆弱性を0～10.0までの値で評価。 • 10.0が最も深刻。〜V4まである。 • 194 NVDをチェックしていくとするとV3を目にすることが多いかも。 ©MIXI

CVSS (V3) の見方 CVSSはVectorと呼ばれる下記の要素から算出されます。 • AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 例 • AV：N ー＞
攻撃元区分：ネットワーク • AC：L ー＞攻撃条件の複雑さ：低 • PR：N ー＞必要な特権レベル：不要 • UI：N ー＞ユーザ関与レベル：不要 • S：U ー＞スコープ：変更なし • C：H ー＞機密性への影響：高 • I：H ー＞完全性への影響：高 • A：H ー＞可用性への影響：高このScoreは9.8 (Critial)！ 195 ©MIXI

脆弱性情報 (NVD/CVSS) の見方の勘所脆弱性情報をどう読んだらいいか分からない場合、ひとまず以下の観点を確認すると良いと思います。 • 自分たちが対象製品、バージョンを使っていないか確認する。 • 攻撃元区分から攻撃者像を想定する。 • その攻撃者ができることを想定する。
• 該当ソフトウェアを使っていたとしても、特定の条件でのみ悪用可となるケースもある。実際のところその脆弱性を悪用できるのか？というところまで考えられるとサイコーです。例 • 自分たちが対象製品、バージョンを使っていないか確認する。 • NVDのKnown Affected Software Configurations欄を確認したところ、自分たちのプロダクトで該当ソフトウェアの該当バージョンを使っていたことが分かった。 • 攻撃元区分から攻撃者像を想定する。 • CVSSの脆弱性の攻撃元区分(AV)を確認したところ、「N」、つまりインターネット経由で攻撃可能と分かった。 • その攻撃者ができることを想定する。 • 196 NVDのDescription欄を確認したところ、任意コード実行ができることが分かった。 ©MIXI

• 該当ソフトウェアを使っていたとしても、特定の条件でのみ悪用可となるケースもある。実際のところその脆弱性を悪用できるのか？というところまで考えられるとサイコーです。例 • • 該当ソフトウェアを使っていたとしても、特定の自分たちが対象製品、バージョンを使っていないか確認する。条件でのみ悪用可となるケースもある。 • NVDのKnown Affected Software Configurations欄を確認したところ、自分たちのプロダクトで該当ソフト実際のところその脆弱性を悪用できるのか？というところまで考えられるとGood！ウェアの該当バージョンを使っていたことが分かった。攻撃元区分から攻撃者像を想定する。 • CVSSの脆弱性の攻撃元区分(AV)を確認したところ、「N」、つまりインターネット経由で攻撃可能と分かった。 • その攻撃者ができることを想定する。 • 197 NVDのDescription欄を確認したところ、任意コード実行ができることが分かった。 ©MIXI

• 該当ソフトウェアを使っていたとしても、特定の条件でのみ悪用可となるケースもある。実際のところその脆弱性を悪用できるのか？というところまで考えられるとサイコーです。例 • こういったことを確認すると、「ヤバそう」かどうかのイメージが付きやすくなると思います！自分たちが対象製品、バージョンを使っていないか確認する。 • NVDのKnown Affected Software Configurations欄を確認したところ、自分たちのプロダクトで該当ソフトウェアの該当バージョンを使っていたことが分かった。 • 攻撃元区分から攻撃者像を想定する。 • CVSSの脆弱性の攻撃元区分(AV)を確認したところ、「N」、つまりインターネット経由で攻撃可能と分かった。 • その攻撃者ができることを想定する。 • 198 NVDのDescription欄を確認したところ、任意コード実行ができることが分かった。 ©MIXI

（補足） • 該当ソフトウェアを使っていたとしても、特定の条件でのみ悪用可となるケースもある。実際のところその脆弱性を悪用できるのか？というところまで考えられるとサイコーです。例 • NVDは危険度の高いCVEを優先的に分析する方針に変わったため、情報が足りない場合は該当製品のベ自分たちが対象製品、バージョンを使っていないか確認する。ンダが発表している情報を見に行くのが良いかもで • NVDのKnown Affected Software Configurations欄を確認したところ、自分たちのプロダクトで該当ソフトすウェアの該当バージョンを使っていたことが分かった。 • https://www.nist.gov/news-events/news/2026/04 攻撃元区分から攻撃者像を想定する。 /nist-updates-nvd-operations-address-record-cve-g • CVSSの脆弱性の攻撃元区分(AV)を確認したところ、「N」、 rowth つまりインターネット経由で攻撃可能と分かった。 • その攻撃者ができることを想定する。 • 199 NVDのDescription欄を確認したところ、任意コード実行ができることが分かった。 ©MIXI

日本の脆弱性情報収集サイト情報のスピードを考慮するとベンダの公式ページ等を見にいくことが多いかもですが、日本のサイトもあります。 • • 200 JVN • Japan Vulnerability
Notes • 日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供 • https://jvn.jp/ JVN iPedia • 国内外問わず日々公開される脆弱性対策情報のデータベース • https://jvndb.jvn.jp/ ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 201 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など次はここの話！ ©MIXI

クライアント側を強固にするには？身も蓋もないがクライアント側を完全に守ることはできない。（攻撃者の手元にプログラムがあるため解析、改造できてしまうため）そのためセキュリティ上の理想的な設計としてはそもそもクライアントでは何も持たず、何も処理せず、ただサーバから受け取ったデータを基に画面描画だけしているのがベスト。ただし実際にはそうもいかずクライアントでもデータを持ったりロジックを動かしたりする必要がある。なので下記を行い、妥当な設計,実装,運用を作りうまいことやってゆかないといけない。 (MIXIはスマホアプリがメインなのでその想定でのお話) 202 •
重要な情報やロジックはクライアントに持たない • モバイルアプリにおける所謂セキュアコーディングをする • ゲームにおけるチートなど完全撲滅できないリスクへの対処をどうするか運用を含めて考え備える ©MIXI

モバイルアプリにおける所謂セキュアコーディングをする Mobile Application Security Design Guideの紹介 https://github.com/OWASP/www-project-mobile-application-security-design-guide • モバイル開発におけるセキュリティ設計が下記観点ごとにまとめられている •
Architecture, Design and Threat Modeling Requirements • Data Storage and Privacy Requirements • Cryptography Requirements • Authentication and Session Management Requirements • Network Communication Requirements • Platform Interaction Requirements • Code Quality and Build Setting Requirements コード例なども交えつつセキュアな設計/実装を包括的に説明してくれているので、モバイルのセキュリティを考えるうえで参考になる。文量多いので悩んだときの辞書として使うと良いと思います 203 ©MIXI

今日頭に入れておきたいモバイルセキュリティの注意点あるあるなもの、影響がデカいもの、事例のあるものたち • データの保管や受け渡しに注意する。 • SDカードやログ等の、他アプリからアクセスできる領域に重要なデータを保存しない。 • カスタムURLスキームでは重要なデータを取り扱わない。 • •
レシート検証はちゃんとしましょう。 • 204 同じカスタムURLスキームを宣言した偽装アプリにデータが渡ってしまうかもしれない。レシート検証周りの参考 • [iOS]https://developer.apple.com/documentation/appstoreserverapi • [Android]https://developer.android.com/google/play/billing/security • コラボ情報など未公開情報を埋め込まない。解析による漏洩対策。 • ゲームの場合、上記に加えて「チート」のリスクも認識/対応しておく。 ©MIXI

今日頭に入れておきたいモバイルセキュリティの注意点あるあるなもの、影響がデカいもの、事例のあるものたち • データの保管や受け渡しに注意する。 • SDカードやログ等の、他アプリからアクセスできる領域に重要なデータを保存しない。 • カスタムURLスキームでは重要なデータを取り扱わない。 • •
レシート検証はちゃんとしましょう。 • • 205 レシート検証周りの参考 • [iOS]https://developer.apple.com/documentation/appstoreserverapi • [Android]https://developer.android.com/google/play/billing/security コラボ情報など未公開情報を埋め込まない。解析による漏洩対策。 • • 同じカスタムURLスキームを宣言した偽装アプリにデータが渡ってしまうかもしれない。実際に埋め込んでしまい未公開情報が漏洩してしまったケースも社内でもあるゲームの場合、上記に加えて「チート」のリスクも認識/対応しておく。 ©MIXI

アプリ内課金の流れこの図はアプリ内課金の流れで、購入したアイテムを付与する前にレシートの整合性を検証してから付与する必要があります。検証が不十分な場合（例えば、偽造されたレシートに対しアイテム付与や、使用済みのレシートが再使用できる）は不正購入による収益損失に繋がる恐れがあります。 206 ©MIXI

アプリ内課金注意事項 • 不正購入の検証方法 ①対レシート偽造 ⇒ クライアントから送られてきたレシートを正しく検証する ※iOSアプリではアプリのBundle IDとレシートのBundle IDが一致しているかも要確認
②対リプレイ攻撃 ⇒ トランザクションIDの一意性を確認し、リプレイ攻撃を防ぐ対策を講じる ※リプレイ攻撃とは悪意あるユーザが過去の正規購入のデータ（購入トークンなど）を再送信して、商品を不正に再度受け取る攻撃です【①の対策例】クライアントから送られてきたレシートを正しく検証する - 各プラットフォームの公開鍵で検証する - iOSアプリの場合はBundleIDの追加チェックも必要 - - サーバ上でデバイスのレシートを検証する https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device PlatformのAPIを使った検証も可能 App Store Server API : https://developer.apple.com/documentation/appstoreserverapi Google Play Developer API: https://developer.android.com/google/play/billing/security?hl=ja#verify 【②の対策例】トランザクション IDの一意性を確認する - 207 レシートに含まれる下記トランザクション識別子をDBに保存しておき、使用履歴を管理し、使用済みのレシートを再度利用できないようにする App Store: transactionId Google Play: orderid ©MIXI

【再掲】今日頭に入れておきたいモバイルセキュリティの注意点あるあるなもの、影響がデカいもの、事例のあるものたち • データの保管や受け渡しに注意する。 • SDカードやログ等の、他アプリからアクセスできる領域に重要なデータを保存しない。 • カスタムURLスキームでは重要なデータを取り扱わない。 • •
レシート検証はちゃんとしましょう。 • • 208 レシート検証周りの参考 • [iOS]https://developer.apple.com/documentation/appstoreserverapi • [Android]https://developer.android.com/google/play/billing/security コラボ情報など未公開情報を埋め込まない。解析による漏洩対策。 • • 同じカスタムURLスキームを宣言した偽装アプリにデータが渡ってしまうかもしれない。実際に埋め込んでしまい未公開情報が漏洩してしまったケースも社内でもあるゲームの場合、上記に加えて「チート」のリスクも認識/対応しておく。 ©MIXI

チートとは • チート（英: cheat）とは騙す、欺くこと。 • コンピュータゲームにおいて、広義には制作者が意図しない方法や結果により使用者が意図的に公平性を損なわせる行為のこと。 • 狭義には、コンピュータゲームにおいて優位に進めるための（バグ等を用いた）不正行為または
ハッキング行為のこと。引用元：https://ja.wikipedia.org/wiki/%E3%83%81%E3%83%BC%E3%83%88, (2026/4/30) 209 ©MIXI

私たち運営側にとってのチートのリスク • • ゲームプレイにおいて不公平が生じてしまう。フェアでない。 • スポーツでいえばドーピング。 • ユーザは冷める。そして運営に対するヘイトが溜まる。ゲームの寿命の短縮。 •
• • すぐクリアされるという直接的な側面と人離れによる間接的な側面。課金数の低下、課金機会の損失。 • チートしている人→チートした方がコスパ良い • チートしていない人→馬鹿らしくなって課金しなくなる関係会社への被害 • 例えばコラボ先の商品を買うとそのIPのキャラデータが手に入るキャンペーンがあったとして、不正にキャラデータを入手できるチートが行われた場合、コラボ先商品の売り上げが下がり、関係会社に対する被害につながる。 • ブランドイメージの低下。 • ユーザ対応コストの増加。 • 210 通報対応/BAN対応/問い合わせ対応など。 ©MIXI

チートの手法チートの手法(弄る箇所)はすごくざっくりと下記４種類に大別できる • • メモリ改変 • メモリの値を書き換える。例えばHPや攻撃力や所持金に相当する箇所のメモリの値を大きくする。 • 対策 •
そもそもサーバに持つべき値はサーバに持つ。所持金とか。 • 加えて、どの値がどのメモリか探り当てられないようにする。なんらか関数を経由した値で保存する等。通信改変 • 通信の送信値を書き換える。JuiceShopで行った攻撃のゲーム版。 • 対策 • • • 不正に書き換えられた値を受理しないよう、サーバ側での検証を徹底する。ローカルデータ改変 • SDカード等のローカル内ストレージの値を書き換える。セーブデータ改変など。 • 対策 • 改変されたくなければローカルに保存しない。サーバ側に保存する。 • やむを得ずローカルに保存する場合は暗号化をして改変の難度を上げる。クライアントアプリ解析・改造（リバースエンジニアリング） • アプリ自体を改造する。クライアント側に持つデータ/ロジックであれば実質的になんでもできる。 • 対策（防ぐことはできないので、難易度を上げる） • コードの難読化 • アプリの改ざんチェック • 211 （改ざんチェックを無効化するように改変することも可能なため、根本的対策にはならないが難度を上げるという意味ではやった方がセキュア。） ©MIXI

メモリ改変プロセスメモリエディタと呼ばれるツールを使用して、メモリに格納される値（HP・攻撃・お金など）を改変する。ゆうしゃ Lv13 プロセスメモリエディタで「500」を検索, 改竄 500 ゆうしゃ
Lv13 検索 1件ヒット ---------------------------000D7DE8 500 HP 500 HP 9999 対策 - そもそもサーバに持つべき値はサーバに持つ。所持金とか。 - 加えて、どの値がどのメモリか探り当てられないようにする。なんらか関数を経由した値で保存する等。 212 ©MIXI

通信改変 Burp Suiteなどを利用し、クライアントとサーバの間の通信を改変する手法。例 213 • ゲームのプレイ結果をサーバに送信する際、スコアを書換える。 • キャラステータスをサーバから受信する際、攻撃力を書換える。 ©MIXI

通信改変の根本的対策 • ユーザに改変されると困る処理はパラメータに持たせない。 • ガチャを引く際、消費オーブ数をパラメータで渡している場合 → オーブ数をパラメータに持たせるのではなく、ガチャIDだけ送るようにする。そうすると消費オーブ数を改変できなくなる。 • 持たせている場合は正当性を検証する。
• 例えば挑戦するステージのIDをリクエストする場合、「このユーザはこのステージに挑戦できる状態か？」をサーバ側で検証する。 214 ©MIXI

通信改変の保険的対策 • 215 以下を併せて実施する。 • パラメータとともにパラメータのハッシュ値も送信するようにし、改ざんチェックを行う。 • SSLを利用するとして、そのうえで • パラメータ全体をアプリケーション層での暗号化をする。
• SSL証明書のPinningを行う。 ©MIXI

通信改変の保険的対策パラメータ全体をアプリケーション層での暗号化をする。パラメータが暗号化されているから改変できない… アプリ 216 BurpSuite等のプロキシツールゲームサーバ ©MIXI

通信改変の保険的対策 SSL証明書のPinningを行う。 BurpSuiteの証明書？信頼できないのでエラー！アプリ 217 BurpSuite等のプロキシツールゲームサーバ ©MIXI

通信改変の保険的対策 SSL証明書のPinningを行う。 BurpSuiteの証明書？信頼できないのでエラー！アプリ 218 【補足】 BurpSuite等の PinningはWebだと廃止の流れがあります（例えばChromeでの廃止）が、ゲームサーバ
プロキシツール・ブラウザ → 運営側がいじれない・自社スマホアプリ → 運営側がいじれるという違いがあるため、不備のある証明書が固定されてしまった場合等の事情も異なってきます。ちなみにAndroidセキュアコーディングガイドでは中間者攻撃への有効策としてPinningが紹介されています。 ©MIXI

ローカルデータ改変ローカルストレージやSDカードなど、ファイルにセーブデータやゲームに関する情報を保存している場合、その値を改変し、チートが可能な場合がある。例 • ゲームのセーブデータをファイルに保存する設計だったとして • ファイル内にあるレベル/hp/atkに相当するパラメータを書き換えることで • ゲーム再起動時、そのファイルに記載されたレベル/hp/atkに強化されている
根本的対策ゲームのセーブデータなど重要な情報はローカルに保存しない。サーバー側に保存する。保険的対策やむを得ずローカルに保存する場合は暗号化をし、改変の難度を上げる。 219 ©MIXI

クライアントアプリ解析・改造アプリ自体の改変。アプリをツールを用いて逆コンパイル/逆アセンブルし、内容を解析、改ざんする手法。行うにはプログラムのロジックを理解する/改造するための技術力が必要になる。プログラム自体を書き換えるということなので、攻撃者の思い通りに任意のロジックを組める。対策解析・改造行為そのものを完全に防ぐことはできない。なるべく解析しづらく、改造しづらくするしかない。 - コードの難読化
- アプリの改ざんチェック（改ざんチェックを無効化するように改変することも可能なため、根本的対策にはならないが難度を上げるという意味ではやった方がセキュア。） 220 ©MIXI

マクロゲームの処理(レベル上げ等単純な処理)を自動化し、ゲーム内で利益を得ようとする手法。一応、ゲームに対して行っていること自体は正規の行動のため厳密にはチートではないこともあるが、「ラクをして強くなる」という点においては近い行為。スマホゲームにおいて行われるマクロの方法はいろいろある。 • エミュレータでアプリを動作させ、PCの操作記録ツールを使用する。 • マクロ用のスマホアプリを使用する。
• 実際のゲームフローで送信される通信リクエストを再現/送信することで、時短ゲームクリア等を行うパターンもある。（これはもはやマクロというより通信改変の亜種かも）。 221 ©MIXI

マクロゲームの処理(レベル上げ等単純な処理)を自動化し、ゲーム内で利益を得ようとする手法。一応、ゲームに対して行っていること自体は正規の行動のため厳密にはチートではないこともあるが、「ラクをして強くなる」という点においては近い行為。スマホゲームにおいて行われるマクロの方法はいろいろある。 • エミュレータでアプリを動作させ、PCの操作記録ツールを使用する。 • マクロ用のスマホアプリを使用する。
• 実際のゲームフローで送信される通信リクエストを再現/送信することで、時短ゲームクリア等を行うパターンもある。（これはもはやマクロというより通信改変の亜種かも。）・クエストがゲーム体験の肝な場合、それを 1秒でクリアできちゃうとかだったらマズそう。・ガチャの演出見ずに早く回せちゃうとかだったら「だからなんなの？」という話でしかなさそう。というように「自分のゲームにおいてマズいのか？」を考える必要がある。そしてマズい場合、対策 (緩和策)を検討する必要がある。 222 ©MIXI

マクロの緩和策 • 通常プレイではあり得ない値(スコア/クリア時間等)ではないかサーバ側でチェックする。 • その処理に対しては報酬を与えない • たとえばスロットの場合、スロット回転が終わるまでの最低時間を予め計測しておき、それよりも明らかに早い間隔で回されている場合はお金だけ減らして報酬を与えないようにする。 • ログをとっておき、BANする
• たとえばクエストの場合、明らかに規定クリア時間より早いものを見つけたら記録しておく。後からBANする。 • すぐBANすると、チーターにBANされた理由を感づかれる→対策されるかもしれないので、時間をあえて置いてBANすることで理由を悟らせないのが望ましい。 • 223 自動化のための通信リクエスト再現を難しくする。 • リクエストパラメータの暗号化 • リクエストの改ざん検知 • コードの難読化 ©MIXI

【再掲】クライアント側を強固にするには？身も蓋もないがクライアント側を完全に守ることはできない。（攻撃者の手元にプログラムがあるため解析、改造できてしまうため）そのためセキュリティ上の理想的な設計としてはそもそもクライアントでは何も持たず、何も処理せず、ただサーバから受け取ったデータを元に画面描画だけしているのがベスト。ただし実際にはそうもいかずクライアントでもデータを持ったりロジックを動かしたりする必要がある。なので下記を行い、妥当な設計,実装,運用を作りうまいことやってゆかないといけない。 (MIXIはスマホアプリがメインなのでその想定でのお話) 224
• 重要な情報やロジックはクライアントに持たない • モバイルアプリにおける所謂セキュアコーディングをする • ゲームにおけるチートなど完全撲滅できないリスクへの対処をどうするか運用を含めて考え備える ©MIXI

チートならびにクライアント(モバイル)のセキュリティのまとめ • 下記がチートで狙われるポイント。図からも分かる通り、クライアント側のデータ/処理を守り切ることは困難。 • そのため、何度も言っていますが重要なロジックや情報はサーバ側に寄せて守りましょう。 • どうしてもサーバ側に寄せられないものについての対応は、ケースバイケースとなります。サービスの性質/改修コスト等に応じて、適切な緩和策を考えていく必要があります。 •
225 ゲームのチートでも、そうでなくても、この考え方は基本であり、同じです。 ©MIXI

参考ドキュメントモバイルのセキュリティのことで迷ったら覗いてみると助けになるかもしれないものたち • Mobile Application Security Design Guide • •
https://github.com/OWASP/www-project-mobile-application-security-design-guide セキュアコーディングガイド • Android (具体的なコードを交えて実践的に書かれている) • • http://www.jssec.org/dl/android_securecoding.pdf Apple (iOSの具体的な話というよりは一般論的な話) • https://developer.apple.com/library/content/documentation/Security/Conceptual/SecureCodingGuide/Introd uction.html • OWASP Mobile Top 10 • 226 https://owasp.org/www-project-mobile-top-10/ ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • • 227 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側公開しないもの = 管理画面や開発環境など次はここの話！ ©MIXI

公開しないものの守り方シンプルに「アクセス制御する」に尽きるが、やり方は色々ある。 • 境界防御 (IP制限) • ゼロトラスト的制御 • Basic認証
• リクエストヘッダに秘密の値を付与して検証 etc 手段によって安全性のレベルと実装,運用コストは変わってくる。どれが絶対に良い悪いという話ではなく、ケースによって適切な手段を選んでゆこうそのために手札を増やしておこう！ (セキュリティ室としてはゼロトラスト的な制御を推奨することが多いです) 228 ©MIXI

【演習】Juice Shopをアクセス制御で守ろう今回の研修で抑えておきたい「アクセス制御」の二つの思想 • 境界防御 → NWの境界線で守っていく考え方。 • ゼロトラスト →
弊社でも取り組んでいるイマドキ(?)の考え方/やり方。 Google Cloudの機能を使って、境界防御とゼロトラストの思想それぞれでJuice Shopをアクセス制御してみましょう！ • 229 Juice Shopは皆さんが運営しているサービスの試験環境だと想定してください。 ©MIXI

境界防御とは一般的な会社のネットワーク構成はこんな感じだと思います。会社のネットワーク PC インターネット PC ルータ等（詳細は省略） App & Data
クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置 AWS上の App & Data App & Data VPN PC 会社ではないどこか 230 ©MIXI

境界防御とは一般的な会社のネットワーク構成はこんな感じだと思います。会社のネットワーク PC インターネット PC ルータ等（詳細は省略）クラウド的なものたち Google Cloud上
の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち会社ではないどこか 231 ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。 • 見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除） • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）一般的な会社のネットワーク構成はこんな感じだと思います。 • 会社の終端装置から外に出る。→（IP制限による攻撃者排除）会社のネットワーク
PC インターネット PC ルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち会社ではないどこか 232 ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。 • 見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除） • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）一般的な会社のネットワーク構成はこんな感じだと思います。 • 会社の終端装置から外に出る。→（IP制限による攻撃者排除）会社のネットワーク
PC インターネット社内なら安心なので PC アクセスされる側は信じるルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内なら安心なのでアクセスされる側は信じる 233 会社ではないどこか ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。 • 社内ネットワークなら安心という世界観見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除） • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）一般的な会社のネットワーク構成はこんな感じだと思います。 • 会社の終端装置から外に出る。→（IP制限による攻撃者排除）
会社のネットワーク PC インターネット社内なら安心なので PC アクセスされる側は信じるルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内なら安心なのでアクセスされる側は信じる 234 会社ではないどこか ©MIXI

【演習】Juice Shopを境界防御にもとづいて守ろう自身のJuice Shop環境にIP制限を施し、境界防御の考え方でのアクセス制御を行おう。やること - Cloud ArmorというGoogle Cloudサービスを使ってIP制限を行い、挙動を確認する ※社内研修時はJuice
ShopをGoogle CloudでデプロイしていたためCloud Armorを使用しました 235 ©MIXI

【演習】Juice Shopを境界防御にもとづいて守ろう 1. Google CloudのコンソールCloud Armor設定画面にアクセス 2. ポリシーを作成 a. 3.
Default rule Action a. 4. 5. デフォルトは拒否でステータス403 ルールの追加 a. モード→基本モード b. 一致→許可したいIP c. 優先度→1000 ターゲットへのポリシーの適用 a. 6. PolicyTypeにバックエンドセキュリティポリシーを選択ターゲットの追加（ロードバランサのバックエンドサービス）高度な作成 a. スルー以上で設定したIP以外でアクセスすると403エラーが返るようになります。 236 ©MIXI

ゼロトラストとは会社のネットワーク PC インターネット PC ルータ等（詳細は省略） App & Data クラウド的なものたち
Google Cloud上の App & Data Saas の App & Data 終端装置 AWS上の App & Data App & Data VPN PC 会社ではないどこか 237 ©MIXI

会社のネットワーク PC インターネット社内なら安心なので PC アクセスされる側は信じるルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内なら安心なのでアクセスされる側は信じる 238 会社ではないどこか ©MIXI

会社のネットワーク PC インターネット社内NWは信頼できる=trust 社内なら安心なので PC アクセスされる側は信じるルータ等（詳細は省略）終端装置ワン!! クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内なら安心なのでアクセスされる側は信じる 239 会社ではないどこか ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。と思ったらインターネット社会では思い通りにはならなかった。 • 見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除）標的型攻撃はじめ色々な攻撃リスクが顕在化してきた。 • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）一般的な会社のネットワーク構成はこんな感じだと思います。色々繋がるネット社会において完全クリーンにすることは困難。
• 会社の終端装置から外に出る。→（IP制限による攻撃者排除）会社のネットワーク PC インターネット PC ルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち会社ではないどこか 240 ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。社内ネットワークだからといってそれだけで安心とは考えない世界観と思ったらインターネット社会では思い通りにはならなかった。 • 見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除）標的型攻撃はじめ色々な攻撃リスクが顕在化してきた。 • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）
一般的な会社のネットワーク構成はこんな感じだと思います。色々繋がるネット社会において完全クリーンにすることは困難。 • 会社の終端装置から外に出る。→（IP制限による攻撃者排除）会社のネットワーク PC インターネット社内ってだけじゃ PC アクセスされる側は信じないルータ等（詳細は省略）クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内ってだけじゃアクセスされる側は信じない 241 会社ではないどこか ©MIXI

境界防御とはここに繋ぐと認証等の各種対策/制約により下記が得られていた。社内ネットワークだからといってそれだけで安心とは考えない世界観と思ったらインターネット社会では思い通りにはならなかった。 • 見知らぬ者が社内NWに居ない。→（盗聴者や攻撃者の排除）標的型攻撃はじめ色々な攻撃リスクが顕在化してきた。 • 攻撃監視やロギングが一定される。→（攻撃の検知や調査）
色々繋がるネット社会において完全クリーンにすることは困難。 • 会社の終端装置から外に出る。→（IP制限による攻撃者排除）会社のネットワーク PC インターネット何も=zero 信頼できない=trust 社内ってだけじゃ PC アクセスされる側は信じないルータ等（詳細は省略）終端装置ワン!! クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 会社IPがこれ App & Data AWS上の App & Data App & Data VPN PC 業務用ならIP制限するものたち社内ってだけじゃアクセスされる側は信じない 242 会社ではないどこか ©MIXI

オフィシャルなゼロトラストオフィシャルなものを正確に学んだり調べたりする場合は下記を参考に！ 2020年8月に公開「NIST SP 800-207」 ▽英語 • https://csrc.nist.gov/publications/detail/sp/800-207/final ▽日本語 •
243 https://www.ipa.go.jp/security/publications/nist/index.html ©MIXI

オフィシャルなゼロトラスト遵守すべきこと引用元：https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html, (2025/4/27) 244 ©MIXI

オフィシャルなゼロトラスト遵守すべきことﾁｷｭｳﾜｶﾗﾅｲ引用元：https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/zero-trust-architecture-jp.html, (2025/4/27) 245 ©MIXI

オフィシャルなゼロトラストﾁｷｭｳﾜｶﾗﾅｲ引用元：https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf, (2025/4/27) 247 ©MIXI

この構成がなぜセキュアなのか Q. エンフォーサが無くても認証認可さえされていれば同じ？ A. リソース自身のセキュリティが完璧でないと突破されるかもなのでリスクは上がる。社外認可制御が抜けていて直接アクセスできるかもしれない認証等に脆弱性があ
り、それを悪用されるかもしれない認証認可社内 252 データや機能リソース ©MIXI

この構成がなぜセキュアなのかエンフォーサがあれば攻撃者のリクエストはリソース自体に到達しないので、リソース自身にもし脆弱性があっても攻撃者は攻撃できない IdP 社外認証認可社内 253 プロキシ (エンフォーサ)
データや機能リソース ©MIXI

誤解してはならないこと • 境界防御の全てがオワコンというわけではない。 • • 依然として使われているし、重要。手札として持っておこう。単純にゼロトラスト = リモート何でもOK
ということではない。 • 公開エンドポイントへのアクセス制御方法が社内IPに依存しなくなったというだけ • PC側の保護も必要となる。AV、EDR、PFW、覗き見、etc… • 当然、カフェ等での業務やフリーWi-Fiでの業務等はリスクがあるゼロトラストを誤解/過信して、セキュリティレベルが下がることの無いように。 254 ©MIXI

ゼロトラストまとめゼロトラストとは「社内ネットワークだろうがなんだろうが原則は何も信頼しない」「色々と疑いの目をもってアクセス制御する」という思想。ゼロトラスト＝最強という話ではなくて、守りたい対象へのアクセス制御方法の有効な手札として知っておこう。 255 ©MIXI

Juice Shopをゼロトラスト的に守るとしたら？ MIXI研修時の演習環境はこのようになっていました。 Public NW GoogleのNW 認証/認可 IAP HTTPS Cloud
Run Cloud Load Balancing 1 HTTP 参加者 1 Juice Shop 1 Cloud Run HTTPS Cloud Load Balancing 2 HTTP Juice Shop 2 参加者 2 256 ©MIXI

Juice Shopをゼロトラスト的に守るとしたら？ MIXI研修時の演習環境はこのようになっていました。 Public NW GoogleのNW 認証/認可 IAP ここがエンフォーサの役割を果たしている
HTTPS Cloud Run Cloud Load Balancing 1 HTTP 参加者 1 Juice Shop 1 Cloud Run HTTPS Cloud Load Balancing 2 HTTP Juice Shop 2 参加者 2 257 ©MIXI

参加者でのGoogleアカウントで認証されれば通過/それ以外は拒否 HTTPS Cloud Run Cloud Load Balancing 1 HTTP 参加者 1 Juice Shop 1 Cloud Run HTTPS Cloud Load Balancing 2 HTTP Juice Shop 2 参加者 2 258 ©MIXI

参加者でのGoogleアカウントで認証されれば通過/それ以外は拒否 HTTPS Cloud Run Cloud Load Balancing 1 HTTP 参加者 1 Juice Shop 1 これから、このルールを変えてみる演習をしていただきます！ Cloud Run HTTPS Cloud Load Balancing 2 HTTP Juice Shop 2 参加者 2 259 ©MIXI

【演習】Juice Shopをゼロトラストにもとづいて守ろう自身のJuice Shop環境のIAP設定を操作し、ゼロトラストにもとづいたアクセス制御を行おう。 • IAPとは • IAP とは、ウェブサイトへのリクエストをインターセプトし、リクエストを送信したユーザーを認証して、認証されたユーザーにのみサイトへのアクセスを許可
する、という一連の処理を行うサービスです。 • 対応しているプラットフォームは、App Engine、Compute Engine のほか、Google Cloud ロードバランサの背後で動作するサービスなど、さまざまなものがありますが、その利用は Google Cloud に限定されません。 IAP コネクタと合わせて使用すれば、オンプレミスのアプリケーションを保護することも可能です。 • 260 ざっくりいうと、ロードバランサ等へのアクセス時にGoogleアカウント等の認証を挟めるサービス。 ©MIXI

【演習】Juice Shopをゼロトラストにもとづいて守ろう自身のJuice Shop環境のIAP設定を操作し、ゼロトラストのアクセス制御を行おう。やること - Identity-Aware ProxyというGoogle Cloudサービスを使ってIP制限を行い、挙動を確認する -
確認すること - IAPをONにして、かつアクセス権があるときの挙動 - - IAPをOＮにして、かつアクセス権が無いときの挙動 - - Googleログイン後にアクセスできればOK レスポンスが「You dont have access」になればOK IAPをOFFにしたときの挙動 - シークレットブラウザなど、Googleログインしてない状態でアクセスできたらOK ※社内研修時はJuice ShopをGoogle CloudでデプロイしていたためIAPを使用しました 261 ©MIXI

【演習】Juice Shopをゼロトラストにもとづいて守ろう 1. IAPサービス画面にアクセス 2. 対象バックエンドサービスを選択しIAPをONにする 3. 画面右側にある「IAP-secured Web App
User」欄に自分を追加 a. 4. これでアクセス権が付与される IAPのON/OFF、IAP-secured Web App Userの付与/剥奪によって挙動の変化を確認 a. 確認すること b. IAPをONにして、かつアクセス権があるときの挙動 i. c. IAPをOＮにして、かつアクセス権が無いときの挙動 i. d. レスポンスが「You dont have access」になればOK IAPをOFFにしたときの挙動 i. 262 Googleログイン後にアクセスできればOK シークレットブラウザなど、Googleログインしてない状態でアクセスできたらOK ©MIXI

MIXIとゼロトラスト MIXIでもゼロトラスト設計での防御を使っていインターネットる！会社のネットワーク PC PC ルータ等（詳細は省略） App
& Data クラウド的なものたち Google Cloud上の App & Data Saas の App & Data 終端装置 AWS上の App & Data App & Data VPN PC 会社ではないどこか 263 ©MIXI

MIXIとゼロトラストうちの会社で使われているゼロトラストベースの構成（エンフォーサ + IDP）の例 • • AWS • ALB +
IdP • ALB + Cognito Google Cloud • Cloud Load Balancing + IAP セキュリティ室で導入サポートも行っています！ 264 ©MIXI

【演習】(余談) Juice ShopをWAFで守ろう WAFについて • Webアプリケーションの脆弱性に対しては一つ一つ対策を施していくのが基本だが、 WAF(WebApplicationFirewall)によって防御するという選択肢もある。 • リクエスト中に攻撃パターンの文字列が含まれていると遮断する(403応答など)。 •
WAFだけで守り切るのは困難だったり、正常なリクエストにも反応してしまう可能性があったり、基本的にはおすすめはしていないが、特定のケースで使える場合があるため、選択肢として持っておくとよい • 。レガシーなつくりでコードが入り組んでおり、アプリケーションの改修が難しいといった場合、WAFで一元的に攻撃シグネチャを遮断するという対策手段はアリかもしれない。 • 266 Google CloudではCloud ArmorにWAF機能がある。 ©MIXI

【再掲】総合演習 3. SQLインジェクションを悪用して全ユーザーの情報（Eメール、パスワードハッシュ）を抜き出そう答え（再掲） • 商品検索機能に下記のようなリクエストを送信することで、SQLインジェクションにより商品テーブルとUsersテーブルの情報が結合され、ユーザー情報を取得できます。 • /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8,9%20F ROM%20Users-•
※%27は「'」、%20は「」をそれぞれURLエンコードした値ユーザー一覧の情報を奪取できた！ 267 ©MIXI

【再掲】総合演習 3. SQLインジェクションを悪用して全ユーザーの情報（Eメール、パスワードハッシュ）を抜き出そう答え（再掲） • 商品検索機能に下記のようなリクエストを送信することで、SQLインジェクションにより商品テーブルとUsersテーブルの情報が結合され、ユーザー情報を取得できます。 • /rest/product/search?q=apple%27))%20UNION%20SELECT%20email,password,3,4,5,6,7,8,9%20F ROM%20Users-•
※%27は「'」、%20は「」をそれぞれURLエンコードした値これをWAFで防ぐ！ユーザー一覧の情報を奪取できた！ 268 ©MIXI

【演習】(余談) Juice ShopをWAFで守ろう 1. Cloud Armorページにアクセス 2. ポリシーを作成or編集 3. 「ルールを追加」でエディタ部分に右をコピペ
a. これが特定文字列を弾くルールセット 4. アクションは拒否(403)に 5. 優先度→10 6. WAF設定後、UNION〜の文字列を送信するとWAFが作動し 403エラーが返るようになればOK 269 evaluatePreconfiguredExpr('sqli-stable', ['owasp-crs-v030001-id942110-sqli', 'owasp-crs-v030001-id942120-sqli', 'owasp-crs-v030001-id942150-sqli', 'owasp-crs-v030001-id942180-sqli', 'owasp-crs-v030001-id942200-sqli', 'owasp-crs-v030001-id942210-sqli', 'owasp-crs-v030001-id942260-sqli', 'owasp-crs-v030001-id942300-sqli', 'owasp-crs-v030001-id942310-sqli', 'owasp-crs-v030001-id942330-sqli', 'owasp-crs-v030001-id942340-sqli', 'owasp-crs-v030001-id942380-sqli', 'owasp-crs-v030001-id942390-sqli', 'owasp-crs-v030001-id942400-sqli', 'owasp-crs-v030001-id942410-sqli', 'owasp-crs-v030001-id942430-sqli', 'owasp-crs-v030001-id942440-sqli', 'owasp-crs-v030001-id942450-sqli', 'owasp-crs-v030001-id942251-sqli', 'owasp-crs-v030001-id942420-sqli', 'owasp-crs-v030001-id942431-sqli', 'owasp-crs-v030001-id942460-sqli', 'owasp-crs-v030001-id942421-sqli', 'owasp-crs-v030001-id942432-sqli'] ) ©MIXI

【演習】(余談) Juice ShopをWAFで守ろう Q. WAF最強！脆弱性自体を直さなくても、これさえあればいいじゃん！ A. WAFはあくまで対症療法だと思っておこう。ちゃんと直そう。 - 完全にガードできるわけではない -
今回の例では、実は "email":"[email protected]'--" と入力して不正アクセスする攻撃は演習でのWAFでは防げません！ - 270 厳しくフィルタリングし過ぎると正常なリクエストを弾いてしまう懸念もある ©MIXI

• データの取り扱い。個人情報等。開発する対象 • 公開するもの = ユーザに公開しているサービス • • 271 サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所クライアント側 • 公開しないもの = 管理画面や開発環境など • AIを使う上で気を付けたいこと ©MIXI

AIをサービスに組み込むとしたら AIをサービスに組み込む場合、従来のセキュリティリスクへの対策に加えて、 AIならではのセキュリティリスクを考慮する必要があります。そこで参考になるのが、OWASPから公開されている以下のドキュメントです。 ❏ OWASP TOP 10 for LLM
Applications https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ ❏ OWASP TOP 10 for Agentic Applications https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ 272 ©MIXI

AIをサービスに組み込むとしたら 2つのドキュメントのうち、どれを参考にするかは対象となるレイヤーによって変わります。 ❏ OWASP TOP 10 for LLM Applications ➔
LLMを組み込んだアプリにおいて代表的なセキュリティリスクをまとめたもの ◆ カスタマーサポート用のチャットボットや社内ドキュメントの検索AIなど、非エージェント型のAIを組み込む場合に参照するドキュメント ❏ OWASP TOP 10 for Agentic Applications ➔ 自律的に行動するエージェント型AIを組み込んだアプリにおいて代表的なセキュリティリスクをまとめたもの ◆ Slackの投稿内容からその日のタスクを洗い出してタスク管理サービスに登録するアプリなど、「行動するAI」をサービスに組み込む場合に参照するドキュメント 273 ©MIXI

AIをサービスに組み込むとしたら各ドキュメントの項目は次のとおりです ★ OWASP TOP 10 for LLM Applications ★
OWASP TOP 10 for Agentic Applications LLM01:2025 Prompt Injection（プロンプトインジェクション） ASI01: Agent Goal Hijack（エージェント目標の乗っ取り） LLM02:2025 Sensitive Information Disclosure（機密情報の漏洩） ASI02: Tool Misuse & Exploitation（ツールの誤用と悪用） LLM03:2025 Supply Chain（サプライチェーン） ASI03: Identity & Privilege Abuse（IDと特権の乱用） LLM04:2025 Data and Model Poisoning（データ／モデル汚染） ASI04: Agentic Supply Chain Vulnerabilities LLM05:2025 Improper Output Handling（不適切な出力処理）（サプライチェーンの脆弱性） LLM06:2025 Excessive Agency（過剰な権限・自律性） ASI05: Unexpected Code Execution (RCE) LLM07:2025 System Prompt Leakage（システムプロンプトの漏洩）（予期しないコード実行） LLM08:2025 Vector and Embedding Weaknesses ASI06: Memory & Context Poisoning （ベクトル／埋め込みの弱点）（記憶とコンテキストの汚染） LLM09:2025 Misinformation（誤情報／ハルシネーション） ASI07: Insecure Inter-Agent Communication LLM10:2025 Unbounded Consumption（無制限のリソース消費）（安全でないエージェント間通信） ASI08: Cascading Failures（連鎖的な障害） ASI09: Human-Agent Trust Exploitation （人間とエージェントの信頼の悪用） ASI10: Rogue Agents（反逆エージェント） 274 ©MIXI

AIをサービスに組み込むとしたら全部で20個ある項目を1つ1つ覚えていくのは大変・・・そこで、本研修では「ここに気を付けて」というポイントを7つに分けてご紹介します。 ①入力 ②実行 ③認証・権限 ④サプライチェーン ⑤データ・コンテキスト・RAG ⑥運用・設計 ⑦人間
275 ©MIXI

①入力攻撃者による悪意のある入力やRAG文書に隠された指示により、AIが本来の目的を捨てて攻撃者の指示に従い、機密情報の出力や破壊的な操作等を行う可能性があります。 ★ ★ 該当する項目 ◦ LLM01: Prompt Injection（プロンプトインジェクション）
◦ ASI01: Agent Goal Hijack（エージェント目標の乗っ取り）対策例 ◦ 入力を信用しない ▪ プロンプトを検証する、Bedrock Guardrails（AWS）や Model Armor（Google Cloud）等のLLMガードレールを導入する、等 276 ◦ システムプロンプトに制約事項やセキュリティ上の注意事項を設定する ◦ 高いリスクを伴う操作は人間による承認を必須とする ©MIXI

②実行 AIが生成したコマンドやSQLクエリ等をそのまま実行したり、エージェントが権限の範囲内でツールを危険に使ったりすることで、データの破壊や機密情報の外部送信等の問題に繋がる可能性があります。 ★ ★ 該当する項目 ◦ LLM05:2025 Improper Output
Handling（不適切な出力処理） ◦ ASI02: Tool Misuse & Exploitation（ツールの誤用と悪用） ◦ ASI05: Unexpected Code Execution (RCE)（予期しないコード実行）対策例 ◦ 出力の検証と無害化を行う ▪ 277 evalを禁止にする、SQLをパラメータ化する、等 ◦ 本番環境では実行させず、サンドボックス環境で実行する ◦ 高いリスクを伴う操作は人間による承認を必須とする【①でも登場！】 ©MIXI

③認証・権限過剰な権限を付与している、認証・認可に使用するトークンの有効期限やスコープが広すぎるなど、権限の設計や制御に不備がある場合に、権限昇格やアクセス制御の回避などに繋がる危険性があります。 ★ ★ 該当する項目 ◦ LLM06:2025 Excessive Agency（過剰な権限・自律性）
◦ ASI03: Identity and Privilege Abuse（IDと特権の乱用）対策例 ◦ ◦ AIに与える権限は必要最小限に留める、トークンは短命かつタスク単位に分離にする ▪ 例：読み取り以外の行動を想定していないため、書き込み権限は与えない ▪ 例：トークンの有効期限が切れたり別タスクの際には再度認証・認可を要求するエージェントに独立したIDを付与し、「誰の立場で、どの権限で」行動したか追跡できるようにする ▪ 複数のエージェントが絡むような場面では、知らないうちに権限が拡大している場合があります。 IDを付与することで権限を明確にし、対人間と同じようにエージェントに対しても権限チェックをしましょう。 278 ©MIXI

権限の拡大ってどういうこと？権限の拡大はエージェントに限った話ではなく、他のサービスやデータソースなどの外部と連携するようなアプリやBotを開発するインテグレーション開発において気を付けたいポイントになります。例）以下の図では、プログラムに管理者権限が付与されていますが、プログラム自体は管理者権限のない一般ユーザーからもアクセスできるようになっています。この場合、一般ユーザーはプログラムを経由することで外部サービスの管理者機能にアクセスできてしまいます。一般権限でアクセス
一般ユーザー 279 管理者権限でアクセスプログラム外部サービス ©MIXI

権限の拡大を防ぐには権限の拡大を防ぐために、「プログラム自体に与えられた権限」と「プログラムを利用する人の権限」が一致するように設計しましょう！例）プログラムに管理者権限を付与する場合、プログラムを利用する人を管理ユーザーに限定する管理者権限以外はブロックする管理者権限でアクセス
一般ユーザー管理ユーザー 280 管理者権限でアクセスプログラム外部サービス ©MIXI

④サプライチェーン AIシステムを構成する外部コンポーネントに脆弱性が含まれている場合や、データセット、ツール等が汚染されている場合に、バックドアの混入やハルシネーション等の問題が引き起こされる可能性があります。 ★ ★ 該当する項目 ◦ LLM03:2025 Supply
Chain（サプライチェーン） ◦ ASI04: Agentic Supply Chain Vulnerabilities（サプライチェーンの脆弱性）対策例 ◦ 提供元が信用できるか慎重かつ厳しく審査する ◦ SBOMやML-BOM（Machine Learning Bill Of Materials）、AIBOM（AI Bill of Materials）を活用し、依存関係をモニタリングしておく ▪ 外部のライブラリやプラグインだけでなく、AIのモデルやデータセットもML-BOMなどを活用して管理対象に含めましょう 281 ©MIXI

⑤データ・コンテキスト・RAG クレデンシャルなどの機密情報が学習される、RAGやメモリが偽情報で汚染される、マルチテナント環境においてアクセス制御に不備があるなど、データの流れに関連した様々な問題が情報漏洩やエージェントの意図しない行動などを引き起こす可能性があります。 ★ 該当する項目 ◦ LLM02:2025 Sensitive Information
Disclosure（機密情報の漏洩） ※便宜上、⑤に分類していますが、他でも同じことが起こり得るため要注意！ 282 ◦ LLM04:2025 Data & Model Poisoning（データとモデルの汚染） ◦ LLM07:20205 System Prompt Leakage（システムプロンプトの漏洩） ◦ LLM08:2025 Vector & Embedding Weaknesses（ベクトルと埋め込みの弱点） ◦ ASI06: Memory & Context Poisoning（記憶とコンテキストの汚染） ©MIXI

⑤データ・コンテキスト・RAG ★ 対策例 ◦ 機微な情報を入力や学習に用いない ◦ 入力を検証する【①でも登場！】 ▪ ◦ アクセス境界を明確にして制限する
▪ 283 例：入力に機微情報が含まれていないか検証する、RAG知識ベースに入れる前に文書を検証する例：テナントごとにベクトルDBを分離する、検索範囲に制限を設ける ©MIXI

⑥運用・設計運用や設計の不備により、エージェントが危険な行動する、エージェント間でミスの伝播する、中間者攻撃を受けるなど様々な問題に繋がる可能性があります。 ★ ★ 284 該当する項目 ◦ LLM10:2025 Unbounded
Consumption（無制限のリソース消費） ◦ ASI07: Insecure Inter-Agent Communication（安全でないエージェント間通信） ◦ ASI08: Cascading Failures（連鎖的な障害） ◦ ASI10: Rogue Agents（反逆エージェント）対策例 ◦ 異常検知を行い、すぐに異常に気づけるような仕組みを整備する ◦ 緊急停止機能（キルスイッチ）を実装する ◦ エージェント間の通信にはmTLS（TLSの拡張版で、双方を認証する技術）を取り入れる ◦ 「誰が何を入力したか、AIが何を判断して実行したか」を追えるようなログを残す ◦ 高いリスクを伴う操作は人間による承認を必須とする【①②でも登場！】 ©MIXI

⑦人間 AIの出力を信じすぎることによって誤情報をそのまま外部に発信してしまったり、エージェントの危険な操作を誤って承認してしまう可能性があります。 ★ ★ 該当する項目 ◦ LLM09:2025 Misinformation（誤情報／ハルシネーション） ◦
ASI09: Human-Agent Trust Exploitation（人間とエージェントの信頼の悪用）対策例 ◦ ◦ 出力を信用させない ▪ 断定させないUIや検証を促すUI ▪ 根拠表示を必須にし、確定情報でない場合は未検証である旨を明示する影響度の大きい操作は必要に応じて2重の承認を設ける ▪ 285 入力者と上長の承認の両方を必須にするなど ©MIXI

補足今回は7つのポイントに分けて紹介しましたが、実際はこれらが組み合わさることで被害に繋がることが想定されます。例） • 本番環境の管理権限をエージェントに与えてしまっており、エージェントに開発環境のデータ削除を指示したところ本番環境のデータまで削除してしまった【②、③】 • 外部から持ってきたデータセットが汚染されていたことで誤った情報が出力され、出力内容を検証させる仕組みも無かったため、そのまま外部に発信されてしまい信用失墜に繋がった【④、⑦】
まずはそのサービスにおいて何をされたら困るかを考え、そこから必要な対策を考えていきましょう！ 286 ©MIXI

MCP(Model Context Protocol)について MCPとは、AIが外部システムやAPI実行、ファイルシステムの操作等の機能にアクセスする際に使用されるプロトコルであり、これらの機能は「ツール」という形でMCPサーバーから提供されています。 ※LLMやAIエージェントに必ずMCPが使われているという訳ではないため、その点はご注意ください。データベース MCP クライアント
MCP MCPサーバーファイルシステム AIアプリ 287 API ©MIXI

MCPに関わるセキュリティリスク MCPサーバーを構築する場合、OWASP TOP 10 for LLM/Agentic Applicationsとは異なる観点でセキュリティリスクに対処する必要があります。そこで参考になるドキュメントが「OWASP MCP
TOP 10」です。 ❏ OWASP MCP TOP 10 https://owasp.org/www-project-mcp-top-10/ ※2026年4月時点ではベータ版のため、正式版では内容が変更されている可能性があります。 288 ©MIXI

MCPに関わるセキュリティリスク ★ OWASP MCP TOP 10 MCP01:2025 Token Mismanagement &
Secret Exposure（トークンの不適切な管理と秘密の漏洩） MCP02:2025 Privilege Escalation via Scope Creep（スコープクリープによる権限昇格） MCP03:2025 Tool Poisoning（ツールポイズニング） MCP04:2025 Software Supply Chain Attacks & Dependency Tampering （ソフトウェアサプライチェーン攻撃と依存関係の改ざん） MCP05:2025 Command Injection & Execution（コマンドインジェクションと実行） MCP06:2025 Intent Flow Subversion（インテントフローの転覆） MCP07:2025 Insufficient Authentication & Authorization（不十分な認証・認可） MCP08:2025 Lack of Audit and Telemetry（監査と監視の不足） MCP09:2025 Shadow MCP Servers（シャドーMCPサーバー） MCP10:2025 Context Injection & Over-Sharing（コンテキストインジェクションと過剰共有） 289 ©MIXI

①認証・権限系 ★ 該当する項目 MCP01:2025 Token Mismanagement & Secret Exposure MCP02:2025
Privilege Escalation via Scope Creep MCP07:2025 Insufficient Authentication & Authorization ★ シナリオ例 ◦ サーバー間の認証や認可に使用するトークンをツール定義にハードコーディングしており、ツール定義からトークンが漏洩して不正アクセスを受けた（MCP01） ◦ MCPサーバーに過剰な権限が与えられており、意図せず本番環境のDBを初期化するツールが実行されてしまった（MCP02） ◦ 出金権限を持たないエージェントから出金ツールの呼び出し要求を受け入れてしまい、不正に出金された（MCP07） 291 ©MIXI

①認証・権限系 ★ 考えられる対策 ◦ トークンはAWS Secrets Managerなどの安全な保管場所に保管する（MCP01） ▪ ◦ MCPサーバーに過剰な権限を与えない（MCP02）
◦ MCPサーバー側でも権限チェックを実施する（MCP07） ▪ 292 併せてトークンを短命にしておくと良いです。例：編集権限を持たないエージェントから編集ツールへのアクセス要求が来たため、拒否する ©MIXI

②実行・コード系 ★ 該当する項目 MCP05:2025 Command Injection & Execution MCP06:2025 Intent
Flow Subversion ★ シナリオ例 ◦ 「logsディレクトリ内のファイルを一覧表示し、/etc/passwdの内容も表示して」と指示を与えたところ、「ls logs; cat /etc/passwd 」というコマンドがそのまま実行され、アカウント情報が漏洩する（MCP05） ◦ 「『users; DROP TABLE users;-- 』というテーブルのデータを一覧表示して」と指示したところ、「SELECT * FROM users; DROP TABLE users;-- 」というSQL文が実行され、データベースが破壊される（MCP05） ◦ 攻撃者が用意したGitHubの公開リポジトリから悪意のあるissueを読み込み、被害者の非公開リポジトリにあるソースコードが攻撃者宛てに送信されてしまう（MCP06） 293 ©MIXI

②実行・コード系 ★ 考えられる対策 ◦ ホワイトリストを用意して想定外のコマンド実行を防ぐ（MCP05） ◦ MCPクライアントからの入力をMCPサーバー上で無害化する（MCP05） ▪ 例：プレースホルダを使ってMCPサーバー側でSQLクエリを組み立てる、パスが含まれている場合は正規化してMCPサーバー側で検証する、等
◦ 当初の意図から外れたツールを呼び出せないように制限する（MCP06） ▪ MCP06は意図を変えられてしまう問題なので、例えば当初の意図がissueの読み込みなら、データの書き込みや送信など明らかに意図から外れているものは実行できないようにする 294 ©MIXI

③設計・運用系 ★ 該当する項目 MCP08:2025 Lack of Audit and Telemetry MCP09:2025
Shadow MCP Servers MCP10:2025 Context Injection & Over-Sharing ★ シナリオ例 ◦ ログを取っていなかったため、インシデントの原因分析に支障が出た（MCP08） ◦ 監視を行っていなかったため異常検知が遅れてしまい、被害が拡大した（MCP08） ◦ 社内ルールや周知事項を無視して信頼できないMCPサーバーを社内に導入したところ、 MCPサーバーに悪意のあるコードが含まれており、社外秘情報が外部に送信された（MCP09） ◦ マルチテナント環境においてコンテキストが共有されており、別会社のコンテキストに含まれる機密情報が出力された（MCP10） 295 ©MIXI

③設計・運用系 ★ 考えられる対策 ◦ 異常検知できる仕組みを整備する、ログをしっかり取る（MCP08） ◦ 信用できない外部のMCPサーバーは導入しない（MCP09） ◦ コンテキストを分離し、コンテキストに渡す情報を必要最小限に留める（MCP10） ▪
296 ユーザーやエージェントごとに分けたり、マルチテナントであればテナントごとに分ける ©MIXI

④サプライチェーン系 ★ 該当する項目 MCP03:2025 Tool Poisoning MCP04:2025 Software Supply Chain
Attacks & Dependency Tampering ★ シナリオ例 ◦ 導入したMCPサーバーのツール説明が改ざんされており、DBの検索を行うツールを呼び出したところDBの初期化を行うツールが実行され、DBが破壊される（MCP03） ◦ 外部から取ってきたMCPサーバーのパッケージにバックドアが仕込まれており、バックドア経由で不正アクセスを受ける（MCP04） 297 ©MIXI

④サプライチェーン系 ★ ★ 考えられる対策 ◦ 提供元が信用できる厳しく調査する（MCP03、MCP04） ◦ ツールの説明内容と実態のレビューを行う（MCP03） ◦ 改ざん対策として署名の付与と検証を行う（MCP03）
◦ SBOMを運用して依存関係をモニタリングする（MCP04）参考ツールポイズニングの具体的な攻撃手法は以下のサイトに紹介されているため、もし興味があれば確認してみてください https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks 298 ©MIXI

AIを開発で利用する際の注意点 • 情報漏洩のリスク ◦ CodexやClaude Codeなどはモデルがクラウド上にあるため、プロンプトやコード、ログなどが学習される設定になっていると、情報漏洩に繋がる可能性があります。学習設定がオフになっていることを確認し、APIキーやパスワードなどの機密情報がプロンプトやコード、ログなどに入り込まないように気を付けましょう。機密情報を含むプロンプト、
ソースコード等 300 ©MIXI

AIを開発で利用する際の注意点情報漏洩のリスク • ～余談～ • LlamaやGemmaなど、ローカルで動作するモデルであれば、機密情報が学習されても問題ないか ➢ 結論、ローカルで動作するモデルでも学習された情報が漏洩する可能性はあるため危険です。例えば、PCがマルウェアに感染した場合に、AIのチャット履歴やログファイル内の情報が漏洩する可能性があります。
モデルがどこにあるかに関係なく、個人情報やクレデンシャルなどの機密情報は入力しないようにしましょう！ 301 ©MIXI

AIを開発で利用する際の注意点 • 権限を必要以上に与えることによるリスク ◦ 権限を必要以上に与えすぎてしまうことで、Webサイトのクラウド移行時に、本番環境のDBやネットワーク設定等をエージェントが削除してしまい、2年半分の本番データが消失したという事例があります。 The $5 Decision
That Wiped 2.5 Years of Production Data https://www.quali.com/blog/the-5-dollar-decision-that-wiped-production-data-agentic-ai-governance/ 与える権限は必要最小限に留め、危険な操作であれば人間による承認を挟むようにしたり、変更前の状態でバックアップを取って安全に保管しておくなどの対策を取りましょう。 302 ©MIXI

AIを開発で利用する際の注意点 • 出力の過信によるリスク ◦ AIが生成した権限設計に不備があったり、生成されたコードにSQLインジェクション等のコード由来の脆弱性が含まれたりする可能性があります。生成物は必ずレビューし、セキュリティホールになり得る箇所を潰しておきましょう。 303 ©MIXI

AIを開発で利用する際の注意点 • その他 ◦ サプライチェーンのリスクはAIの開発利用においても気を付けたいポイントです。具体的には、プラグイン（Skills）が汚染されている、エージェントが脆弱性のある古いライブラリを提案する、といった可能性があるため、提供元の確認や依存関係のモニタリングを行いましょう！提供元が信用できるか厳しく調査する 304
SBOMやAI-BOMなどを活用して依存関係をモニタリングする ©MIXI

AIについてのまとめここまでご紹介したリスク以外にも、AIに関するセキュリティリスクはたくさんあり、本研修だけで全てを抑えるのは難しいため、まずは以下の5点を覚えていただければと思います！ 305 1. 入力は信用しない。 2. 出力も信用しない。 3. 権限を過剰に与えない。
4. 外部コンポーネントは便利だけどリスクもある。 5. 機密情報を入力しない。 ©MIXI

セキュアに開発しよう！ • • 開発の前提を守る • インフラ(AWS, GoogleCloud)の環境。NW設定等。 → • 作業環境。PCやクレデンシャル等。
• データの取り扱い。個人情報等。 → → 分離,アクセス制御等の適切な設計設定を。端末,クレデンシャルは堅牢に。ツールは慎重に扱う。扱う情報が何なのか整理。法律やルールも確認。開発する対象を守る • 公開するもの = ユーザに公開しているサービス • • 306 早見表サーバ側 • 自分たちでコードを作り込む箇所 • ミドルウェアやライブラリなど外部のコードを流用する箇所 → クライアント側 → Top10など参考に脆弱性を作り込まないコーディングを。 CVE等の情報をもとにリスク評価を。 → 重要なデータとロジックを持たないように。 • 公開しないもの = 管理画面や開発環境など → • AIを使う上で気を付けたいこと → 適切なアクセス制御を。 Top10など参考にリスクケアを。 ©MIXI

©MIXI

セキュリティ研修【MIXI 26新卒技術研修】

セキュリティ研修【MIXI 26新卒技術研修】

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript