ログは「信頼の根源」か、それとも「攻撃者の武器」か
現場でインシデント対応をしていると、決まって遭遇する景色がある。それは、攻撃者がシステム侵入の足がかりとして、あるいは証拠隠滅の手段として「ログ」を悪用している場面だ。
多くのエンジニアは「ログは記録を残すためのもの」と信じているが、セキュリティの最前線では「ログは攻撃者にとってのインジェクション・ベクター（攻撃の媒介者）」と認識すべきだ。今日は、君たちが今日書くコードに潜む「ログ汚染」と「情報漏洩」という2つの死神を追い払う方法を伝授する。
—
1. ログ偽装（Log Injection）の正体
攻撃者がログに改行コード（\r\n）を混入させると何が起きるか。彼らは、管理者の目を欺くために「偽のログ行」を生成する。
攻撃手法（PoC）のイメージ:
ログイン失敗を記録するログ機能に対し、攻撃者がユーザー名として以下の文字列を入力する。
admin\r\n[INFO] User admin logged in successfully from 127.0.0.1
ログファイルには以下のように記録される。
[WARN] Failed login attempt for user: admin
[INFO] User admin logged in successfully from 127.0.0.1
ログ監視ツールやSIEMは、この「成功した」という偽の行を読み込み、攻撃の痕跡を完全に隠蔽してしまう。これがログインジェクションの恐ろしさだ。
防御策：改行の無害化
ログ出力の直前で、改行コードを削除またはエスケープすることが鉄則だ。
Pythonによるセキュアな実装例:
import logging
import re
def sanitize_log(message):
“””
改行コード（LF, CR）を除去し、ログインジェクションを防ぐ
“””
return re.sub(r'[\r\n]’, ”, message)
使用例
user_input = “hacker\r\n[INFO] Login success”
safe_message = f”Failed login for user: {sanitize_log(user_input)}”
logging.warning(safe_message)
—
2. 「ログに機密情報を書くな」の真実
「パスワードやトークンをログに出すな」という教えは耳にタコができるほど聞かされてきただろう。だが、なぜ漏れるのか？ 答えは簡単だ。「ログ出力関数の引数に、バリデーション前のユーザー入力オブジェクトをそのまま突っ込んでいるから」だ。
特に、例外発生時のスタックトレースには要注意だ。多くのフレームワークはエラー発生時にリクエストパラメータ全体をダンプする設定になっている。これが、認証トークンやクレジットカード番号をログファイルへ垂れ流す原因となる。
防御策：動的なマスキング
特定のキーをフィルタリングする仕組みを、ロガーのラップ関数として実装する。
JavaScript (Node.js/Winston) での構成例:
const winston = require(‘winston’);
// ログ出力時に機密情報をマスクするフォーマット関数
const maskSensitiveData = winston.format((info) => {
const sensitiveKeys = [‘password’, ‘token’, ‘credit_card’];
sensitiveKeys.forEach(key => {
if (info[key]) {
info[key] = ‘‘; // 値を伏せ字にする
}
});
return info;
});
const logger = winston.createLogger({
format: winston.format.combine(
maskSensitiveData(),
winston.format.json()
),
transports: [new winston.transports.Console()]
});
// 使用例：これならトークンが含まれていてもログには出力されない
logger.info(‘User action’, { user_id: 123, token: ‘secret-auth-token-12345’ });
—
3. インフラ・クラウド層での「最後の砦」
アプリケーション側で完璧に防げれば理想だが、開発者のミスを考慮し、インフラ層でも多重防御（Defense in Depth）を敷いておくのがプロの流儀だ。
WAFでの攻撃遮断
WAFで「改行コードを含むリクエスト自体」を拒否するルールを定義しておく。
Nginx + ModSecurity (CRS) 設定の考え方:
改行コード(\r\n)を含むリクエストを検知してブロックする例
SecRule ARGS “@rx [\r\n]” \
“id:10001,phase:2,deny,status:403,msg:’Log Injection Attempt Detected'”
IAM・権限管理
ログファイルが保管されるS3バケット等のIAMポリシーは「最小権限の原則」を極限まで適用する。「ログを読み取れるユーザー」と「ログを分析するサービスアカウント」は物理的に分離するのが鉄則だ。
—
最後に：コードは「書く」よりも「守る」ことを意識せよ
君たちが書くログは、将来の自分や仲間のインシデント対応を助けるための重要な資産だ。だが、設計を疎かにすれば、そのログが自らの首を絞める凶器に変わる。
1. 入力値はすべて疑え：ログに出力する文字列は、たとえ内部データであってもサニタイズ（改行除去）を通すこと。
2. コンテキストを意識せよ：スタックトレースがどこに保存されるか、誰が読めるかを常に想像すること。
3. 自動化せよ：手動のチェックには限界がある。ログのマスク機能はライブラリ化し、全チームで共通のロガーを使うように強制せよ。
明日、出社したらまずは自分の書いたサービスのログファイルを見てみてほしい。そこに生のトークンや、ユーザーが入力した怪しげな文字列が混ざっていないかを確認すること。それが、一流のエンジニアへの第一歩だ。
何かあればいつでも相談してくれ。コードの脆弱性は、一緒に叩き潰していこう。
コメント