フロントエンド実装系の攻撃と対策

攻撃視点の分類 → セキュリティ脅威マップ / レイヤーC「クラウドとアプリ実装」

人が見ているWebページ(=表側)に悪いしかけを仕込み、訪れた人をだましたり、その人の操作を乗っ取る 攻撃の総称。フロントエンドとは、ブラウザに表示されてユーザーが直接さわる部分のこと。ここに細工が混ざると、利用者は 「見ているだけ」「いつもの操作をしただけ」 なのに、パスワードやログイン状態をこっそり奪われたり、意図しない送金・設定変更をさせられたりする。攻撃の中心は「作る人」が防ぐべきものだが、何が起きているのかは全員が知っておきたい。

このページの読み方 — 🟢 は全員が知っておく基礎、🔧 はエンジニア・運用担当者向けの実装/設定。このジャンルは“作る人”の対策が主役なので、🟢は短め・🔧が本体。まず🟢を全員で、🔧は技術担当が押さえる。

1. このジャンルの攻撃とは

Webページは、サーバーから送られてきた文章だけでなく、ブラウザの中で動く小さなプログラム(JavaScript) を含んでいる。このしくみを悪用して、攻撃者は表側に細工を仕込み、

  • ページに悪いプログラムを差し込む — 訪れた人のブラウザで勝手に動かす(XSS=Cross-Site Scripting=Webページに悪いプログラムを差し込む)
  • ログイン中の利用者にこっそり操作させる — 本人の知らないうちに送金や設定変更(CSRF=Cross-Site Request Forgery=ログイン中の利用者にこっそり操作させる)
  • 見た目をだまして誤クリックさせる — 透明なボタンを重ねる(クリックジャッキング=透明なボタンを重ねて誤クリックさせる)

ことを狙う。利用者は普通に使っているだけなので 「だまされた自覚がない」 のが怖いところ。だからこそ、入口をふさぐのは作る人の責任になる。

2. 主な手口

手口 しくみ(何が起きているか)
XSS(反射型) リンクのURLに悪いプログラムを混ぜ、そのリンクを踏ませた瞬間にブラウザで実行させる。1回かぎりの“反射”型。
XSS(格納型) 掲示板・コメント・プロフィールなどに悪いプログラムを保存し、ページを見た全員 のブラウザで実行させる。被害が広がりやすい。
XSS(DOM型) サーバーを経由せず、ブラウザ内で動くJavaScriptがURLや入力を雑に画面へ反映してしまい、その場で悪いプログラムが動く。
CSRF ログイン中の利用者に、本人が気づかないまま「送金」「パスワード変更」などのリクエストを送らせる(=ログイン中の利用者にこっそり操作させる)。
クリックジャッキング 本物のボタンの上に 透明なフレーム を重ね、別のボタンを押したつもりで攻撃者の用意した操作をさせる(=透明なボタンを重ねて誤クリックさせる)。
オープンリダイレクト 「このサイト→外部へ転送」する機能を悪用し、信頼できるサイト経由で偽サイトへ転送 する。URLの先頭が本物なので油断させやすい。
機密情報のフロント露出 APIキーやパスワードを、ブラウザに送られるJavaScriptにそのまま書いてしまう。表側のコードは 誰でも中身を見られる ので筒抜けになる。
依存ライブラリ経由の混入 npm等で取り込んだ外部の部品(ライブラリ)に悪性スクリプトが紛れ込み、それを読み込んだサイト全員に被害が及ぶ。
Cookie / トークンの盗難 XSS等でブラウザに保存されたログインの合鍵(Cookieやトークン)を抜き取り、本人になりすましてログインする。

3. 実例・典型シナリオ

  • 掲示板に仕込まれたスクリプト(格納型XSS): コメント欄に悪意のあるプログラムを書き込んでおくと、その投稿を 閲覧した人のブラウザ でそれが動き、ログイン用のCookieが攻撃者へ送られてアカウントを乗っ取られる。
  • 透明な偽ボタン(クリックジャッキング): 「無料プレゼント受け取り」ボタンに見せかけたページに、実は本物のSNSの「フォローする」「送金する」ボタンを透明フレームで重ねておく。利用者はプレゼントを押したつもりが、攻撃者に都合のよい操作をさせられる。
  • 踏んだだけで送金(CSRF): 銀行サイトにログインしたまま別タブで細工ページを開くと、そのページが裏で送金リクエストを送り、本人は何も入力していないのに 意図しない送金や設定変更が実行される。
  • 信頼サイト経由の誘導(オープンリダイレクト): 本物のサービスのURLなのに、転送機能を悪用されて最終的に偽ログイン画面へ飛ばされ、フィッシングに使われる。

4. 対策

🟢 基礎(全員がやること)

※このジャンルの被害は主に「作る人」の対策で防ぎます。利用者側でできるのは、あやしい動きに乗らないことです。

  1. 見覚えのないポップアップや「許可して」「インストール」に安易にOKしない — ページが急に何かを求めてきたら一拍おく。
  2. ブラウザと拡張機能は最新・最小限に — 拡張機能は表側を書きかえられるので、出どころの不明なものは入れない。使わないものは削除。
  3. あやしいサイトでログインしない — URLのドメインをよく見て、少しでも違和感があれば公式アプリ/ブックマークから入り直す。

🔧 応用(エンジニア・運用)

  1. 出力エスケープ/サニタイズ — 画面に出す前に、ユーザー入力を そのまま実行されない形 に変換(エスケープ)する。HTMLを許可する箇所はサニタイズ(危険なタグ・属性の除去)を必ず通す。XSS対策の本丸。
  2. CSP(Content-Security-Policy)を設定 — 「このページが読み込んでよいスクリプトの出どころ」をブラウザに宣言するヘッダー。許可外のスクリプトを実行させず、XSSの被害を大幅に抑える保険。
  3. Cookieに HttpOnly + Secure + SameSiteHttpOnlyでJavaScriptから読めなくし(盗難防止)、Secureで暗号化通信のみに限定、SameSiteで別サイトからの送信を制限してCSRFを抑える。
  4. CSRFトークン — 正規の画面から発行した使い捨ての合言葉をリクエストに添付させ、外部の細工ページからの操作を弾く。
  5. X-Frame-Options / frame-ancestors — 自サイトを他サイトの透明フレームに埋め込めなくする設定。クリックジャッキング対策 の定番(frame-ancestorsはCSP側の指定)。
  6. 入力検証 — 受け取る値の形式・長さ・種類をサーバー側でも厳密にチェックする(表側のチェックだけに頼らない)。
  7. 依存の監査npm audit 等で取り込んだライブラリの既知の脆弱性を定期チェックし、更新する。出どころのあやしい部品は使わない。
  8. フロントに秘密情報を置かない — APIキー・パスワード・トークンをブラウザに送るコードへ書かない。秘密はサーバー側で扱い、表側からは見えなくする。

5. 解説動画(実在確認済み)

フロントエンド単独テーマのIPA公式動画はID確証がないため、特定動画は埋め込まず、実在する公式ページへのリンク のみ掲載する。

6. チェックリスト

🟢 全員

  • 見覚えのないポップアップや「許可して」「インストール」に安易にOKしていない
  • ブラウザを最新に保ち、拡張機能は必要最小限にしている
  • ログイン前にURLのドメインを確認する癖がある

🔧 エンジニア・運用

  • ユーザー入力は表示前にエスケープ/サニタイズしている
  • CSP(Content-Security-Policy)を設定し、許可外スクリプトを実行させない
  • CookieにHttpOnly + Secure + SameSiteを付与している
  • 状態を変える操作にCSRFトークンを導入している
  • X-Frame-Options / frame-ancestors でフレーム埋め込みを制限している(クリックジャッキング対策)
  • サーバー側でも入力検証を行っている(表側のチェックに依存しない)
  • npm audit 等で依存ライブラリを定期監査し更新している
  • APIキー・トークン等の秘密情報をフロントのコードに置いていない

7. 関連ジャンル・出典

関連ジャンル

出典(一次情報)

  • OWASP — Top 10、Cheat Sheet Series(XSS / CSRF / Clickjacking 等の実装ガイド)
  • IPA「映像で知る情報セキュリティ」 — https://www.ipa.go.jp/security/videos/index.html
  • MDN Web Docs — CSP / Cookie属性 / X-Frame-Options などWeb標準のリファレンス

合わせて読む