IPA 情報処理安全確保支援士試験（SC）頻出キーワード解説[3/4]

1. 序論：現代のセキュアプログラミングにおける脅威ランドスケープ
2. Webアプリケーションにおけるセッション管理とクッキーのセキュリティ
3. クライアントサイドセキュリティ：DOM Based XSSの詳細分析
4. サーバーサイドセキュリティ：Pythonにおける直列化の脆弱性
1. 4.1 Pickleモジュールと任意コード実行（RCE）
2. 4.2 機械学習モデルとサプライチェーン攻撃
5. 試験対策：重要用語と解説の包括的データベース
6. 結論と考察

1. 序論：現代のセキュアプログラミングにおける脅威ランドスケープ

情報処理安全確保支援士（RISS）試験において、セキュアプログラミングは単なるコードの記述規則を超え、システム全体の信頼性を担保するためのアーキテクチャ設計の中核をなす領域である。本報告書は、提供された調査資料に基づき、Webアプリケーションのセッション管理、クライアントサイドのスクリプト処理、およびサーバーサイドのオブジェクト直列化（シリアライゼーション）における脆弱性と対策について包括的に論じるものである。特に、HTTPプロトコル上での状態管理におけるクッキー属性の厳密な運用、DOM（Document Object Model）を介したクロスサイトスクリプティング（XSS）のメカニズム、そして近年機械学習（ML）システムの普及に伴い顕在化しているPythonのPickle脆弱性に焦点を当て、その深層を分析する。

2. Webアプリケーションにおけるセッション管理とクッキーのセキュリティ

HTTPプロトコルはステートレス（状態を持たない）であるという特性上、Webアプリケーションがユーザーのログイン状態を維持するためには、セッションID等の識別子をクライアントとサーバー間で安全に交換する仕組みが不可欠である。調査資料 ¹ および ¹ は、この交換メカニズムの中核を担うクッキー（Cookie）の属性設定と、それらが防ぐべき攻撃ベクタについて詳細な知見を提供している。

2.1 HTTP通信とHTTPS通信の根本的差異

セキュアなセッション管理の前提となるのは、通信経路の暗号化である。調査資料 ¹ によれば、HTTP通信とHTTPS通信の違いは、郵便における「ハガキ」と「封書」に例えられる。

HTTP（Hypertext Transfer Protocol）通信では、データは平文のままインターネット上を流れる。これは、カフェの無料Wi-Fiやインターネットサービスプロバイダ（ISP）の設備など、通信経路上にあるあらゆるノードにおいて、第三者がデータを盗聴可能であることを意味する ¹。攻撃者がパケットスニッフィングを行えば、セッションIDを含むすべてのヘッダ情報が露見し、なりすましが可能となる。

対してHTTPS（HTTP Secure）は、通信内容をSSL/TLSプロトコルによって暗号化する。これにより、通信経路上の第三者がデータを傍受したとしても、その内容は解読不能な乱数としてしか認識できない ¹。この「封書」による保護は、後述する Secure 属性の効果を発揮させるための必須要件である。

2.2 クッキー属性による多層防御メカニズム

セッションハイジャックやクロスサイトリクエストフォージェリ（CSRF）といった攻撃からユーザーを保護するために、開発者はクッキーに対して適切な属性（Attribute）を付与する必要がある。調査資料 ¹ および ¹ に基づき、主要な属性の機能と実装上の意義を分析する。

2.2.1 Secure属性：通信経路の保護

Secure 属性は、クッキーが暗号化された通信（HTTPS）においてのみ送信されることを強制する設定である ¹。

メカニズムと防御対象：サーバーが Set-Cookie: session_id=...; Secure というヘッダを送信すると、ブラウザはこのクッキーを保存する際、「HTTPS接続時のみ送信する」という制約を記録する。これにより、ユーザーが攻撃者の用意した罠サイトなどから http:// （非暗号化）のリンクへ誘導されたとしても、ブラウザはそのクッキーの送信を拒絶する 1。これは、中間者攻撃（Man-in-the-Middle Attack: MITM）や、公衆Wi-Fiにおける盗聴リスクに対する直接的な対抗策となる 1。
実装上の注意点：ローカル開発環境（localhost）などでHTTPSを使用していない場合、この属性を有効にするとクッキーが送信されず、ログイン機能などが正常に動作しなくなる可能性がある点は留意が必要である 1。

2.2.2 HttpOnly属性：XSSによるセッション奪取の防止

HttpOnly 属性は、クライアントサイドのスクリプト（主にJavaScript）からクッキーへのアクセスを禁止する設定である ¹。

メカニズムと防御対象：通常、JavaScriptは document.cookie プロパティを通じてクッキーの読み書きが可能である。しかし、HttpOnly 属性が付与されたクッキーは、ブラウザのJavaScriptエンジンから隠蔽される。これにより、アプリケーションにクロスサイトスクリプティング（XSS）の脆弱性が存在し、攻撃者が悪意のあるスクリプト（例：<script>alert(document.cookie)</script>）を実行させることに成功したとしても、セッションID自体はスクリプトから参照できず、攻撃者のサーバーへ送信されることを防ぐことができる 1。
セキュリティ上の位置づけ：この属性はXSSそのものを防ぐものではなく、XSSが成功した場合の被害（セッションハイジャック）を最小限に抑えるための「多層防御（Defense in Depth）」の最後の砦として機能する 1。

2.2.3 SameSite属性：CSRFへの対抗

SameSite 属性は、クッキーがクロスサイト（異なるドメイン間）のリクエストに含まれるかどうかを制御するものであり、クロスサイトリクエストフォージェリ（CSRF）に対する現代的な防御策である ¹。

Strict（厳格）：最も制限の強い設定であり、クッキーは同一サイト（Same Site）からのリクエストでのみ送信される。他のサイトから張られたリンク（トップレベルナビゲーション）をクリックして遷移した場合であっても、クッキーは送信されない。セキュリティは極めて高いが、外部からのリンクで遷移した際にログイン状態が維持されないため、ユーザビリティへの影響が大きい 1。
Lax（緩やか・推奨）：セキュリティとユーザビリティのバランスを考慮した設定であり、現代のブラウザにおけるデフォルトの挙動となっている。この設定では、画像埋め込みやiframeなどのサブリソース要求、およびPOSTメソッドなどの「安全でない」HTTPメソッドによるクロスサイトリクエストではクッキーの送信をブロックする。一方で、リンクのクリック（トップレベルのGETリクエスト）においてはクッキーの送信を許可するため、ユーザーは外部サイトから遷移してもログイン状態を維持できる 1。
None（なし）：すべてのクロスサイトリクエストにおいてクッキーの送信を許可する設定である。これは従来のクッキーの挙動と同様であるが、近年のセキュリティ標準では、SameSite=None を設定する場合は必ず Secure 属性を併用することが強制されている。つまり、暗号化されていない通信でクロスサイトクッキーを利用することはできない 1。

2.3 主要フレームワークにおける実装例

調査資料 ¹ は、Python（Flask）およびNode.js（Express）におけるこれらの属性の実装コードを提示している。これらのフレームワークでは、開発者が生のHTTPヘッダを操作するのではなく、設定オブジェクトを通じてセキュアなデフォルトを適用することが推奨される。

Python (Flask)：app.config = True および app.config = True と記述することで、フレームワークが生成するすべてのセッションクッキーに対し、自動的にこれらのフラグが付与される 1。
Node.js (Express)：express-session ミドルウェアの設定において、cookie: { secure: true, httpOnly: true, sameSite: 'lax' } とオブジェクト形式で指定することで、同様の保護が適用される 1。

2.4 セッション固定化攻撃（Session Fixation）に関する考察

調査資料 ¹ によれば、今回の調査範囲において「セッション固定化攻撃」の具体的な防御策に関する記述は確認できなかった。しかし、セッション管理の文脈において、この攻撃は「ログイン成功後に新しいセッションIDを発行する（Regeneration）」ことによって防ぐのが定石である。資料におけるこの情報の欠落は、クッキー属性による防御（ハイジャック対策）と、セッションIDのライフサイクル管理（固定化対策）が異なるレイヤーの対策であることを示唆している。

3. クライアントサイドセキュリティ：DOM Based XSSの詳細分析

Webアプリケーションのフロントエンドがリッチ化するにつれ、サーバーを介さずにブラウザ内部だけで完結する脆弱性、すなわちDOM Based XSS（Document Object Model Based Cross-Site Scripting）のリスクが増大している。調査資料 ² から ³ は、この脆弱性の発生機序を「ソース（Source）」と「シンク（Sink）」という概念を用いて詳細に解説している。

3.1 DOM Based XSSのメカニズムと特徴

従来の反射型（Reflected）XSSや蓄積型（Stored）XSSが、サーバーからのレスポンスに悪意あるスクリプトが含まれることで発生するのに対し、DOM Based XSSは、クライアントサイドのJavaScriptがDOMを安全でない方法で操作することによって発生する 3。

重要な点は、攻撃ペイロードがサーバーに送信されるとは限らないことである。例えば、URLのフラグメント識別子（#以降の部分）にペイロードが含まれる場合、この部分はブラウザ内でのみ処理され、サーバーへのHTTPリクエストには含まれない。そのため、WAF（Web Application Firewall）などのサーバーサイドの防御機構をすり抜ける可能性が高い 4。

3.2 ソース（Source）：汚染されたデータの入口

「ソース」とは、攻撃者がコントロール可能な入力データをJavaScriptが読み取るプロパティや関数を指す。ここから「汚染された（Tainted）」データがアプリケーション内に流入する。

主要なソース一覧²：
- location.href / document.URL / document.documentURI：現在のページのURL全体。
- location.search：URLのクエリパラメータ部分（?以降）。
- location.hash：URLのフラグメント部分（#以降）。ここはサーバーに送信されないため、DOM XSSの温床となりやすい。
- document.referrer：遷移元のURL。攻撃者は自分のサイトから被害者のサイトへリンクを張り、リファラにペイロードを含めることができる。
- window.name：ウィンドウ間でデータを共有するためのプロパティであり、クロスドメインで永続化するため、隠蔽された攻撃ベクトルとして利用されることがある。

3.3 シンク（Sink）：脆弱性の発火点

「シンク」とは、ソースから取り込まれたデータが最終的に到達し、実行またはレンダリングされる関数やDOM要素を指す。汚染されたデータが検証やサニタイジングを経ずにシンクに到達した瞬間、XSSが成立する。

実行シンク（Execution Sinks） 2：JavaScriptコードとして文字列を解釈・実行する機能群である。これらは最も危険度が高い。
- eval()：文字列をコードとして評価する。
- setTimeout() / setInterval()：第一引数に文字列を渡すと、コードとして実行される。
- execScript()：一部のブラウザにおける eval 相当の機能。
HTML要素シンク（HTML Element Sinks） 2：文字列をHTMLとしてレンダリングする機能群である。
- document.write() / document.writeln()：ドキュメントストリームにHTMLを書き込む。ページロード中にスクリプトタグが含まれていると即座に実行される。
- innerHTML / outerHTML：要素の内容を書き換える。現代のブラウザでは innerHTML で挿入された <script> タグは実行されない場合が多いが、<img src=x onerror=alert(1)> のようなイベントハンドラを用いた攻撃は依然として有効である。
ロケーションシンク（Location Sinks） 4：ページの遷移を制御するプロパティである。
- location.href / location.replace()：ここに javascript:alert(1) のような擬似プロトコルを設定することで、スクリプトを実行可能である。

3.4 攻撃シナリオ：PDFリンク生成における脆弱性

調査資料 6 および 5 は、具体的な攻撃シナリオを紹介している。

あるサイトが、URLパラメータに基づいてPDFファイルへのリンクを動的に生成するJavaScriptを使用しているとする。

攻撃者は http://www.vulnerable.site/page#config=javascript:malicious_code() というURLを作成し、被害者にクリックさせる。

被害者のブラウザでページがロードされる。
スクリプトが location.hash（ソース）から #config=... の部分を読み取る。
スクリプトは検証なしに <a href=" + 読み取った値 + ">Download PDF</a> というHTMLを生成し、DOMに追加する（シンク）。
被害者がこのリンクをクリック、あるいは自動的にクリックされる処理が走ると、javascript: プロトコルにより悪意あるコードが実行される。

この一連の流れ（ソースからシンクへのデータの移動）を追跡し、遮断することがDOM Based XSS対策の核心である。これを「テイント解析（Taint Analysis）」と呼ぶ ⁵。

4. サーバーサイドセキュリティ：Pythonにおける直列化の脆弱性

サーバーサイドプログラミング、特にPythonにおいては、オブジェクトの直列化（シリアライゼーション）に伴う脆弱性が重大なリスクとなっている。調査資料 ⁷ は、Python標準ライブラリである pickle モジュールの危険性と、それがAI/ML（人工知能・機械学習）サプライチェーンに与える影響について詳述している。

4.1 Pickleモジュールと任意コード実行（RCE）

pickle はPythonオブジェクトをバイト列に変換（シリアライズ）し、保存や転送を可能にするライブラリである。しかし、その設計思想は柔軟性を最優先しており、セキュリティ境界を持たない。

スタックベースの仮想マシン：Pickleフォーマットは、実際には単純なデータ形式ではなく、スタックベースの仮想マシンに対する命令列（オペコード）である。GLOBAL オペコードや REDUCE オペコードを使用することで、デシリアライズ（復元）時に任意のPython関数を呼び出すことが可能である 7。
__reduce__ メソッドの悪用：Pythonオブジェクトは __reduce__ という特殊メソッドを実装することで、自身のシリアライズ方法をカスタマイズできる。攻撃者はこのメソッドを悪用し、「復元時に os.system 関数を引数 rm -rf / で呼び出す」といった命令を含むオブジェクトを作成できる。このオブジェクトがPickle化されたデータをサーバーが読み込むと、デシリアライズの過程で自動的にコマンドが実行され、リモートコード実行（RCE）に至る 7。

4.2 機械学習モデルとサプライチェーン攻撃

このPickleの脆弱性は、近年急速に普及している機械学習の分野で深刻な問題を引き起こしている。

モデルファイルの実体：PyTorchなどの主要なMLフレームワークでは、学習済みモデルの保存形式（.pth ファイルなど）の内部で pickle を使用している。これは、インターネット上のリポジトリ（Hugging Faceなど）からダウンロードしたモデルファイルが、実は「実行可能なプログラム」であることを意味する 7。
具体的脅威事例：調査資料 7 によれば、2024年にはHugging Face上で悪意のあるPyTorchモデルが多数発見されたほか、MLflow（機械学習ライフサイクル管理ツール）においても、悪意あるモデルファイルによって任意コード実行が可能となる脆弱性（CVE-2024-37059）が報告されている。
対策の限界：picklescan のようなスキャンツールも開発されているが、CVE-2025-1945のようにバイパス手法が発見されるなど、イタチごっこの状態にある。根本的な対策は、信頼できないデータに対して pickle を絶対に使用しないことである 7。

5. 試験対策：重要用語と解説の包括的データベース

IPA試験において頻出する、また本調査で判明した重要用語を以下に体系化する。これらはコードレベルの脆弱性排除（セキュアプログラミング）の中核をなす知識である。

5.1 Webセキュリティ・セッション管理用語集

用語	カテゴリ	詳細解説	セキュリティ上の役割・対策
Secure属性	Cookie	クッキーの送信をHTTPS（暗号化）通信時に限定するフラグ。平文のHTTP通信ではブラウザがクッキーの送出をブロックする。	盗聴防止：中間者攻撃（MITM）によるセッションIDの窃取を防ぐ ¹。
HttpOnly属性	Cookie	JavaScriptからの `document.cookie` へのアクセスを禁止するフラグ。ブラウザの開発者ツールやHTTPヘッダでは確認可能だが、スクリプトからは隠蔽される。	XSS被害軽減：クロスサイトスクリプティング脆弱性が悪用された場合でも、セッションIDが盗まれることを防ぐ（XSS自体を防ぐものではない）¹。
SameSite属性	Cookie	クロスサイトリクエスト（別ドメインからの要求）に対するクッキーの送信挙動を制御する。`Strict`, `Lax`, `None` の3つのモードがある。	CSRF対策：意図しないサイトからのリクエスト送信時に認証クッキーを送らせないことで、なりすまし操作を防ぐ ¹。
SameSite=Lax	Cookie	現代のブラウザのデフォルト設定。画像読み込み等のサブリソースやPOSTメソッドではクッキーを送らないが、トップレベルの遷移（リンククリック等）では送る。	ユーザビリティとの両立：外部サイトからの遷移でログイン状態を維持しつつ、主要なCSRF攻撃を防ぐバランスの取れた設定 ¹。
SameSite=Strict	Cookie	最も厳格な設定。同一サイト内からのリクエスト以外では一切クッキーを送信しない。	高セキュリティ：銀行システムなど、利便性よりも安全性を最優先する場合に適する ¹。
SameSite=None	Cookie	従来のクッキーと同様、全てのクロスサイトリクエストで送信を許可する。ただし、`Secure` 属性の併用が必須。	互換性：サードパーティクッキーとして機能させる場合に必要だが、HTTPSが前提となる ¹。
セッションハイジャック	攻撃手法	正規ユーザーのセッションIDを盗み出し、そのユーザーになりすましてアクセスする攻撃。	脅威：Secure属性やHttpOnly属性が不適切な場合に発生リスクが高まる ¹。
HTTPS	プロトコル	SSL/TLSを用いてHTTP通信を暗号化するプロトコル。	基盤技術：セッションIDを含む機密情報をネットワーク上の盗聴から保護するために必須 ¹。

5.2 クライアントサイド（DOM）セキュリティ用語集

用語	カテゴリ	詳細解説	セキュリティ上の役割・対策
DOM Based XSS	攻撃手法	サーバーを介さず、ブラウザ上のDOM操作によって発生するXSS。URLフラグメントなどが攻撃経路となるため、サーバーログに残らない場合がある。	クライアントサイド対策：WAF等では検知困難なため、JavaScriptコード内での適切な入力検証と出力エンコーディングが不可欠 ³。
ソース (Source)	概念	攻撃者が操作可能な外部入力データを受け取るJavaScriptのプロパティや関数。Taint（汚れ）の発生源。	監視対象：`location.href`, `location.search`, `document.referrer`, `window.name` などが代表的 ²。
シンク (Sink)	概念	受け取ったデータを実行またはHTMLとして描画するJavaScriptの関数やDOM要素。Taintの到達点。	防御地点：`eval()`, `document.write()`, `innerHTML` などへのデータ受け渡しを厳格に管理する必要がある ²。
document.write	シンク	HTMLドキュメントに動的に文字列を書き込むメソッド。入力値に `<script>` が含まれると実行される。	非推奨API：DOM XSSの典型的な原因となるため、`textContent` などの安全な代替手段を使用すべきである ²。
innerHTML	シンク	要素の内部HTMLを書き換えるプロパティ。`<script>` タグは実行されない場合が多いが、イベントハンドラ（`onerror`等）によるスクリプト実行は可能。	要注意API：信頼できないデータを代入する場合は、事前にサニタイジング（無害化）が必要 ²。
eval()	シンク	文字列をJavaScriptコードとして評価・実行する関数。	危険な関数：「Eval is evil」と称されるほど危険性が高い。外部入力を渡すことは絶対避けるべきである ²。
location.hash	ソース	URLの `#` 以降の部分。サーバーには送信されないため、DOM Based XSSの主要な攻撃経路となる。	入力検証：画面上の表示制御などに利用する場合でも、想定された値（英数字のみ等）かどうかの検証が必須 ⁴。
テイント解析	解析手法	アプリケーション内でデータがどのように伝播するか（ソースからシンクへ）を追跡し、脆弱性を特定する手法。	静的・動的解析：JavaScriptコードのセキュリティレビューにおいて中心的な役割を果たす ⁵。

5.3 サーバーサイド・直列化セキュリティ用語集

用語	カテゴリ	詳細解説	セキュリティ上の役割・対策
Pickle	ライブラリ	Python標準のオブジェクト直列化モジュール。オブジェクトをバイト列に変換し、保存・転送可能にする。	使用上の警告：セキュリティ機構を持たないため、信頼できないデータ（ユーザー入力等）をデシリアライズしてはならない ⁷。
デシリアライズ	処理	直列化されたデータ（バイト列やJSON等）を元のオブジェクトに復元する処理。	攻撃点：この処理過程で、データに含まれる悪意ある命令が実行されるリスクがある ⁷。
reduce	Python	Pickle化の際に呼び出される特殊メソッド。オブジェクトの再構築方法（呼び出す関数と引数）を定義する。	悪用ベクトル：攻撃者はこのメソッドを細工し、`os.system` などの危険な関数を実行させるペイロードを作成する ⁷。
RCE (Remote Code Execution)	攻撃影響	遠隔からサーバー上で任意のコードを実行する攻撃。Pickle脆弱性が悪用された場合の典型的な被害。	甚大な被害：サーバーの完全な乗っ取り、データ漏洩、システム破壊につながる ⁷。
CVE-2024-37059	脆弱性事例	MLflowにおけるPickleの取り扱い不備に起因する脆弱性。悪意あるモデルファイルによるコード実行を許容した。	事例研究：機械学習プラットフォームにおけるセキュリティ対策の重要性を示す実例 ⁷。

6. 結論と考察

本調査により、IPA情報処理安全確保支援士試験におけるセキュアプログラミングの領域は、単なる「入力チェックの徹底」というレベルを超え、プロトコル仕様や言語仕様の深い理解に基づいたアーキテクチャ設計の問題へ及んでいることが明らかとなった。

Webセキュリティにおいては、開発者は Secure, HttpOnly, SameSite といったクッキー属性を適切に組み合わせ、ブラウザのセキュリティ機能を最大限に活用する「多層防御」のアプローチが求められる。特に SameSite 属性の理解は、近年のCSRF対策において必須知識である。

クライアントサイドにおいては、DOM Based XSSという「サーバーログに残らない攻撃」への理解が不可欠である。開発者は、location.hash や document.referrer といったデータが「汚染されている（Tainted）」可能性があるという前提に立ち、それらが innerHTML や eval といった危険な「シンク」に到達する前に遮断・無害化するコード設計を行わなければならない。

さらに、AI技術の進展に伴い、Pythonの pickle に代表される直列化ライブラリの脆弱性が新たな脅威として台頭している。これは、コードの記述ミスではなく、ライブラリの仕様そのものを悪用する攻撃であり、エンジニアには「信頼できないデータを決してデシリアライズしない」という原則の遵守が求められる。

総じて、セキュアプログラミングの実践には、攻撃者の視点（ソースからシンクへのデータフロー、通信パケットの盗聴、オブジェクト復元時の挙動）を持ち、それをコードと設定の両面から封じ込める多角的な能力が必要不可欠である。