アクセス制御
このタグの記事 11 件
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
アップロードの穴の本質は『受け取ること』ではなく『どこに置き、実行させてしまうか』。認証なしの投稿口＋型検証なし＋Web公開領域に保存＋そこでスクリプトが実行できる、が揃うとWebシェル→RCEで乗っ取られる。守りは多層：①エンドポイントに認証/権限＋CSRF②サーバー側で許可リスト＋中身検査③保存先はWeb公開領域の外（or実行無効化）④ファイル名を乱数化しパスは信用しない。1枚の壁でなく、各段の止め所を複数持つ。
PCI DSS とは — クレジットカード情報を扱うためのセキュリティ基準
PCI DSS(Payment Card Industry Data Security Standard)は、カード情報を保存・処理・伝送する事業者が満たすべき国際的なセキュリティ基準。カード国際ブランドが策定し、ネットワーク保護・保存データの暗号化・アクセス制御(必要最小限)・監視/ログ・脆弱性管理などを要求する。実務で最も安全なのは『自前でカード番号を保持せず、準拠済みの決済代行(トークン化)に任せて適用範囲を最小化する』こと。
OWASP Top 10 とは — Webアプリで最も重大な10大リスクの定番リスト
OWASP Top 10 は、非営利団体 OWASP が数年ごとに公開する『Webアプリで最も重大な10大リスク』のリスト。開発者・運営者の共通言語として広く使われる。最新版(2021)の筆頭は『アクセス制御の不備(Broken Access Control)』で、以下インジェクション・設定ミス・脆弱で古いコンポーネント・認証の不備などが並ぶ。個別の攻撃手法ではなく“リスクのカテゴリ”なので、自分のアプリを点検する観点として使うのが正しい。
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)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Express（Node.js）のセキュリティ対策 — 本番ハードニング実務リファレンス
Expressは最小主義＝既定でほぼ守らない。守りは開発者が自分で足す。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Laravelのセキュリティ対策 — 本番ハードニング実務リファレンス
Laravelの既定は堅いが、本番事故は設定・運用から起きる。本ページは実務リファレンス。(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)危険な既定設定の一覧表 (3)領域別の具体対策＝秘密/APP_KEY・本番設定(APP_DEBUG/キャッシュ)・認可(Policy/Gate・Mass Assignment)・インジェクション/出力(Eloquentバインド・Blade)・セッション/CSRF/Cookie・アップロード・HTTPS/ヘッダ/レート制限・依存(Composer)CVE (4)自己検証チェック。攻撃手順は扱わず、防御と点検に限定。
Ruby on Railsのセキュリティ対策 — 本番ハードニング実務リファレンス
Railsは規約と安全な既定(CSRF保護・Strong Parameters・ORM)を備えるが、本番事故は運用から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝秘密とcredentials(master key/secret_key_base)・本番設定(force_ssl・例外非露出)・gem CVE・Strong Parameters/Mass Assignment・認可(Pundit等・所有者スコープ)・インジェクションと危険メソッド(where連結/send/constantize)・セッション/Cookie/CSRF・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)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス
Next.jsの既定は安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝境界と環境変数(NEXT_PUBLIC_)・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可＋入力検証・SSRF(サーバー側fetch)・セキュリティヘッダ/CSP・認証/セッション/Cookie・レート制限 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
ログインを付けただけで安心していないか — 認証と認可の違い
認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故る前に／新規登録を検知。
IDORとは — IDを書き換えるだけで他人のデータが見えてしまう穴
IDORは、?id=124 を 125 に書き換えるだけで他人の請求書・個人情報が見える、アクセス制御不備の脆弱性。本命の防御は『サーバー側で“このログイン中の利用者が、この対象を見てよいか”を毎回チェックする』。推測されにくいIDは対策にならない。