設定ミス
このタグの記事 11 件
米ワシントンDCのメディケイド情報露出（約40万人）：公開報告書に残った受給者番号と、受給者・公開する側がやること
米ワシントンDC（コロンビア特別区）でメディケイド（低所得者向けの公的医療保険）を運営する医療保険財政局（DHCF）は、同局のウェブサイトに2023年から2026年7月まで掲載していた統計報告書2件に、集計の元になった個人データが「隠しフィールド」として含まれ、権限のない人が見られる状態だったと公表した。含まれていたのはメディケイド番号、生年月日、医療機関名、人種、性別、居住区（ward）、民族で、氏名、社会保障番号、金融口座の情報は含まれていないとしている。2026年7月21日に把握し、報告書を削除した。米保健福祉省（HHS）への届出では対象は399,086人。当サイトの結論：画面に集計しか見えない報告書でも、ファイルの中に元のデータが残ることがある。受給者は心当たりのない受診記録に注意し、報告書を公開する側は、元データを含まないファイルを作り直して公開する。
クラウドストレージの公開設定ミス：パブリックアクセスのブロックを有効にしても漏れる場合
バケットからの漏えいは攻撃ではなく設定で起きる。公式ドキュメントの要点は『パブリックアクセスブロックは既存のポリシーやACLを変更しない』——つまりブロックを有効にしても公開設定は残り、外せば公開が戻る。だから目標は『ブロックが有効』ではなく『ブロックを外しても公開されない状態』。ブロックはバケット単位でなくアカウント単位で掛ける（バケットポリシーはバケット側の設定を無効化できるため）。そして『公開』の定義は直感より広い。
よくあるセキュリティの失敗4つ：初期設定・閉じ忘れ・監視不足・入力検証の思い込み
事故は珍しい攻撃ではなく、決まった型から起きる。技術分類ではなく『誤った前提』で整理すると4つになる——既定値は安全なはず（設定を触っていない）、使っていないものは危なくないはず（閉じ忘れ）、何かあれば気づくはず（見えていない）、入力は検証すれば安全なはず（外部に決めさせすぎ）。どれも個々の技術知識ではなく、確認の習慣で防げる。自分の環境で何を見ればよいかを型ごとにまとめた。
ASP.NET Coreのセキュリティ対策 — 本番ハードニング実務リファレンス
ASP.NET Coreは成熟して安定したフレームワークだが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番で詳細エラー/開発者例外ページを露出しない・秘密の外部化(User Secrets/環境/Key Vault)・NuGet依存CVE・認可([Authorize]・フォールバックで既定拒否・リソースベース/所有者)・over-posting(DTO/[Bind])・安全でないデシリアライズ(BinaryFormatter回避)・HTTPS/ヘッダ/antiforgery・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Djangoのセキュリティ対策 — 本番ハードニング実務リファレンス
Djangoは標準で多くの安全な既定(ORM・CSRF・自動エスケープ・認証)を備えるが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番DEBUG=False＋ALLOWED_HOSTS・SECRET_KEYの外部化・pip依存CVE・本番セキュリティ設定(SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE等)・認可(所有者スコープ)・インジェクションと出力(raw/extra・mark_safe)・CSRF/セッション/管理画面・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
フレームワーク別セキュリティ対策 — 使っている技術ごとの守り方
フレームワークが変わっても、狙われる弱点の種類（アクセス制御・秘密の扱い・インジェクション・依存CVE・設定ミス）はほぼ共通。違うのは『既定の危険な設定』と『その技術でよく狙われる場所』。当サイトは各フレームワークの既定の注意点とハードニング手順をそれぞれまとめている。まずは自分が使っているフレームワークの章へ。
Laravelのセキュリティ対策 — 本番ハードニング実務リファレンス
Laravelの既定は安全寄りだが、本番事故は設定・運用から起きる。本ページは実務リファレンス。(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)危険な既定設定の一覧表 (3)領域別の具体対策＝秘密/APP_KEY・本番設定(APP_DEBUG/キャッシュ)・認可(Policy/Gate・Mass Assignment)・インジェクション/出力(Eloquentバインド・Blade)・セッション/CSRF/Cookie・アップロード・HTTPS/ヘッダ/レート制限・依存(Composer)CVE (4)自己検証チェック。攻撃手順は扱わず、防御と点検に限定。
Spring Bootのセキュリティ対策 — 本番ハードニング実務リファレンス
Spring Bootは安定したフレームワークだが、事故は依存・設定・認可から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝依存CVE(Log4Shell系・実稼働版で判定)・本番設定と秘密の外部化・Spring Securityの認可(既定拒否/メソッド認可/所有者チェック)・Actuator/管理面の露出削減・安全でないデシリアライズ・インジェクション・ヘッダ/CSRF/セッション・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
公開ディレクトリに秘密ファイルを置き忘れていないか：webrootの棚卸し
webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら、全サイトの同じ場所に同じファイルがある。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。
X-Forwarded-For（XFF）偽装とは：信頼するプロキシの設定ミスと防御
XFFはクライアントが詐称できるヘッダ。偽XFFにインジェクション探索の文字列を入れる無差別スキャンのよくある例と、『全プロキシ信頼（ワイルドカード）』設定の危険性。応急処置はIPヘッダのサニタイズ、根本対策は信頼するプロキシの設定の見直し。実害ゼロでも直すべき設定がある。
Laravelの.envが外部から見られる状態だった事例：共用レンタルサーバーでの配置ミスと直し方
原因は『アプリ本体をpublic_html直下に置いた』こと。public/ だけを見せるべきだった。応急処置→キーの再発行→構造改修の三段で直し、再発を仕組みで防ぐ。