知らないと怖いWebセキュリティと、CPIサーバーのWAF設定方法

公開直後から狙われているWebサイト

自分が管理している・作ったサイトはアクセス数が少ないから大丈夫、ニュースなどを見ても自分には関係無い話だと思っていないでしょうか。
アクセス数が少ないサイトでもWWW公開直後から狙われています。下記データは、CPIスタッフブログのWAF（Web Application Firewall）データです。アクセスの18%はhumans(ユーザー)で、82%がbots(機械)です。

Botとは、すべての Botが悪いわけではありませんが、ほとんどがこのサイトに 脆弱性がないかなどを調べに来ている「攻撃」です。数字が示す通りWWW公開直後から、悪意あるユーザーから脆弱性がないか常に調査されています。そして 脆弱性を放置していると、ある日突然サイトが乗っ取られるかもしれません。下図は、悪意あるユーザーに乗っ取られた後の有名なCMSの画面です。

ある日突然、ご自身のサイトがこのようになっていたら…とても怖いですよね。ちなみに
 CPIスタッフブログは、毎日 CMSのログイン画面に対して辞書攻撃のアタックがきています ^ ^;

私のブログも、そこまでアクセス数が多いわけではありません。ではなぜ狙われるのか？悪意あるユーザーの一般的な手順として、狙ったサイトを攻撃するために、まずは踏み台になるサーバーが必要になります。その踏み台サーバーを得るために、簡単に落とせるサーバーを探しているのです。

このようにWWWに公開されているすべてのサイトは、アクセスが多い少ないに関わらず、公開直後から狙われています。それでは悪意ある攻撃からサイトを守るために、具体的に何をすれば良いのでしょうか。

ポイント：

1. たとえアクセス数の少ないサイトも狙われています。

狙われやすいIDとパスワード

みなさんは“狙われやすい” IDとパスワードが存在することはご存知でしょうか？
普段何気なく付けているIDとパスワードは、とても危険です。下記図は、弊社メールサーバーに対して辞書攻撃を受けている一日分のログです。

(国別ランキング)

一番多くアタックが来ている国は中国でした。一日で約80万件のアタックを受けています。さらに、一番多くアタックを受けているアカウント名を見てみましょう。

（ID別ランキング）

狙われやすいアカウント１位は「test」、２位が「info」でした。何気なくtest、info、admin、demoなどのアカウントに対して、password、p@ssw0rd、test123、demo123などの安易なパスワードを付けていませんか？
これらのIDとパスワードを設定して公開した時点で、遅かれ早かれメールアドレスやCMSなどのシステムが乗っ取られてしまう可能性が高くなってしまいます。

ポイント：

1. 推測されやすいアカウント名、パスワードを付けない。
2. 複数サイトで同じアカウント名、パスワードを付けない。
3. 開発中に使っていたアカウント「test」「demo」などが残っていないか確認する

CMSのアップデートが必要な理由

CMSのアップデートはいつも確認・適用していますでしょうか？　2013年8月に某レンタルサーバー会社に設置されたCMSの脆弱性を狙ったサイト改ざんの被害が一度に8300件出たニュースは、みなさまの記憶にもまだ残っているのではないでしょうか？私も業界に身を置く人間として、とても衝撃を受けた事件でした。

サイト改ざんを狙った攻撃を未然に防ぐ対策として、CMSのアップデートはとても重要です。CMSアップデートを放置したままの状態が続けば続くほど、危険度は増していきます。

では実際に年間を通じて、どれくらいの脆弱制が発見されているのか見てみましょう。

IPA（情報処理推進機構）の調査によると、2014年の一年間だけでもCMS本体で41件、拡張機能ではさらに増えて344件。合計するとカウントされている4つのCMSだけで年間385件の脆弱性が報告されています。（下図参照）

図を見て分かると思いますが、CMSのコアファイルよりも、モジュールやテーマなどの拡張機能のほうが多く脆弱制が報告されています。
弊社サーバーに設置されたCMSも、アップデートを怠ったことにより、被害にあうユーザーも少なくはありません。

必ずCMSのアップデートは行ってください。

ポイント：

• CMSのアップデートは必ず運用フローに組み込んでください。
• CMSのコアファイルはもちろん、モジュールやテーマのアップデートも行ってください。

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

※ 動画での解説があります。( Youtube : 1分11秒〜 )

Webサイトのセキュリティ対策の１つとして最低限行わなくては行けないのが、XSS（クロスサイトスクリプティング）対策です。
その他にもSQL インジェクション対策、CSRF（クロスサイトリクエストフォージェリ）対策が必要です。SQLインジェクション、CSRFは後ほど説明します。

XSS（クロスサイトスクリプティング）とは、Webサイト管理者が意図しない悪意あるスクリプト（JavaScriptなど）が実行されてしまうことです。

これまでのHTML4で構築されたWebサイトの場合であれば、ユーザーの操作（クリックやオンマウスなど）で悪意あるJavaScriptが実行されていました。しかしHTML5普及以降は、下記コードなどを埋め込むことにより、ページが読み込まれたと同時に悪意あるJavaScriptを実行することが可能となりました。

1. <video>
2. 　<source onerror="javascript:alert('On-error')">
3. </video>
4.  
5. <input value="" autofocus onfocus="alert('Auto-Focus')">

『XSS対策方法』

多様化するXSS（クロスサイトスクリプティング）のコードからサイトを守るためには、ユーザーから受け取ったJavaScriptコードの入出力時に、コードを無効化します。具体的にはフロントエンドとサーバーサイドで行うと良いでしょう。

『フロントエンドの場合』

1. var safe_text = document.createTextNode(some_text);

JavaScriptの「createTextNode」メソッドを使い、some_textに代入された値を無効化し、safe_textに代入しています。

『サーバーサイドの場合（php）』

1. $safe_text = htmlspecialchars($some_text, ENT_QUOTES, 'UTF-8');

htmlspecialchars関数を使い、$some_textに代入された値を無効化し、$safe_textに代入しています。

ポイント：

1. XSSは、掲示板やお問い合わせフォームなどの、Webフォームに仕掛けられます。下記のコードを運営するWebフォームに張りつけ、送信してみてください。JavaScriptが実行される場合は脆弱制が存在します。
   
   1. <script>alert('XSSのテスト')</script>
2. 最新のChromeブラウザなどは、XSS対策が標準でONになっています。 Macの場合は、一旦Chromeブラウザを終了し、下記コマンドをコンソール画面より実行ください。
   
   1. open -a Google\ Chrome --args --disable-xss-auditor

   Windowsの場合は、Chromeを起動するためのショートカットにXSS無効のオプションを入れてください。（chrome.exeは環境によってパスが違います）

   1. "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --args --disable-xss-auditor"

SQLインジェクション対策について

動画での解説があります。( Youtube：7分17秒〜)

SQL インジェクションとは、データベース内に保存された情報を引き出したり、削除したり不正にデータベースを操作する攻撃・脆弱性のことです。

『SQLインジェクション対策方法』

CMSなどのフレームワークを使う場合

• CMSやフレームワークが用意している、データベース接続用の関数等を使うこと。

PHPなどのプログラムから接続する場合

• 文字コードを指定する
• 特殊文字をエスケープする
• 受け取ったデータを元にSQL文を生成する場合、変数に対してバインド処理を行う

フレームワークを利用する場合の接続方法は、それぞれの接続方法で接続していただくとして、今回はPHPを使った場合のサンプルプログラムを掲載させていただきます。
 

1. // MySQLサーバーに接続し、$mysqliにオブジェクトを代入
2. $mysqli = new mysqli($host , $user , $password , $db);
3. // 文字コードの指定
4. $mysqli->set_charset('utf8');
5.  
6. // SQL文を作成します。値には??を指定します。
7. $sql = "insert into user(username,age) value(?,?)";
8. // prepareメソッドを呼び出し、SQL文を作成します。
9. $stmt = $mysqli->prepare($sql);
10.  
11. // ??で指定した箇所に、$name、$ageをバインドします。「si」はデータ型で、
12. // s : string 、 i : integer
13. $stmt->bind_param("si",$name,$age);
14. $name =’Masayuki Abe’;
15. $age = 37;
16. //SLQ文を実行
17. $stmt->execute();
18. $mysqli->close();

重要なのは、文字コードを指定すること、データを代入するときは直接SQL分に指定せずに、prepare()メソッドを利用することです。下記コードはSQLインジェクションの脆弱制を含むコードですので書かないでください。

$sql = "insert into user(username,age) value($name,$age)”;

ポイント：

SQLインジェクションの脆弱制は、動的にSQL文をプログラム上で生成する場合に発生する場合があります。
システム開発がこれからの場合、要件定義書に「データのバインド処理」、「文字コードの指定」は必須と一文入れておくと良いかもしれないですね。

すでに開発が終わっている場合は、開発を担当した者に「データのバインド処理」、「文字コードの指定」はしっかりしている？と聞くのも良いかもしれません。

CSRF（クロスサイトリクエストフォージェリー）対策について

CSRF（クロスサイトリクエストフォージェリー）とは、通常操作できない管理画面の操作や、Webフォームの最終送信処理や、ショッピングの最終決済処理などを他サイトからのリクエストを受信し処理してしまいます。

『CSRF対策方法』

動画での解説があります( Youtube：13分20秒〜)

送られてきたデータを元に何か処理を行う場合、正規のユーザーが送信したデータかどうかを調べる必要があります。そのためにはフォームのデータをセッションで送る、正規ユーザーがアクセスした時にトークンを発行し、正規のユーザーかどうかチェックを行うことなどがあります。

※ソースコードレベルの対策として様々な方法があります。こちらで紹介しているのは例です。
 

データ入力フォームなど（PHPの場合）

1. // セッションを開始
2. session_start();
3.  
4. // $mynameと、$ageはエスケープ処理や、文字チェックを行ったものとします。
5. // $mynameと、$ageをセッションに格納します。
6. $_SESSION['myname'] = $myname;
7. $_SESSION['age'] = $age;
8.  
9. // Tokenを生成。Tokenとセッションを合わせることにより更にセキュリティ強度がまします。
10. // 疑似乱数を生成
11. $bytes = openssl_random_pseudo_bytes(16);
12. // 16進数に変換
13. $token = bin2hex($bytes);
14.  
15. // セッションにセット
16. $_SESSION['token'] = $token;

1. <!--hiddenにTokenを付け処理画面に遷移する-->
2. <h1>入力データの確認</h1>
3. <form action="tnk.php" method="post">
4. <input type="hidden" name="token" value="<?php print $token ?>">
5. <input type="submit" value="データ送信">
6. </form>

データを受け処理を行う画面など（PHPの場合）

1. // セッションスタート
2. session_start();
3.  
4. // POSTで受け取ったTokenと、SESSIONで受け取ったTokenを比較する
5. // 一致すれば処理を実行、一致しなければ処理を収支する
6. if($_POST['token'] != $_SESSION['token']){
7. echo 'エラーです';
8. }else{
9. // 処理を実行する
10. }

ポイント：

セッションを使いフォームデータのやり取りをしてください。

WAFについて

XSS対策、SQLインジェクション対策、CSRF対策など、日々進化する攻撃からWebサイトを守るのは骨が折れるものです。
もちろんソースコードレベルで対策を行うことは重要ですが、なかなか対応が追いつかないのも現状です。

そこで今回ご紹介するのがWAF（ウェブアプリケーションンファイアウォール）です。

WAFはWebアプリケーションレベルの脆弱制をついた攻撃からWebサイトを守ります。
下記はCPIのACE01サーバーに標準で搭載されたWAFの動作検証及び、使い方の説明です。

WAFの使い方・除外設定方法

※ 動画でも解説しています。( 動画：20分55秒〜

1. ACE01（ACE01_2015）の場合WAFが標準でONです。
    
2. 攻撃が検知されると、コントロールパネルの「【制作ツール】＞【WAF】」よりログを確認することができます。
   
    
3. WAFの除外設定はWebサーバーに .htaccessを設置し除外設定を行います。
   記述は下記の通りです。

   『特定のシグネチャを指定して除外』
   SiteGuard_User_ExcludeSig
     [ シグネチャ ID|シグネチャ名|urldecode|all|clear ]
   e.g)

   1. -- .htaccess
   2. <IfModule siteguard_module>
   3. SiteGuard_User_ExcludeSig xss-tag-1,xss-tag-filter
   4. </IfModule>

   urldecode：URL デコードエラーによる検出を除外
   all：すべてのシグネチャと URL デコードエラーによる検出を除外
   clear：上位階層設定を解除

    

   『特定ファイルの除外』
   <Files ~ "filename\.php$">
     SiteGuard_User_ExcludeSig
       [ シグネチャ ID|シグネチャ名|urldecode|all|clear ]
   </Files>
   設置した階層以下のfilename.phpが除外されます。
   e.g)

   1. -- .htaccess
   2. <Files ~ "sample\.php$">
   3. SiteGuard_User_ExcludeSig all
   4. </Files>

    

   『クエリを指定した除外』

   1. SiteGuard_User_ExcludeSig_With_ParamName

     [ シグネチャ ID|シグネチャ名|urldecode|all|clear] [パラメータ名 ]
   e.g)

   1. -- .htaccess
   2. SiteGuard_User_ExcludeSig_With_ParamName all xss

   例の「all xss」 は、xssクエリに対して全て（all）を許可しています。

   xssキーに対してシグネチャを指定する場合は、下記の通りです。

   1. -- .htaccess
   2. SiteGuard_User_ExcludeSig_With_ParamName xss-tag-1 xss

    

動的サイトを運用する場合は、WAFの導入をオススメします。

WAFが標準搭載された「Shaerd Plan ACE01に関する詳しい情報」

最後に

今回ご紹介した基本を行うことで、セキュリティリスクを軽減することができます。
さらに最近では、これまで自社運用が難しかったファイアウォールや、WAFが専門の技術者無しでも、簡単に導入できるサービスが登場しています。これら基本対策と組み合わせることにより、セキュリティ対策を強化することができます。この機会に自社の対策を一度見直してみてはいかがでしょうか。

関連記事

CMSのハッキング統計と、CMSのアップデート手順