【開発者向け】Webアプリの脆弱性対策｜SQLインジェクションやXSSを防ぐ方法

セキュリティ
2026.02.03

ウェブアプリケーションにおける脆弱性について、発生しうる脅威と対策を紹介します。
本書はSQLインジェクション、OSコマンドインジェクション、XSS(クロスサイトスクリプティング)、CSRF（クロスサイト・リクエスト・フォージェリ）攻撃の仕組みや対策を紹介します。
また、本書はWEBアプリケーション開発について基礎知識がある方向けに書かれています。

SQLインジェクション

SQLインジェクションは、Webサイトの入力欄を悪用して、データベースを不正に操作してしまう攻撃 のことです。
例えば、本来は検索条件をのための入力欄なのに、そこに命令文を入れてSQLの操作をされてしまうのがポイントです。

発生しうる脅威

・データベースの不正閲覧・改ざん・削除
・認証回避、管理者権限の奪取

SQLインジェクションの例

アドレス帳の機能のある会員登録制のSNSなどのサイトでアドレス帳の検索画面を例にSQLインジェクションの説明をします。
下のアドレス帳の検索画面は、ログイン者(=データベースでは「登録者」)の友達を対象に検索条件に一致するデータを検索結果に表示できます。
この例だとログイン者山田さんが、「友人名」が”田中”という条件で検索した結果が表示されています。

WEBセキュリティの脅威①：SQLインジェクションの例：友達（アドレス帳）検索画面

PHPを例にSQLインジェクションがされていないコードを見てみます。
ユーザの入力した「友人名」の値をそのままSQL文に埋め込んでいます。

WEBセキュリティの脅威①：SQLインジェクション対策がされていないphpのコード

このコードの場合、検索条件の「友人名」に”田中’ OR ‘1’=’1″と入力して検索されるとSQLは「SELECT friend_name, address FROM address_book WHERE owner = ‘山田’ AND friend_name = ‘田中’ OR ‘1’=’1′;」となり、’1’=’1′ は常に真なので、本来見えないはずのデータまで表示されます。

WEBセキュリティの脅威①：SQLインジェクションの例

上の例はデータを不正に取得する内容ですが、これ以外にSQLのINSERT、UPDATE、DELETEを実行してデータを不正に書き換えてしまうことも可能です。

対策①：プレースホルダ

SQLインジェクション対策がされているコードは次のようにプレースホルダを使います。
こうすることで不正な値が入力されても「命令」ではなく「ただの文字列」として扱われます。

SQLインジェクション対策がされているphpコード

対策②：エスケープ処理　※最近は非推奨

エスケープ処理は、’（シングルクォート）や;セミコロンなどの文字をSQLの命令の一部ではなく文字列の意味として変換をします。
例えば、エスケープ処理は、’（シングルクォート）の文字を「\’」 に変換します。

エスケープ処理の例

対策③：データベースアカウントの適切な権限

WEBアプリケーションが利用するデータベースアカウントには適切なアクセス権限を付与することで、不正な閲覧やデータ書き換えを最小限にできます。
基本的にWEBアプリケーションが利用するデータベースアカウントには必要最小限の権限を設定します。

エスケープ処理は以下の理由で推奨されません。
代わりに、プレースホルダの使用が強く推奨されます。

  • エスケープ処理は、データベースの種類（MySQL, PostgreSQL, SQL Serverなど）や文字コードによってエスケープすべき特殊文字が異なるため、完全に網羅するのが困難
  • コードが読みにくくなる
  • エスケープ処理し忘れのリスク

OSコマンドインジェクション

Web画面からOS（WindowsやLinuxなど）に出す命令を、ユーザーが入力した値で書き換えられてしまう攻撃です。
こにより、本来実行するはずの命令とは別に、勝手に別の命令を追加されてしまいます。

発生しうる脅威

・サーバ内ファイルの閲覧、改ざん、削除
・不正なシステム操作

OSコマンドインジェクションの例

画面で指定したファイル名のログファイル内容を表示するWEB画面を例に説明します。

WEBセキュリティの脅威②：OSコマンドインジェクションの例：ログ確認画面

「表示」をクリックした場合のPHPのコードは以下の通りです。
ユーザが入力した値をそのまま連結させてshell_exec() に渡し、OSコマンドとして解釈されます。

WEBセキュリティの脅威②：OSコマンドインジェクション対策がされていないphpコード

このコードの場合、「ログファイル名」に”apl20251230.log; rm -rf /”と入力して「表示」をクリックされると、システム上のほぼすべてのファイルが削除されます。

WEBセキュリティの脅威②：OSコマンドインジェクションの例：不正操作の例

対策：シェルを起動できる言語機能の利用を避ける

OSコマンドインジェクションの対策は、シェルを起動できる言語機能の利用を避ける（OSコマンドを使わない）ことです。

OSコマンドインジェクションのセキュリティー対策がされているphpコード　

クロスサイトスクリプティング(XSS)

XSS（クロスサイトスクリプティング）とは、攻撃者が用意したスクリプトがユーザーのブラウザ上でそのサイトのものとして実行されてしまうことです。

反射型XSS

反射型XSSは、入力した値がそのまま“反射（表示）される”ことで起きるXSSです。

検索サイトを例に説明します。
この検索サイトはキーワードを入力して「検索」をクリックすると、キーワードを表示して検索結果も表示するようになっています。
「検索」をクリックすると、「http://example.com/search?word=XSS」のようにURLのクエリストリングにキーワードを設定しています。

WEBセキュリティの脅威③：反射型XSSの例（検索サイトの例）-通常の使い方をされているシーン

攻撃者はURLのクエリストリングにキーワードにスクリプトを仕込んだメールや偽サイトなどを用意し、利用者にクリックさせると、検索キーワードそのままHTMLとして出力しているため、スクリプトが実行されてしまいます。

WEBセキュリティの脅威③：反射型XSSの例（検索サイトの例）-攻撃された場合のシーン

この例は cookie を画面に表示するだけですが、実際の攻撃では JavaScript を用いて cookie を外部サーバーへ送信し、セッションハイジャックなどにつながる危険があります。

■反射型XSSの対策
　・サーバ側で 出力時エスケープを徹底
　・URLパラメータやPOST値をそのままHTMLに埋め込まない

反射型XSSは、スクリプトはサーバーに保存されず、リクエストに対するレスポンス内でのみ実行されますが、次に説明する蓄積型XSSはスクリプトがサーバに保存されて実行されます。

蓄積型XSS

蓄積型XSSは、悪意のあるスクリプトをWebサイトに保存されてしまい、それを見た人のブラウザで勝手に実行される攻撃です。

ショッピングサイトの口コミ投稿を例に説明します。
このサイトは口コミを投稿できるようになっています。
口コミを入力する欄にスクリプトを入力して投稿すると、以降はこのページに訪れた人を対象にスクリプトが実行されていしまいます。

WEBセキュリティの脅威③：蓄積型XSSの例（ショッピングサイトの口コミ投稿の例）

この例は cookie を画面に表示するだけですが、本当の攻撃の場合は次のようにされます。
　①Cookieを外部サーバに送信
　②セッションIDを盗む
　③勝手な操作をさせる

■累積型XSSの対策
　・表示時のHTMLエスケープが必須
　・DBに悪意あるスクリプトが入る前提で設計
　・Cookieに HttpOnly / Secure

DOM型XSS

DOM型XSSは、JavaScriptの書き方ミスが原因で起きるXSSです。

次のようなテキストボックスに文字を入力して「OK」をクリックすると、下に入力した文字が表示されるだけのシンプルな画面を例に説明します。

WEBセキュリティの脅威③：DOM型XSSの例（サンプル画面の説明）

コードは次のようになっており、テキストボックスに入力した値をinnerHTMLでそのまま出力するようになっています。

WEBセキュリティの脅威③：DOM型XSSのセキュリティー対策がされていないコード例

このコードの場合、テキストボックスにスクリプトが入力されると、そのスクリプトが実行されてしまいます。

WEBセキュリティの脅威③：DOM型XSSの例（スクリプトを入力された場合）

対策としては、innerHTML を使わず textContent を使用することで、HTMLタグとして解釈されず、文字列として表示されます。

WEBセキュリティの脅威③：DOM型XSSのセキュリティー対策がされているコード例

CSRF（クロスサイト・リクエスト・フォージェリ）

CSRF（クロスサイト・リクエスト・フォージェリ）は、ユーザが利用しているサイトにログインしたままの状態を悪用して、意図しない操作をさせる攻撃です。

発生しうる脅威

  • サイトのサービス悪用（ショッピングサイトで意図しない商品の購入、ネットバンクから送金など）
  • 情報の改ざん（ユーザのパスワード変更など）

CSRFの例

ネットバンクのWEBサイトを例に説明します。

①ユーザがネットバンクのWEBサイトへログインします。
　ログインするとユーザのブラウザにはログイン中ということを示すセッション情報がcookieが保存されます。
　この段階ではまだ攻撃は発生していません。

WEBセキュリティの脅威④：CSRF（クロスサイト・リクエスト・フォージェリ）　STEP1

②攻撃者が偽サイトへの誘導をします。この例ではメールを使っています。
　偽サイトにはネットバンクの送金をリクエストするURLへアクセスするように仕掛けられています。

WEBセキュリティの脅威④：CSRF（クロスサイト・リクエスト・フォージェリ）　STEP2

③ユーザが偽サイトを開くと攻撃者へ送金のリクエストを送信し、攻撃者へ送金がされてしまいます。

WEBセキュリティの脅威④：CSRF（クロスサイト・リクエスト・フォージェリ）　STEP3

原因と対策

原因対策
第三者サイトからのリクエストでCookieが送信できてしまう。
（ブラウザのcookieに保持しているセッションを利用）		①CSRFトークン(サーバーが生成する一意で予測不可能な値)を利用する。
　（これが最もポピュラー）
②サーバー側で正当なサイトからのリクエストかどうかを検証する。
　（リクエストのRefererやOriginヘッダーを確認）
③SameSite属性付きCookieの利用
GETメソッドによるリクエストを使用している。
（GETメソッドは、偽のリクエストを生成できてしまう。）		POSTメソッドにする。
※POSTにしただけではCSRF対策として不十分なのでCSRFトークンなど他の対策と併用する。
重要な操作に対するチェック機構が無い重要な操作には再認証を要求する。

まとめ

  • SQLインジェクション
    • 不正なSQLを実行され、データの漏えい・改ざん・削除が発生する
    • 対策としてはプレースホルダの使用が最重要
    • データベースアカウントには最小権限を付与する
  • OSコマンドインジェクション
    • ユーザ入力を通じてOSコマンドを不正実行される危険がある
    • 原則としてOSコマンドを直接実行する実装は避ける
  • XSS（クロスサイトスクリプティング）
    • 悪意あるスクリプトがユーザのブラウザ上で実行される
    • 反射型XSS（入力した値がそのまま“反射（表示）される”ことで起きる）、累積型XSS(webサイトが蓄積しているコンテンツの中に含ませる)、DOM型(JavaScriptに対策がない場合に発生)の3種類がある
    • 出力時のエスケープを徹底することが基本対策
    • DOM操作では innerHTML を避け、textContent を使用する
  • CSRF
    • ログイン状態を悪用して意図しない操作を実行される
    • CSRFトークンの利用が最も一般的で効果的
    • POSTメソッドの利用、SameSite Cookie、再認証の併用が重要

コメント

タイトルとURLをコピーしました