脆弱性診断の指摘事項に対するベストプラクティスが実施できない場合の緩和策ガイド

認可に関する脆弱性と対策

Mon, 01 Jan 0001 00:00:00 +0000

認可に関する脆弱性と対策#

1. 脆弱性の概要 / 影響#

クーポン配布やキャンペーン等のマーケティング施策においては、必ずしも全ての利用者が会員登録やログインを経ているわけではありません。

例えば、店舗に設置されたQRコードを読み込むだけで誰でも利用できるクーポンは、顧客体験の向上に貢献する一方で、「誰でも何度でも」利用できてしまうとなると、想定していた効果が見込めなかったり、想定外の金銭的被害を被る可能性があります。

また、NEWSページの画像に認可制御をかけていなければ、公開前の情報を取得される可能性もあります。会員限定コンテンツの音声や動画の取得に制限がかけられていなければ、会員拡大のチャンスを失ってしまうかもしれません。

2. 根本的な対策#

セキュリティの観点からの原則は、システム上の全ての機能とデータアクセスが、認証された一意のユーザーに紐づいていることです。この原則に基づき、以下の三点が根本的な対策となります。

不要な情報は公開しない：リリース前情報は事前公開せず、時刻になったらサーバへアップロードして公開する
リソースとユーザーを紐づける：全てのクーポン、会員限定コンテンツなどのリソースは、発行・取得・利用の各段階で必ずユーザーIDと関連付ける
監査可能なログの記録：「誰が」「いつ」「どのリソースに」「何をしたか」をログに記録する

3. 緩和策#

ユーザビリティの最大化が求められるtoCサービスや、迅速な展開が必要なマーケティング施策では、すべてのユーザーに会員登録を強制することがビジネス上のボトルネックとなり得ます。このような場合、対象となるクーポンや静的コンテンツが不正利用された場合に発生し得る金銭的損失、運営コスト、そして実施したことによる見込み顧客の喪失といった機会損失を事前に試算し、被害額とビジネスインパクトに基づいて、どの対策をどこまで厳密に実装するか（コスト対効果）を判断します。その結果として、セキュリティのベストプラクティスを実施しないという判断が下されることがあります。

こうした制約の中でも、根本的な対策では無いながら受容可能なレベルまでリスクを低減させる方法として、緩和策を示します。

発行・利用の段階での追加チェック（サーバー側での簡易チェック）#

利用時の追加属性チェックを導入します。具体的には、同一IPアドレスからの短時間での大量リクエストを検知して拒否するルールや、利用頻度に基づく閾値を設けることで、不正な自動化ツールやスクレイピングによる乱用を防ぎます。

APIごとにレートリミットを設定し、短時間の大量発行・大量利用を自動的にブロックします。ログとアラートを連携させ、閾値超過や異常パターンを検知した際にセキュリティチームへ通知することで、手動対応やルール調整を迅速に行えるようにします。

署名付き/一時URLで静的リソース保護#

静的画像やクーポン表示ページなど、公開しているが長期公開したくないリソースは、期限付きかつ署名付きのURLで配布します。署名や有効期限（開始時刻・終了時刻）は、公開タイミングで生成・設定し、サーバー側で検証を行います。これにより、第三者によるURL共有や単純なスクレイピングでの継続的アクセスを防ぎ、意図した期間のみリソースにアクセスできるようにします。

URL難読化#

ファイル名やURLを推測困難なランダム文字列やハッシュ化した識別子に置き換え、推測による直接アクセスを困難にします。さらに、サイト上でのクローリングや検索結果への索引化を避けたいページについては、robots.txtやHTML metaタグを適切に設定して、検索エンジンや正規クローラーによる掲載を拒否します。

発行時の最小限の認証#

クーポン配布時に最低限の本人確認を要求します。例として電話番号のSMS OTP（ワンタイムパスコード）を必須にすることで、ボットや大量アカウントの自動生成による不正取得を抑制できます。その場で行える簡易的な手順であれば、UXへの影響を最小限に抑えられますし、セッション内に認証状態を持つだけであれば、サーバ側の実装コストも低くなります。

他に、決済連携のある配布（アプリ内購入やポイント付与など）では、決済プラットフォームから返却される決済トークンや利用者IDを記録しておきます。これにより、同一ユーザーIDによる短期間での異常な繰り返し利用を検知しやすくなります。

物理配送が発生するケースでは、配送先住所情報を識別要素として活用し、同一住所への不自然な頻度の注文や受け取りを監視します。配送先による縛りはリアルワールドの抑止力として有効です。

利用時の本人確認（実店舗）#

実店舗で利用する高額・高価値のクーポンについては、店舗スタッフによる身分証明書（運転免許証、マイナンバーカード等）の提示と確認を義務付ける運用ルールを設けます。可能であれば記録を取っておくべきですが、抑止力的な運用でも一定程度の効果が見込めます。

4. 緩和策実施後も残存するリスク#

上記の各緩和策を講じたとしても、リスクは残存します。

1. 発行・利用の段階での追加チェック（サーバー側での簡易チェック）#

リミットが適用されない程度の分散的なアクセスや短時間では検知・防止できない場合があります。また、Cookieを消去・リセットしたり、プロキシやVPNでIPを切り替えたり、アプリを再インストールして端末識別子を変えるなど、攻撃者が属性を変更することで回避される恐れがあります。

2. 署名付き/一時URLで静的リソース保護#

署名付きURL自体が有効である限り、第三者に共有されれば何度でもアクセス可能です（有効回数の制限や短時間での利用制限が別途必要）。また、署名管理、期限設定、認証フローの追加によって実装が複雑になり、CDNやストレージのアクセス方法によってはクラウド利用料が増える可能性があります。

3. URL難読化#

URLやファイル名が何らかの理由で漏えいした場合、難読化だけでは防げません。

近年のAIクローラーやスクレイピングの進化により、robots.txtやmeta noindexを無視してデータ収集・学習されるケースがあり、意図せず情報が学習データや検索インデックスに取り込まれる恐れがあります。

4. 発行時の最小限の認証#

決済連携や外部IDに頼る場合、それらのプラットフォーム仕様に依存するため実装不可のケースや、ユーザー側でリセット・偽装可能な要素が存在する場合、効果が限定的になる可能性があります。また、収集・保持する情報が増えることで、実装や運用、セキュリティ管理が煩雑になります（データ保護、アクセス権管理、ログ管理など）。取り扱う個人情報や決済データについては、法令・プラットフォーム規約に従い最小限の保持・暗号化・アクセス制御を行う必要があります。

5. 利用時の本人確認（実店舗）#

スタッフによるID確認は時間や労力を要し、顧客体験の低下やレジ待ちの増加、教育コストの発生を招きます。また、一定程度の抑止力になるとはいえ、経済的利益が大きい場合や業として行える転売等が絡むと、本来規制したい対象は気にせず、本来利用してほしい層への威圧になってしまい、逆効果となる可能性があります。

ファイルアップロード機能を中心としたDoS攻撃の緩和

Mon, 01 Jan 0001 00:00:00 +0000

ファイルアップロード機能を中心としたDoS攻撃の緩和#

1. 脆弱性の概要 / 影響#

Webアプリケーションにおけるファイルアップロード機能は、多くの機能実装で不可欠である一方、DoS（Denial of Service）攻撃を受けやすい機能でもあります。攻撃者は巨大ファイルの送信、画像処理の計算量を悪用した資源枯渇、大量の並列リクエストなど、多様な手法でサービスの可用性を脅かすことができます。

本ドキュメントでは、ファイルアップロード機能を起点とするDoS攻撃の脅威モデルを整理し、ネットワーク層からアプリケーション層、処理層、アーキテクチャ層に至る多層防御の考え方に基づき、緩和策をまとめます。

2. 脅威モデル#

ファイルアップロード機能に関連するDoS攻撃は、主に以下の4つのベクトルに分類できます。

2.1 帯域・セッションの枯渇#

大量のHTTPリクエストを並列送信し、Webサーバーの同時接続数やセッションプールを飽和させます。ファイルアップロードのエンドポイントは、リクエストボディが大きくなるため、通常のAPIエンドポイントよりも帯域の消費効率が高くなります。

2.2 ストレージの枯渇#

巨大なファイルを繰り返しアップロードし、サーバーのディスク容量を圧迫します。ストレージが枯渇すると、ログの書き込みやデータベース操作にも影響が波及し、システム全体の機能不全を引き起こします。

2.3 CPU・メモリの枯渇（Decompression Bomb / Pixel Flood）#

ファイルサイズは小さいものの、展開後に膨大なリソースを消費するファイルを送信します。代表的な手法として以下があります。

Decompression Bomb（展開爆弾）: 圧縮ファイルや画像のヘッダ情報を細工し、展開時に数十GBのメモリを要求します。PNGのIHDRチャンクに異常なピクセル数（例：50,000 x 50,000ピクセル）を宣言するといった例が考えられます。
Pixel Flood攻撃: JPEGファイルのヘッダに巨大な画像寸法を定義し、画像変換ライブラリが全ピクセルをメモリに展開しようとする際にメモリを溢れさせます。

2.4 処理遅延（Slow Processing）#

サーバー側の画像変換・リサイズ処理の計算量を悪用します。ファイルサイズの制限だけでは防御できず、ピクセル数、フレーム数、色深度など処理の計算量に直結するパラメータの制御が必要となります。

3. 多層防御による緩和・対策#

3.1 ネットワーク層の防御#

3.1.1 WAF（Web Application Firewall）の活用#

WAFはアプリケーション層の攻撃を検知・遮断する最前線の防御です。主要なクラウドWAFサービスは、以下の機能を提供します。

機能	説明
IPレピュテーション	既知のボットネットIPからのアクセスを遮断
レートベースルール	一定期間内のリクエスト数超過で自動遮断
リクエストサイズ制限	異常に大きいリクエストボディを遮断
Bot Control	機械学習によるボット判定とチャレンジ発行

3.1.2 IPブラックリストとレピュテーションフィルタリング#

ボットネットの送信元IPは、脅威インテリジェンスフィードを通じて共有されています。例えば、AWS WAFのAmazonIpReputationListマネージドルールグループには、DDoS活動に積極的に関与しているIPを検査するAWSManagedIPDDoSListルールが含まれています。

ただし、IPアドレスベースの遮断には後述するCGNAT問題に注意が必要です。

3.2 アプリケーション層の防御#

3.2.1 レート制限の設計#

レート制限は、DoS対策の中核をなす機能です。効果的なレート制限を行うには、複数の識別子を組み合わせて実装する必要があります。

識別子	適用場面	利点	制約
IPアドレス	全エンドポイント	実装が容易	CGNAT環境で正規ユーザーに影響する可能性がある
認証済みユーザーID	認証必須エンドポイント	精密な制御	未認証エンドポイントには適用不可
APIキー	API提供サービス	クライアント単位の制御	キーの発行方法によっては同様のリスクが発生

CGNAT問題: モバイル回線や一部のISPでは、CGNAT（Carrier-Grade NAT）により多数のユーザーが単一のパブリックIPアドレスを共有します。これを考慮した制御をしなければ、正規ユーザーの誤判定によって、攻撃者のDoS攻撃の目的が意図せず達成されてしまいます。

HTTPセキュリティヘッダ・Cookie属性

Mon, 01 Jan 0001 00:00:00 +0000

HTTPセキュリティヘッダ・Cookie属性#

1. 脆弱性の概要 / 影響#

クロスサイトスクリプティング（XSS）、セッションハイジャック、クリックジャッキング等の攻撃を防御するメカニズムであるHTTPセキュリティヘッダ（HSTS、CSP、X-Frame-Options等）やCookie属性（Secure、HttpOnly、SameSite）を設定することはシステムの安全性を確保するうえで重要であるにもかかわらず、セキュリティ診断の実施後にこれらの不備が指摘されるケースがしばしば見受けられます。

これらのセキュリティ機構はリスクの『軽減』を目的とした多層防御の一部であり、アプリケーション側の脆弱性（不適切なエスケープ等）そのものを排除するものではないことに注意してください。緩和策の実施後もリスクは残存し、恒久的な対策への移行を計画・実行する必要があります。

HTTPセキュリティヘッダ欠如のリスク#

ヘッダ	目的	欠如時のリスク
Strict-Transport-Security (HSTS)	HTTPS接続の強制	中間者がHTTPS接続をHTTPにダウングレードし、通信内容を盗聴・改ざん可能
Content-Security-Policy (CSP)	リソース読み込み制限	XSS攻撃による悪意あるスクリプトの実行、データ窃取、フィッシング等の被害拡大
X-Frame-Options	クリックジャッキング防止	悪意あるサイトにiframeで埋め込まれ、ユーザーの意図しない操作を誘発される
X-Content-Type-Options	MIMEスニッフィング防止	ブラウザのMIMEタイプ推測により、悪意あるファイルが意図しない形式で実行される
Referrer-Policy	Referer情報の制御	機密情報を含むURLが外部サイトに漏洩

Cookie属性欠如のリスク#

属性	目的	欠如時のリスク
Secure	HTTPS通信でのみCookie送信	中間者攻撃により、HTTP通信経由でCookieが窃取され、セッションハイジャックされる
HttpOnly	JavaScriptからのCookieアクセス禁止	XSS攻撃により、認証Cookieが窃取され、なりすましや権限昇格が可能になる
SameSite	クロスサイトリクエストでのCookie送信制御	CSRF攻撃により、ユーザーの意図しない操作が実行される（パスワード変更、送金等） *1

*1 Google Chrome や Microsoft Edge 等のモダンブラウザでは、SameSite 属性が省略された Cookie に対しても SameSite=Lax 相当の挙動がデフォルトで適用されるため、クロスサイトの POST リクエストでは Cookie が送信されないなど、限定的ながらブラウザによる CSRF 保護を受けられます。

CookieのSameSite属性の間違えやすい挙動#

SameSite 属性は仕様が複雑で、ブラウザにより挙動が異なります。たとえば Chromium 系のブラウザでは、SameSite 属性が明示されていない Cookie に対してデフォルトで SameSite=Lax 相当が適用されますが、Cookie がブラウザに保存されてから 2 分間 は例外的にクロスサイトの POST リクエストでも送信される仕様があります。

長時間のセッション維持を許容する場合の緩和策

Mon, 01 Jan 0001 00:00:00 +0000

長時間のセッション維持を許容する場合の緩和策#

1. 脆弱性の概要/影響#

Webアプリケーションにおいて、再ログインの頻度を減らしたいという利用者の要望や、業務の性質上長時間のログイン状態を維持したいという要件から、セッションタイムアウトを長めに設定したくなるケースは少なくありません。
しかし、セッションが長時間有効な状態にあると、何らかの原因でセッションが第三者に渡った場合に、そのセッションを悪用できる時間的猶予が広がり、不正アクセスや情報漏えいのリスクが高まります。
セッションが第三者に渡る経路としては、たとえばXSSやネットワーク上の盗聴によるセッションIDの漏えい、ログイン状態のままの端末の紛失・盗難、共有端末でのログアウト忘れによるセッションの残存などが考えられます。
いずれのケースにおいても、セッションが有効である間は、第三者が本人のセッションを悪用して、情報を閲覧したり、権限の範囲内で各種操作を行ったりする可能性があります。また、セッションが長く維持されるほど、不正利用が可能な期間も長くなり、結果として被害が拡大するおそれが高まります。

2. 根本的な対策#

リスクを完全に排除する根本的な対策は存在しません。
セッションの悪用リスクを低減するためには、アプリケーションの性質や取り扱う情報の重要度に応じて適切なタイムアウトを定義し、サーバ側で確実に強制することが重要です。利便性を理由に無制限または過度に長いセッションを許容するのではなく、セキュリティと使いやすさのバランス、利用者の操作特性を踏まえてタイムアウト値を設定する必要があります。
セッション管理では、少なくとも以下の2種類のタイムアウトを併用することが重要です。

アイドルタイムアウト（Idle Timeout）
- 最後の操作やHTTPリクエストから一定時間が経過した場合にセッションを無効化する仕組みです。NISTでは「Inactivity Timeout」とも呼ばれています。離席や操作の中断など、利用者が操作していない間の悪用を抑止する効果があります。
絶対タイムアウト（Absolute Timeout）
- 活動状態にかかわらず、認証または再認証から一定時間でセッションを無効化する仕組みです。NISTでは「Overall Timeout」とも呼ばれています。アイドルタイムアウトだけでは、攻撃者が定期的にリクエストを送ることでセッションを無期限に延命できるため、絶対タイムアウトで上限を設けることが必要です。

OWASPおよびNISTの文書では、タイムアウト値の目安として以下のような考え方が示されています。

OWASP Session Management Cheat Sheet#

アイドルタイムアウトについて、高価値アプリケーションでは2〜5分、低リスクアプリケーションでは15〜30分という、アプリケーションの重要度に応じた目安を挙げています。

NIST SP 800-63B#

AAL（Authentication Assurance Level）ごとの再認証要件として以下の時間を示しています。

AALレベル	Overall Timeout	Inactivity Timeout
AAL1	30日以内	設定任意
AAL2	24時間以内	1時間以内
AAL3	12時間以内	15分以内

3. 緩和策#

いずれも一般的なセキュリティ対策ですが、セッションタイムアウトを長めに設定しなければならない場合には、以下のような仕組みを導入することで影響を緩和できます。

3.1 重要操作前・リスクイベント発生時の再認証要求#

重要な操作については、現在のセッションが有効であることだけを根拠に実行を許可しないことが望まれます。OWASP Authentication Cheat Sheetでは、パスワード変更やメールアドレス変更のような機微なアカウント情報の更新や、配送先変更のような重要な操作の前に、現在の認証情報による再確認を求めることを推奨しています。これにより、CSRFやセッションハイジャック、あるいは第三者が一時的に利用者の端末やブラウザへアクセスできた場合でも、重要操作まで連鎖的に実行されることを防げます。
再認証は、リスクの高いイベントが検知された際にも要求することが有効です。同Cheat Sheetでは、再認証の契機として、異常なログインパターンやIPアドレス・利用端末の変化といった不審なアカウントアクティビティを検知した場合などを挙げています。これにより、たとえセッションが継続中であっても、通常と異なる状況下では追加の本人確認を挟み、不正利用の継続を抑止できます。あわせて、再認証後は既存セッションIDを無効化し、新しいセッションIDを発行すること（セッションIDのローテーション）も推奨されています。

3.2 ログイン状態の可視化・通知#

利用者自身がログイン状況を把握し、不審なセッションに気づいて対処できる仕組みを整えておくことも有効です。具体的には、アクティブなセッションの詳細をいつでも確認できるようにすること、不正なセッションを利用者または管理者が終了できるようにすることが挙げられます。OWASP ASVS 5.0（V7.5 Defenses Against Session Abuse）でも、セッションの可視化や管理に関する確認項目が示されています。
あわせて、通常と異なるセキュリティイベントが発生した場合に利用者へ通知することも有効です。ただし、重要性の低い通知を大量に送ると通知疲れにより見落としが発生するおそれがあるため、新規端末からのログインや通常と異なる地域・環境からのアクセスなど、リスクの高いイベントを中心に通知する設計が望まれます。

既知の脆弱なライブラリの利用による問題

Mon, 01 Jan 0001 00:00:00 +0000

既知の脆弱なライブラリの利用による問題#

1. 脆弱性の概要 / 影響#

一般的に、アプリケーションは複数のライブラリを組み合わせて構成されています。多くのライブラリでは新しいバージョンが定期的にリリースされており、新機能の追加だけでなく、脆弱性の修正を目的とした、適用が必須となるアップデートも含まれています。脆弱なライブラリを利用している場合、対象のアプリケーション自体に固有の脆弱性がなくても、そのライブラリの脆弱性を悪用した攻撃を受ける可能性があります。

ライブラリの脆弱性情報はNVD（National Vulnerability Database）などのデータベースで広く公開されており、攻撃に利用できるPoCコードが既に存在するケースも少なくありません。そのため、既知の脆弱性を抱えたライブラリをアプリケーション内で使用し続けることは、常に攻撃にさらされるリスクを伴います。セキュリティアップデートが公開された際は、速やかに影響範囲を確認したうえで適用することが求められます。

しかし、ライブラリ間の依存関係や適用するためのコードの修正が困難な場合など、アプリケーションの構成や環境によってはアップデートを即座に適用できないケースも存在します。

本ドキュメントは、こうした状況において根本対策が実施されるまでの間に講じるべき緩和策を示します。

2. 根本的な対策#

セキュリティの観点では、既知の脆弱性を持つライブラリやコードは速やかにアップデートして脆弱性を解消することが求められます。特に近年はAIの進化により攻撃の高速化が進んでおり、既存の脆弱性をアプリケーション内に放置することはリスクを高める要因となります。

根本的な対策は以下のとおりです。

脆弱性の修正済みバージョンへのアップデート#

脆弱性情報が公開されているライブラリは、修正済みバージョンへアップデートし、脆弱性を解消しましょう。この対応をするには公開された脆弱性が自身のアプリケーションに影響するかどうかをまず特定する必要があります。このような場合にソフトウェアの部品表となるSBOM （Software Bill of Materials）などを利用して、自身のアプリケーションでどのライブラリのどのバージョンを利用しているかをしっかりと管理することが重要となってきます。また、平時から利用しているソフトウェアやライブラリの情報を適切に管理することはサプライチェーン攻撃のような迅速な対応が求められる際に利用箇所の特定や対応を円滑に進めるのに役立ちます。

ただし、最近ではリリース後、すぐに最新バージョンを適用するのは危険な場合があります。近年のサプライチェーン攻撃では正規のメンテナが乗っ取られ、悪意あるコードが含まれたバージョンが公開されてしまう場合があります。そのため、すぐに適用するとアプリケーション内に悪意あるコードが組み込まれてしまう恐れがあります。

したがって、リリース後、一定の検疫期間を設けるpnpmのminimumReleaseAgeのような設定を組み込んだり、バージョンタグを指定してインストールするのではなく、バージョンをハッシュで固定化してインストールするなどの仕組みを設けることが重要となってきています。

メンテナンス可能なライブラリへの差し替え#

何らかの理由でメンテナンスが困難またはサポートが終了しているライブラリは、継続的にメンテナンスが行われている代替ライブラリを探し、差し替えることを検討してください。特にサポートされていないライブラリの継続的な利用は、今後発見されるすべての脆弱性に対して自力で対処する義務を負うことを意味するため、その保守コストは時間とともに増大し続けることになります。

定期的なリファクタリングの実施#

ライブラリのアップデートを行う上でコードが古い、またはドキュメントが不足しているなど、メンテナンス性に問題がある場合は、定期的にリファクタリングを行い、保守しやすい状態を組織内で維持してください。仕組みとしてリファクタのマイルストーンを配置して、実施するなど開発の計画に組み込むようにしましょう。また、リファクタリングとともにドキュメントを作成したり、見直すことはソフトウェアの保守性を担保することにつながります。

3. 緩和策#

1. 仮想パッチ（Virtual Patching）の導入#

仮想パッチとしてWAF（Web Application Firewall）やIPS（Intrusion Prevention System）を導入することで、脆弱性を狙う攻撃トラフィックが対象のアプリケーションに到達する前に遮断することができます。仮想パッチの対応では、許可リストを用いる対応と拒否リストを用いる対応があります。

許可リストによる対応: 自身が信頼しているアクセスリストや正常な入力パターンのみを許可し、それ以外を拒否する対応です。攻撃面の縮小効果が見込まれます。
拒否リストによる対応: 既知の攻撃パターンを検出して、拒否する対応です。迅速に適用できる、一方で特定の攻撃のみしか防御できないため回避されるリスクが高いです。特に特定の攻撃ペイロードのみを遮断するルールは、攻撃者が容易に回避できる可能性があるため推奨できません。

また、仮想パッチに加えて対象アプリケーションを常に監視し、不審な動作が発生しないかを確認することも重要となってきます。

2. 独自でのパッチ適用や入力検証コードの実装#

ライブラリのアップデートが困難な場合、検出された脆弱性の種類（SQL Injection、XSS 等）に応じて、脆弱なコンポーネントへの入力・出力を保護するコードを独自に実装し、パッチや入力検証を行うコードを適用する方法があります。

ただし、独自のパッチ適用や入力検証コードの実装は不備が生じやすく、攻撃者によって回避される恐れもあるため、あくまで一時的な対策として位置づけてください。実装にあたっては、対象アプリケーションの資産の重要度と今後の運用状況を十分に考慮することが重要です。重要度が低いアプリケーションかつ次回のアップデート予定が明確に決まっている場合にのみ、独自のパッチ適用などを検討してください。一方、重要度が高いアプリケーションに対しては独自でのパッチ適用などによる対処は推奨できません。

もし、今後メンテナンスが不可能と判断できるのであれば、経営判断を仰いだうえでアプリケーションの移行など別の手段を検討する必要があります。

また、独自で1からパッチを作成しなくてもソフトウェアやライブラリの提供元などが、アップデートが困難な場合の緩和策を提示していることがあります。例えば、Apache Log4jの任意コード実行の脆弱性では、特定のクラスをロードしないことで問題を回避する手段が提供されました。その他にも、GitHub Security Advisoriesなどにも緩和策に関する情報が提示されている場合がありますので確認することをお勧めします。

3. ネットワーク分離・アクセス制限を入れる#

アップデートが困難なアプリケーションに対しては、攻撃の到達を防ぐためにネットワーク分離やアクセス制限を導入するという手段もあります。インターネットからの直接アクセスを遮断し、内部ネットワークからのアクセスのみを許可することで、攻撃対象領域を狭めることができます。さらに、内部ネットワークからのアクセスについても特定のネットワークに限定したり、認証プロセスを追加したりすることで、アクセスできる人やシステムを必要最小限に絞ることができます。

4. 多層防御の構築#

単一の緩和策に依存せず、仮想パッチ・入力検証・ネットワーク分離やアクセス制限など、これまで挙げた対策を組み合わせて防御する多層防御という手段もあります。多層防御を用いることで攻撃者がアプリケーションにある脆弱性を悪用するための難易度を高めることができます。仮にいずれかの層が突破された場合でも、攻撃に対する被害を最小限に抑えることが可能です。また、突破に要する労力が攻撃者にとってのメリットを上回ることで、攻撃自体を諦めさせる抑止効果も期待できます。

4. 緩和策実施後も残存するリスク#

緩和策を講じた場合でも、以下のリスクが残存する可能性があります。

1. 仮想パッチ（Virtual Patching）の導入#

WAFやIPSによる仮想パッチは有効な対策の1つですが、この対策の防御には限界があります。例えば、攻撃者が攻撃コードをエンコードや難読化することで設定されているルールを回避し、防御を突破される可能性があります。また、ルールの設定によっては正当な通信を誤って遮断する誤検知が発生し、サービスの運用自体に影響を与えるリスクもあります。

SQLインジェクションの対策と緩和

Mon, 01 Jan 0001 00:00:00 +0000

SQLインジェクションの対策と緩和#

1. 脆弱性の概要 / 影響#

SQLインジェクション（SQLi）とは、Webアプリケーションがユーザー入力をSQLクエリに安全に組み込まず、攻撃者が任意のSQL構文を注入できる脆弱性です。OWASPにおいても代表的なWeb脆弱性として位置づけられており、脆弱性が悪用された場合は以下のような深刻なインシデントに発展する可能性があります。

情報漏えい: 顧客情報や機密データの漏えい。
データ改ざん・破壊: データの書き換えやテーブルの削除。
認証回避: 管理者権限での不正ログイン。

2. 根本的な対策#

SQLインジェクションの根本的な対策は、プリペアードステートメント（静的プレースホルダ） の利用です。ユーザー入力をSQLの構造部分から切り離すことで、攻撃者によるSQL構文の注入を原理的に防ぐことができます。

ただし、長期間運用されているレガシーシステムでは、以下の理由により根本対策の適用が困難なケースがあります。

複雑な動的SQL文: 数百〜数千行に及ぶSQLテンプレートが文字列連結で構築されている。
フレームワークの制約: プリペアードステートメントをサポートしない古いライブラリや独自フレームワークを使用している。
リソース制約: 大規模な改修に伴うリグレッションテストの工数が確保できない。

3. 緩和策#

根本対策が困難な場合、単一の防御策に依存することはリスクがあります。複数の緩和策を設けた多層防御を構築し、攻撃の成立難易度を高めることが求められます。これらの緩和策は脆弱性を根本的に排除するものではありません。長期的にはシステムの刷新やコードベースの安全な書き換えが必須です。

3.1 アプリケーション層#

コードレベルでの修正が限定的に可能な場合に実施すべき対策です。

3.1.1 厳格な入力バリデーション#

SQL構文として解釈されうる文字の混入を未然に防ぎます。

型チェックの徹底: 例えば、数値として扱われるべきパラメータ（ID、フラグ等）は、必ず数値型にキャストしてからSQLに埋め込みます。
ホワイトリスト検証: ソート順（ASC/DESC）やテーブル名など、プレースホルダが使えない識別子は、許可された文字列リストと照合します。

3.1.2 独自エスケープ処理#

OWASPガイドラインでは推奨されていませんが、プリペアードステートメントが利用できない場合の最終手段として使用します。

DBエンジン固有の仕様への準拠: PHPのビルトイン関数である mysql_real_escape_string 相当の処理など、使用するDBエンジンの仕様に完全に準拠したエスケープ関数を使用します。※なお、mysql_real_escape_stringのサポートはPHP5までで、現在使用されている 7.x系では削除されています。
メタ文字の無害化: '（シングルクォート）、"（ダブルクォート）、\（バックスラッシュ）、;（セミコロン）などを確実にエスケープします。

3.2 データベース層#

3.2.1 データベースファイアウォール#

アプリケーションから送信されるSQLクエリを監視し、不正なパターンを遮断します。

クエリホワイトリスト:
- 学習フェーズ: 正常な運用時の全SQLパターンを学習し、ホワイトリストを作成します。
- 運用フェーズ: リストに含まれない未知のSQL（攻撃によって構造が変化したSQL）をブロックします。
製品例: MySQL Enterprise Firewall、Oracle Database Firewall、各種商用DBセキュリティ製品。

3.2.2 最小権限の原則#

万が一インジェクションが成功した場合の被害範囲を最小限に抑えます。

ユーザー分離: アプリケーションからの接続ユーザーを用途別に分割します。

ユーザー付与する権限

App_Read SELECT のみ

App_Write INSERT、UPDATE のみ
危険な権限の剥奪: DROP、ALTER、GRANT などの管理権限、およびファイル操作やOSコマンド実行に関わるストアドプロシージャの実行権限を剥奪します。

ユーザー	付与する権限
`App_Read`	`SELECT` のみ
`App_Write`	`INSERT`、`UPDATE` のみ

XSSの対策と影響

Mon, 01 Jan 0001 00:00:00 +0000

XSSの対策と影響#

クロスサイトスクリプティング（XSS）とは、Webアプリケーションがユーザー入力を適切に処理せず、そのままHTMLやJavaScriptとして実行してしまう脆弱性です。 OWASP においても代表的なWeb脆弱性として位置づけられています。

脆弱性概要/影響#

XSSは、信頼できないスクリプトがブラウザ側で実行されてしまう脆弱性です。

主な分類:

格納型 (Stored): サーバーに悪意あるスクリプトが保存され、閲覧した全ユーザーに影響が及ぶもの
反射型 (Reflected): URLパラメータ等に含まれたスクリプトが、そのままレスポンスとして返ることで発火するもの
DOM-based: JavaScriptによるクライアント側の処理不備で発生するもの

発生頻度の高いケース:

リッチテキストエディタや掲示板など、文字装飾のためにHTMLタグを許可したい場合
「お知らせ」機能などで一部の装飾を許可している箇所
AIエージェントによる出力: 生成AIがMarkdownやJSON形式で出力した内容を、そのままブラウザでレンダリングする際の不備

主な影響:#

セッション情報の窃取: Cookie（HttpOnly属性がない場合）の読み取りによるなりすまし。
画面の改ざん・破壊: 意図しないコンテンツの表示やUIの崩壊。
情報の漏洩: 攻撃者のドメインへ機密情報を送信されるリスク。

根本対策#

XSS対策の原則は信頼できない入力をそのまま実行させないことです。そのため、コンテキストに応じた出力エンコードが対策となります。 HTML要素、属性、JavaScript内など、データの挿入場所に応じた適切なエスケープ（< → < など）を徹底してください。

安全な関数を用いてDOMを構築することも対策の一つです。例えばinnerHTMLではなくinnerTextを用いて組み立てれば、エスケープを行わずともHTMLとして解釈される恐れが無いため発火しません。

その他の対策#

エスケープが行えない場合の対策です。根本的な対策と緩和策との区別が不明瞭であるため、その他の対策として紹介します。

DOMPurify の利用:#

DOMPurifyはJavaScript製のライブラリで、特定のタグ（<b>, <h1>, <i>等）のみを許可（ホワイトリスト形式）するサニタイズライブラリです。ユーザー入力を安全なHTMLに変換してからDOMに挿入することで、XSSの発生を防ぎます。自前でパースを行うのは現実的ではないため、このようなライブラリがよく用いられます。

const clean = DOMPurify.sanitize(userInput, {
 ALLOWED_TAGS: ["b", "i", "a"],
 ALLOWED_ATTR: ["href"]
});
element.innerHTML = clean;

内部的にはDOMを解析して危険なノードや属性を削除するため、単純な正規表現ベースのフィルタよりも堅牢です。また、SVGやMathMLといった複雑なケースにも対応しています。一方で、設定ミス（過剰な許可）により脆弱性を招く可能性があるため、最小権限の原則で許可リストを設計する必要があります。

また、ブラウザネイティブなライブラリではないため、非常に稀ですが、ブラウザ独自の仕様に対応しきれずバイパスされてしまうこともあります。ただし、この場合は脆弱性として認知され速やかに修正されるため、やはり自前でパース処理を書くよりも安全であると考えられます。

setHTML API (Sanitizer API):#

Sanitizer API はブラウザ標準で提供されるHTMLサニタイズ機構で、ユーザー入力などの不正なHTMLを安全な形に変換してDOMに挿入できます。従来の innerHTML はスクリプトやイベント属性（onerror など）をそのまま解釈してしまうため危険ですが、setHTML() を使うことで許可された要素・属性のみが反映されます。例えば以下のように利用します。

// setHTMLを実行
document.body.setHTML("<script>alert(1);</script><s onclick=alert(1)>TEXT</s><a href='javascript:alert(1)'>alert</a><a href='/top.html'>TOP</a><img src=1 />")

//<s>TEXT</s><a>alert</a><a href="/top.html">TOP</a> が返される
document.body.innerHTML;

このように <script> や onclick、さらには javascript: プロトコルまで自動で除去してくれます。便利な関数ですが、現状では一部のブラウザで実験的な機能（提案段階）です。