1. Home
  2. Security
  3. WEBアプリケーションのセキュリティ対策と攻撃まとめ～最低限行っておくべき対策とは～

WEBアプリケーションのセキュリティ対策と攻撃まとめ～最低限行っておくべき対策とは～

  • 公開日
  • カテゴリ：Security
  • タグ：PHP,Apache,Security,WEB,nginx
WEBアプリケーションのセキュリティ対策と攻撃まとめ～最低限行っておくべき対策とは～

WEB サービスを公開するという事はその瞬間から、外部からの攻撃にも備える必要がある事を意味します。

自分のサービスにはどんな機能があり、それによってどんな脅威があるのか。それを考え、セキュリティ対策をとっていく事は、WEB サービスを運営する者としての責務です。

今回は、WEB アプリケーションに考えうる脅威と、その対策についてをまとめていきます。

Contents

  1. WEB のセキュリティ対策
  2. SQL インジェクション
    1. 攻撃例
    2. 被害想定
    3. 対策
  3. XSS（クロスサイトスクリプティング）
    1. 攻撃例
    2. 被害想定
    3. 対策
  4. CSRF（クロスサイトリクエストフォージェリ）
    1. 攻撃例
    2. 被害想定
    3. 対策
  5. クリックジャッキング
    1. 攻撃例
    2. 被害想定
    3. 対策
  6. ディレクトリトラバーサル
    1. 攻撃例
    2. 被害想定
    3. 対策

WEB のセキュリティ対策

セキュリティ対策という言葉は良く耳にしますが、具体的にどんな事に気を付け、対策を行っていけば良いのでしょうか。

そして、何故、セキュリティを気にしなければいけないのでしょうか。

WEB というのは誰にでも開かれた世界です。その WEB アプリケーションがどこで作られたとしても、公開すればその瞬間から、世界中どこからでもアクセスする事が出来ます。それまでは考えられなかったタッチポイントを私たちは今、手元のパソコンやスマホだけでいとも簡単に手に入れられる時代になりました。

しかしながら WEB もまたテクノロジーの集合体であり、誰にでも気軽にサービスを公開できる分、リテラシー、技術力、そして計画不足などから、誰でもアプリケーションのセキュリティホール（脆弱性）を生んでしまう場合がある事も事実です。

WEB の世界も日々進化しており、悪意のある攻撃者の攻撃手法も日に日に巧妙化してきています。もしも自分の WEB サービスが攻撃を受け、サーバ障害によるサービスの停止や個人情報の漏洩などの被害を被った場合に、最も損をするのは自分自身と、そのサービスに参加してくれたユーザ達です。

良かれと思って公開したサービスで悪しきが得をし、良しが損をするなんて、こんな悲しい結末はありません。

このページは定期的に更新し、情報の追加や更新を行っていきます。これから WEB サービスを作って公開してみたいと思っている初心者の方から、アタックとその対策を確認したい人まで、少しでもその対策施策の発見に役立っていただけると幸いです。

SQL インジェクション

SQL インジェクションは、データベースへの問い合わせ処理を利用して不正な操作を行う攻撃手法です。

送信されたクエリに不正なコードを仕込む事で、データベースへ問い合わせを行う SQL 文が意図しない挙動を起こし攻撃が成立します。

攻撃例

例１：投稿フォーム

投稿フォームに不正なコードを入力し送信する事で、送信されたデータから SQL 文を組み立てる際に攻撃者の意図する挙動を誘発させ、攻撃が成立する。

例２： GET パラメータ

URL からパラメータを取り、それらをデータベースへの問い合わせに使用するアプリケーションの場合、URL パラメータに不正なコードを仕込む事で、取得したパラメータから SQL 文を組み立てる際に攻撃者の意図する挙動を誘発させ、攻撃が成立する。

被害想定

上記のような攻撃が成立する事によって想定される被害は以下の通りです。

データの漏洩

資産であるデータや個人情報が攻撃者に盗まれる。

データの改ざん

データベース内のデータが意味の無いものや不快な内容に改ざんされる、もしくは削除される事で、サービスの継続が困難になる。

対策

SQL インジェクションを防ぐには、送信されたデータから SQL 文を組み立てる前にそれらを十分に評価し、且つ、セーフティな方法でデータベースへ問い合わせを行う事です。

  • エスケープ処理を行う。
  • プリペアドステートメントを用いる。
  • データベースユーザの権限を必要最小限にする。

また、万が一に備えてデータベース内のデータの持ち方にも気を配ります。

  • 必要以上に個人情報や重要な情報を公開 DB に置かない。
  • パスワードはハッシュ化する。

XSS（クロスサイトスクリプティング）

XSS(cross site scripting = クロスサイトスクリプティング) は、動的な WEB ページを利用して悪意のあるコードを埋め込む事で、第三者のアクセス時に不正な操作が実行される攻撃手法です。

前述した SQL インジェクションとは性質こそ違いますが、入口は近いものがあります。 XSS の場合、その多くがスクリプトの埋め込みによって攻撃が成立します。

不正なコードを仕込まれる事によって、第三者がアクセスした際にそのコードが実行され、不特定多数のユーザに被害をもたらします。

攻撃例

例１：投稿フォーム

掲示板などの、投稿フォームからの投稿が第三者の目に触れるようなサイトの場合、投稿フォームから不正なコードを投稿する事によりそのコードが埋め込まれ、別の不特定多数がそのページへアクセスした際にそのスクリプトが実行されてしまう事で攻撃が成立します。

例２：インラインの JavaScript や CSS

HTML タグに直接記述されているイベントハンドラや、script タグ内のコメント、CSS もインラインに記述する場合は、コメント、バックスラッシュの利用、数値文字の参照などでスクリプトを仕込む事が可能であり、XSS が成立します。

被害想定

上記のような攻撃が成立する事によって想定される被害は以下の通りです。

cookie（クッキー）の漏洩

WEB アプリケーションの中には、クッキーを利用して重要な情報を格納（パスワードなど。cookie に格納してはいけません）しているものがあり、これらを攻撃者に取得されてしまうとなりすましなどの被害のきっかけとなります。また、セッション ID なども、それだけで認証を行っているサイトがあれば、アカウントを乗っ取られてしまう場合もあります。

ページの改ざん

入力フォームで XSS が成立した場合、フォームの送信先を攻撃者の任意の送信先へ変更（改ざん）されてしまう場合があります。そうすると、別のユーザが入力したアカウント情報、個人情報やクレジットカード情報が攻撃者の用意した送信先（サイト）へ送信されてしまい、情報が漏洩してしまいます。

対策

入力値を厳密に審査する

例えば、あるフォームには数値が入ってくるべきである場合は、数値のみを許容するようにする。文字列なら、記号に関して無害化（サニタイズ/サニタイジング）を行う。１つずつの入力フォームに対して、厳密に入力を受け付ける値を限定していく事が大切です。

エスケープ処理を行う

スクリプトの埋め込みには記号と半角英数字が使われますが、記号はエスケープ処理を行う事でスクリプトの実行を防げます。 「<」は「&lt;」にしたり、「&」は「&amp;」にしたりなど、いわゆる文字参照（実体参照）に変換してしまう事で、攻撃者のコードを無力化する事が出来ます。

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

CSRF(cross-site request forgeries = クロスサイトリクエストフォージェリ) は、リクエスト強要やセッションライディングとも呼ばれます。ユーザやブラウザを騙し、ユーザの意図しない場所へユーザのクライアントからリクエストを送信させる攻撃手法です。

攻撃例

その多くは、攻撃者が用意したサイトへ何らかの方法で導かれたユーザがアクセスした時点で特定のサイトへの攻撃を行わせるものになります。

またその際に、ユーザにはほとんど自覚症状がない事が多く、いつのまにか攻撃に加担していたという事も珍しくありません。

被害想定

攻撃への加担

XSRF が成立した場合、ユーザは自身の知らない（体感の無い、目には見えない）ところでユーザ自身のクライアントから特定のサイトへ攻撃のリクエストが行われます。その結果、ユーザの意図しないところで大量のリクエストが送られたり、または不正なコードを含んだ投稿を行わされたりなどが、ユーザ自身のクライアントから実行されます。結果、攻撃者は自身を隠蔽した上で他人に他人を攻撃させる事が成立します。

意図しないユーザ操作

例えばユーザが SNS などログインの必要なサイトへアクセスしようとしてその時に XSRF が成立すると、ユーザ認証が行われた状態で攻撃者の指示した通りの操作が行われてしまいます。

この場合、XSRF が成立する流れとしては以下のようなものになります。（一例です）

  1. ある SNS のログイン画面が実は罠サイトのページだった
  2. そこで ID とパスワードを入力する
  3. 攻撃者の指示する操作を受け取り本家のログイン画面に移行、そのままログイン（ログイン ID とパスワードが奪取されます）
  4. 本家 SNS 内で攻撃者が指示した操作が実行される。

攻撃者の指示する操作とは様々なものがありますが、例えば自分の SNS で意図しない投稿が行われたり、非公開のものを公開にされたり、金融機関サイトなら不正に送金が行われてしまったりもします。

対策

XSRF の場合、始まりが運営者側のサイトからでない事も多く、大切な事は、こういった手法、もしくはそれを疑われるような、通常ではないリクエストについての対策を行う事が重要です。

一時トークンの導入

いわゆる CSRF トークンといわれる仕組みで、リクエスト発効前に一時トークンを発行し、リクエストが投げられた時点でクライアント側とサーバ側でトークンの審査を行い、適合しないものは受け付けないという流れを構築する事で、CSRF を防ぐ事ができます。

もし第三者が CSRF によって外部から運営者のサイトへ何らかのリクエスト、もしくは操作を行おうとしても、CSRF トークンによってその実行をサーバ側でブロックする事が出来ます。

昨今の PHP フレームワークで提供されている CSRF トークンやGoogle ReCaptcha などはトークンでの CSRF 対策に分類されます。

承認機能の導入

公開されている投稿フォームと、投稿内容の表示が行われている場合、運営者はそこからの投稿をリアルタイムに表示しない、いわゆるコメント承認機能のようなものを一枚挟むだけでも、攻撃的な投稿があった場合にもそれらが公開状態とならないのである程度は防げます。

根本的な解決にはなりませんが、それでも運営側でまず止められればユーザ側に被害が広がる事を防げます。

ただしこの場合、送信されたデータを確認する際には十分に注意が必要です。送られたコードが実行されない形で表示させ確認を行わないと、結局は確認の際に攻撃コードが実行されてしまいます。

クリックジャッキング

クリックジャッキング（Clickjacking）攻撃は、サイトページ上に目視出来ないリンクなどを設置し、ユーザにそのリンクを押下させる事で、遷移先サイトで攻撃者の指示した操作が行われてしまう攻撃手法です。

攻撃例

攻撃者が用意したページに iframe で攻撃対象のサイトを読み込み表示させ、その上（ログインボタンなどやリンク）から透明な別のリンクを設置する事でユーザがそれを押下すると、あたかも正当なページ遷移を実現するが、同時に悪意のある操作を実行させる事が可能となります。

被害想定

個人情報の漏洩

スパムメールから罠サイトへ誘導され、そのままログインを行った事で、ログイン後で自身のアカウントの個人情報を搾取されてしまう。

不正操作・不正送金

上記と同じような手法でクリックジャッキングが成立する事で、ネットバンクでの不正送金や、アカウントの不正操作が行われてしまう。

対策

一番の対策は、攻撃者が iframe を使って自身のサイトを表示されないように運営者が対策を行う事です。

罠サイトに表示できなければ、少なくとも iframe を使ってクリックジャッキングを仕掛ける事は出来なくなります。

具体的には、HTTP レスポンスヘッダに X-Frame-Options ヘッダを設定し、含める事です。

これで、iframe による表示を制御（許可/禁止）する事が出来ます。

X-Frame-Options ヘッダの設定は、以下で行う事が出来ます。

  • サーバ側
    • Apache や nginx などの Web サーバの設定ファイル
  • アプリケーション側
    • PHP や Java 側での設定
  • .htaccess
    • サーバーサイドの知識が無くても、.htaccess ファイルにて設定が可能です。

※ HTML の meta タグでは設定できません。

設定値

  • DENY
    • 全て禁止。例外は認めない。
  • SAMEORIGIN
    • 同じドメイン内なら許可。他は禁止。
  • ALLOW-FROM [URI]
    • 指定ドメインのみ許可。他は禁止。 WEB サーバでの設定例
# Apache（.htaccess も同じ）
Header always append X-Frame-Options DENY
Header always append X-Frame-Options SAMEORIGIN
Header always append X-Frame-Options ALLOW-FROM http://web.security.com

# nginx
add_header X-Frame-Options DENY;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Frame-Options "ALLOW-FROM http://web.security.com";
PHP での設定例
<?php
header('X-FRAME-OPTIONS: DENY');
header('X-FRAME-OPTIONS: SAMEORIGIN');
header('X-FRAME-OPTIONS: ALLOW-FROM http://web.security.com');

ディレクトリトラバーサル

ディレクトリトラバーサル(directory traversal) は、「../../」などパスを遡る記法を利用してリクエストを送り、攻撃者の意図する階層とファイルへのアクセスが行われてしまう攻撃手法です。

攻撃例

クッキーを利用したサイトにて、利用するクッキーに不正な値を仕込む事で、攻撃者の意図するファイルを不正に入手されてしまいます。

SNS などでファイル選択ができるフォームにおいて、攻撃者はそこへファイルパス文字列を含むファイル名のついたファイルを入力する事で、最終的に攻撃者の狙ったファイルまでのパスとそれを取得する為の動作を成立させます。

被害想定

オープンソースなど、デフォルトのディレクトリ構成が容易にわかりうるものに対してよく攻撃が行われ、ディレクトリトラバーサルを成立させると重要なデータやファイルを奪取されてしまいます。 Wordpress の wp-config.php やフレームワークの設定情報などは、データベース情報に直結する為、そこから個人情報の漏洩も起こり得ます。

対策

  • ファイルパスが成立してしまうようなファイル名の受け取り、操作を許可しない。（渡されたものが URL エンコードされているとチェックを通ってしまう為、その場合の値もチェックする）
  • 外部からのパラメータを受け取り、そこからファイル名を直接指定するような実装は行わない。
  • ファイル、ディレクトリの権限を厳密に定義する。

Author

rito

  • Backend Engineer
  • Tokyo, Japan
  • PHP 5 技術者認定上級試験　認定者
  • 統計検定 3 級