クロスサイト・スクリプティング
クロスサイト・スクリプティング(以下、XSS:Cross-Site Scripting)は、Webアプリケーションの脆弱性を利用した代表的なサイバー攻撃の1つであり、またその脆弱性自体のことも指します。
攻撃者が脆弱性のある Webサイトに悪意のある JavaScript などのスクリプトを仕込み、そのサイトを訪れたユーザのブラウザ上でそのスクリプトを実行させる仕組みです。
主な被害と影響
ユーザのブラウザ上で任意のスクリプトが実行されるため、以下のような被害につながる危険性があります。
- セッション乗っ取り:
クッキー(Cookie)やセッションIDが盗み出され、被害者になりすましてサービスにログインされる。 - 偽情報の表示・改ざん:
サイトの表示内容を書き換え、ユーザに偽の入力フォーム(フィッシングサイト)を表示してパスワードや個人情報を入力させる。 - 不正なリダイレクト:
別の悪意あるサイトへ強制的に転送される。 - API の不正利用:
ログイン中のユーザ権限で、勝手に投稿を行ったり設定を変更したりする。
代表的な3つのタイプ
XSSは、スクリプトがどのように仕込まれ、実行されるかによって主に3つに分類されます。
- 格納型 XSS(Stored XSS)
- 仕組み:掲示板の投稿、コメントなどのデータベースに悪意のあるスクリプトが保存される。
- 特徴:そのページを閲覧したすべてのユーザのブラウザでスクリプトが実行されるため、影響範囲が広くなる。
- 反射型 XSS(Reflected XSS)
- 仕組み:検索窓など、ユーザが入力した内容がそのままレスポンスに反映される仕組みが利用される。攻撃者は悪意のあるスクリプトを含んだリンクを作成し、メールやSNSなどでユーザに踏ませる。
- 特徴:クリックしたユーザのブラウザでのみスクリプトが実行される(サーバ側には保存されない)。
- DOMベース XSS(DOM-based XSS)
- 仕組み:ブラウザ内の JavaScript の処理(DOMの操作)に問題がある場合に発生する。URLのハッシュフラグメント(#以降)やパラメータなどを JavaScript が安全でない方法で処理することで引き起こされる。
格納型XSSの攻撃の仕組み
格納型XSSの攻撃の仕組みは以下になります。

-
- ①:攻撃者が、コメント欄などを通じて悪意あるスクリプトをサイトに保存させる。
- ②③:被害者が普通にページを開くと、サイトは保存されたスクリプトをそのまま含めて返す。
- ④:被害者のブラウザは「サイトから届いたもの」と信じて、スクリプトを実行する。
- ⑤:スクリプトがセッションクッキーなどを攻撃者に送信し、セッション・ハイジャックにつながる。
主な対策
XSS を防ぐためには、Webアプリケーションの開発段階で適切な対策を講じることが不可欠です。
- エスケープ処理の徹底(出力値の無害化)
ユーザから入力されたデータを画面に出力する際、HTMLの構文として解釈される特殊文字(&, <, >, “, ‘ など)を、実体参照(<, > など)に変換する。 - Content Security Policy(CSP)の導入
HTTPヘッダで、ブラウザが実行してよいスクリプトの送信元を制限し、仮に脆弱性をつかれても外部スクリプトの読み込みや実行を防ぐ。 - Cookieの属性設定(HttpOnly 属性)
セッションID などを格納するクッキーに HttpOnly 属性を付与することで、JavaScript からクッキーにアクセスできなくし、セッションハイジャックのリスクを軽減する。
クロスサイト・リクエスト・フォージェリ
クロスサイト・リクエスト・フォージェリ(以下、CSRF:Cross-Site Request Forgery)は、Webアプリケーションの脆弱性を利用し、認証済みのユーザに意図しない操作(パスワード変更、送金、設定変更など)を強制的に実行させるサイバー攻撃およびその脆弱性のことです。
攻撃の仕組み
CSRFは、ブラウザが、対象サイトへアクセスする際に自動的にクッキー(Cookie)を送信する仕様を悪用します。一般的な攻撃の流れは以下の通りです。

-
- ①:被害者が正規サイトにログインし、ブラウザがセッションクッキーを保持する。
- ②③:被害者がログアウトしないまま罠サイトを開くと、罠サイトは送金などの偽リクエストを仕込んだページを返す。
- ④:ブラウザは、リクエストの発生元に関係なく、正規サイトのクッキーを自動的に付けて送信する。
- ⑤:正規サイトはクッキーが正しいため、本人の操作と判断し、処理を実行する。
主な被害と影響
CSRFによって、ユーザーが意図しない以下のような操作が実行される危険性があります。
- 不正な送金・決済:
ネットバンキングやECサイトで、勝手にお金が移動されたり商品が購入されたりする。 - アカウント情報の書き換え:
登録されているメールアドレスやパスワードが勝手に変更され、アカウントが乗っ取られる。 - 意図しない投稿・設定変更:
SNSや掲示板などで、ユーザの意図しない内容が勝手に投稿・拡散される。
代表的な対策
CSRFを防ぐためには、サーバ側でそのリクエストが本当にユーザ自身の意図した操作であるかを検証する仕組みを実装する必要があります。
- Anti-CSRF トークンの導入(最も確実な対策)
セッションごとにトークン(推測困難なランダムな値)を生成し、正規の入力フォームやリクエストに含める。サーバ側で受信したトークンとセッション内のトークンが一致するかを検証することで、外部サイトからの不正なリクエストを遮断する。 - クッキーの SameSite 属性の設定
セッションクッキーに SameSite=Lax または SameSite=Strict を指定することで、外部サイトから送信されたリクエストにクッキーが含まれないように制限する。 - 重要操作時の再認証
パスワード変更や資金移動などのクリティカルな処理を行う際、パスワードの再入力を求めることで、自動的なリクエストの乱用を防ぐ。 - カスタムリクエストヘッダーの利用
JavaScript(Fetch API や XMLHttpRequest)を用いて独自のカスタムヘッダを付与し、クロスドメインからのリクエストを制限します。
セッション・ハイジャック
セッション・ハイジャック(Session Hijacking)は、Webアプリケーションにおけるユーザのセッション(ログイン状態)を何者かに乗っ取られるサイバー攻撃およびその脆弱性の総称です。
攻撃者がセッションIDを不正に入手・推測することで、被害者になりすましてシステムへアクセスし、不正な操作(個人情報の閲覧、不正送金、データの改ざんなど)を行います。
セッションIDの役割
Web通信に使用されているHTTPはステートレス(状態を保持しない)であるため、ページを移動するたびにログインし直さなくて済むよう、サーバ側でログイン状態を識別するためのセッションIDを発行し、ブラウザ側に保存させます。
攻撃者は、このセッションIDを盗み出せば、パスワードを入力しなくてもそのユーザになりすますことができます。
セッション・ハイジャックの仕組み
セッション・ハイジャックの仕組みは以下になります。

-
- ①②:被害者が正規サイトにログインし、サイトはセッションIDを発行する。
- ③:攻撃者がそのIDを不正入手する。
- ④:攻撃者は盗んだIDを使って、自分でサイトにアクセスする。
- ⑤:サイトはIDが正しいので、攻撃者を認証済みの本人として扱う。
セッションIDを不正入手する手口
セッションIDを不正に入手する手口には、主に以下のようなものがあります。
- セッションIDの盗聴(Sniffing)
暗号化されていない通信(HTTP)を使用している場合、Wi-Fiの盗聴などにより、通信経路上でセッションIDが傍受される。 - クロスサイト・スクリプティング(XSS)の悪用
WebアプリにXSSの脆弱性がある場合、悪意あるスクリプトを実行してクッキーなどからセッションIDを読み取り、攻撃者のサーバへ送信する。 - セッションIDの予測(脆弱な生成アルゴリズム)
セッションIDが連番や推測しやすい規則で作られている場合、総当たり攻撃などで有効なIDを見つけ出される。
また、ログイン前のセッションIDを攻撃者が固定・誘導するセッション固定攻撃(Session Fixation)という手法もある。 - マイク・カメラや物理的盗み見
端末の画面を盗み見られたり、マルウェアによってブラウザのキャッシュから直接セッション情報が盗まれる。
主な被害と影響
セッション・ハイジャックが成立してしまうと、以下のような深刻な被害を受けます。
- アカウントの完全な乗っ取り:
被害者の権限でシステム内のすべての操作が可能になる。 - 機密情報の漏洩:
クレジットカード情報、住所、個人情報、プライベートなメッセージなどが盗まれる。 - 不正なトランザクション:
ネットバンキングでの勝手な送金や、ECサイトでの不正購入。
主な対策
セッション・ハイジャックを防ぐためには、セッションIDの保護と、安全なライフサイクル管理が重要です。
- 通信の完全暗号化(HTTPSの強制)
すべての通信をHTTPS(SSL/TLS)化し、通信経路での盗聴や改ざんを防止します(HSTSの導入も有効)。 - Cookieへの属性付与 (HttpOnly と Secure)
HttpOnly 属性を付与することで、JavaScriptからクッキー(セッションID)へのアクセスを禁止し、XSSによる窃取を防ぐ。また、Secure 属性により、HTTPS通信時のみクッキーが送信されるようにする。 - 強固なセッションIDの生成
推測困難で十分なランダム性を持ったセッションIDを、安全な乱数生成器を用いて生成する。 - ログイン前後でのセッションIDの再発行
ログインが成功したタイミングで、それまでのセッションIDを破棄し、新しいセッションIDを発行することで、セッション固定攻撃を防ぐ。 - 適切な有効期限(タイムアウト)の設定
一定時間操作がない場合や、ブラウザを閉じた際にセッションが切れるよう適切な有効期限を設定する。



