セキュアプログラミングと脆弱性対策

情報処理安全確保支援士試験の午前Ⅱでは、Webアプリケーションの脆弱性に関する出題が毎回のように見られ、その筆頭がSQLインジェクションである。攻撃者が入力欄にSQL文の断片を混入させ、データベースを不正に操作・窃取する攻撃であり、根本的解決はプレースホルダ(バインド機構)を用いてSQL文の組み立てを静的に行うことである。IPA「安全なウェブサイトの作り方」では、エスケープ処理は代替手段、WAFの導入は攻撃の影響を低減する「保険的対策」と位置付けられており、「根本的解決」と「保険的対策」の区別は頻出論点である。同系統のOSコマンドインジェクションは、外部からの入力がシェル経由でコマンドとして解釈されることに起因するため、シェルを起動できる関数(system等)の利用を避け、目的のみを実現するライブラリ関数で代替することが根本的解決となる。いずれも「外部入力を命令文の一部として解釈させない」という共通原理で整理すると、選択肢の判別が容易になる。

クロスサイトスクリプティング(XSS)は、攻撃者が仕掛けたスクリプトを利用者のブラウザ上で実行させる攻撃であり、反射型・格納型・DOM Basedの三類型の違いが問われる。根本的解決はウェブページに出力するすべての要素に対するエスケープ処理(「<」「>」「&」等をHTMLエンティティへ変換)であり、入力時のフィルタリングはあくまで補助にすぎない。属性値はダブルクォートで囲む、URLを出力する場合はhttpとhttpsのみ許可する、といった実装細部も午前Ⅱの選択肢に登場する。被害低減策としては、cookieへのHttpOnly属性付与によりスクリプトからのセッションID読み取りを防ぐこと、Content Security Policy(CSP)によりスクリプトの読み込み元を制限することが挙げられる。XSSはセッションハイジャック、偽ページの表示、マルウェア感染の起点となるため、「どの対策が根本的解決に当たるか」を問う形式で繰り返し出題されている。

クロスサイトリクエストフォージェリ(CSRF)は、ログイン済み利用者のブラウザから本人の意図しないリクエストを送信させ、退会処理や送金といった重要な処理を実行させる攻撃である。対策は、第三者に推測困難な秘密情報(CSRFトークン)をフォームに埋め込みサーバ側で照合する方式、重要処理の直前における再認証(パスワード再入力)の要求、Refererの確認等であり、cookieのSameSite属性(Lax/Strict)による緩和も近年の出題範囲に入っている。セッション管理では、セッションIDの推測・盗聴・固定化という三つの脅威を押さえる。特にセッションフィクセーションは、攻撃者が用意したセッションIDを被害者に使わせてログイン後のセッションを乗っ取る攻撃であり、ログイン成功時にセッションIDを再発行することが対策となる。セッションIDは暗号論的に安全な擬似乱数で生成し、URLに埋め込まず、cookieにはSecure属性を付与してTLS経由でのみ送信することが求められる。

その他のWeb脆弱性として、ディレクトリトラバーサル(「../」等の相対パス指定により公開を意図しないファイルへアクセスする攻撃)、HTTPヘッダインジェクション(改行コードの混入によりレスポンスヘッダや本文を偽造する攻撃)、クリックジャッキング(透明にしたiframeを正規ページに重ね、利用者に意図しないクリック操作をさせる攻撃)、メールヘッダインジェクションが頻出である。クリックジャッキングの対策は、X-Frame-OptionsヘッダまたはCSPのframe-ancestorsディレクティブにより他サイトのフレーム内での表示を制限することである。近年は、脆弱な公開サーバに内部ネットワークやクラウドのメタデータサービスへのリクエストを代行させるサーバサイドリクエストフォージェリ(SSRF)、XML外部実体参照(XXE)、安全でないデシリアライゼーションの出題も増えており、OWASP Top 10の項目名と攻撃原理を対応付けて整理しておくべきである。

C/C++等で実装されたプログラムでは、バッファオーバーフローが最重要論点である。境界検査を行わないstrcpy等の関数により確保領域を超えた書き込みが行われると、スタック上のリターンアドレスが改ざんされ、攻撃者の用意したコードへ制御が移る。対策は、境界検査を行う関数への置換や入力長の検査という根本的対策に加え、OS・コンパイラ側の緩和技術としてASLR(アドレス空間配置のランダム化)、DEP/NXビット(データ領域でのコード実行防止)、スタックカナリア(リターンアドレス近傍に置いた検査値の改変検知)の三者の機能の違いを問う四択が午前Ⅱの定番である。また、書式文字列攻撃、整数オーバーフロー、競合状態(レースコンディション)も出題される。特にTOCTOU(Time of Check to Time of Use)は、資源の検査と使用の間のわずかな時間差を突いてファイル等を差し替える攻撃であり、排他制御やアトミックな操作で対処する。

脆弱性を識別・評価する共通基盤も体系的に問われる。CVEは個々の脆弱性に一意の識別子を付与する共通脆弱性識別子、CWEはSQLインジェクションやバッファオーバーフロー等の脆弱性の種類を分類する共通脆弱性タイプ一覧、CVSSは深刻度を評価する共通脆弱性評価システムであり、CVSSは基本評価基準・現状評価基準・環境評価基準の三つの基準から成る。基本評価基準は脆弱性そのものの特性を評価するため時間の経過では変化せず、攻撃コードの出現や対策情報の提供状況により変化するのは現状評価基準である点がひっかけとして出題される。国内制度では、経済産業省告示「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」に基づく情報セキュリティ早期警戒パートナーシップにおいて、IPAが脆弱性関連情報の届出受付機関、JPCERT/CCが製品開発者との調整機関を担い、対策情報はJVN(Japan Vulnerability Notes)で公表される。この役割分担は午前Ⅱで繰り返し問われている。

セキュアプログラミングは個別のコーディング技法にとどまらず、開発ライフサイクル全体に組み込むことが求められる。企画・設計段階からセキュリティを作り込むセキュリティバイデザイン、処理が失敗したときにシステムを安全側に倒すフェールセーフ、プログラムやプロセスを必要最小限の権限で動作させる最小権限の原則が基本原則である。入力値検証は、許可する形式をあらかじめ定義してそれ以外を拒否するホワイトリスト方式が、既知の危険パターンのみ排除するブラックリスト方式より堅牢とされる。検証手法としては、ソースコードを実行せずに解析する静的解析(SAST)、実行中の挙動を外部から検査する動的解析(DAST)、問題を起こしそうなデータを大量に送り込んで異常を検出するファジングが出題される。加えて、第三者によるペネトレーションテストや脆弱性診断を組み合わせ、リリース後もJVN等の脆弱性対策情報を継続的に監視して修正プログラムを適用する運用までを含めて理解しておきたい。