web creators特別号 |
HTML5・スマートフォン・SNS・Webアプリケーション Webサイト制作最新トレンドの傾向と対策 |
サイト構築&運用 5-04
Webサイトの制作と運営に関わるセキュリティ(後編)
Webサイトの制作・運営にあたってはセキュリティを十分に考慮することが必須だ。Webサイトの脆弱性とユーザーとのコミュニケーション上のリスクの認識と予防・対策を意識して取り組みたい。
制作・文/江口崇(CEO, Dekilog)
Webサイトの脆弱性
Webアプリケーションの設計や実装の不備が原因で、セキュリティ上のリスクが生じることがある。この不備のことを「脆弱性」という。主なものに「SQLインジェクション」「XSS」「CSRF」がある。
Webサービスではデータベースを使って機能を提供したりコンテンツを表示したりする。ここでは、SQLと呼ばれるデータベースへの問い合わせ文を外部からの情報を使って組み立てる。
たとえば「ユーザーIDが1234の人の日記を表示」の場合、ユーザーIDの部分が外部からの情報になる。
SQLインジェクション
「SQLインジェクション」は、この問い合わせ文に外部からの情報を組み込む際のチェック機能が不完全な時に起こる脆弱性だ。外部から渡されるIDの部分を操作することで、意図しないデータを表示したり、データベースの内容を改ざんしたり壊したりするリスクがある。XSS(クロスサイト・スクリプティング)
「XSS(クロスサイト・スクリプティング)」はWebサービスそのものでなく、そのWebサービスを利用しているユーザーに被害が及ぶ可能性のある脆弱性だ。表示しているページにスクリプトを埋め込む(または、第三者によって埋め込まれてしまう)ことにより、情報漏洩のリスクが発生する。具体的には、個人情報登録画面で入力した個人情報が、他のサイトに送られてしまうケースなどが挙げられる。
なお、クロスサイト・スクリプティング(Cross Site Scripting)は、本来であればCSS と略されるが、スタイルシートのCSSと区別するため、XSSと表記される場合が多い。
CSRF(クロスサイト・リクエスト・フォージェリ)
「CSRF(クロスサイト・リクエスト・フォージェリ)」は、Webサービスにログインしている状態で悪意のあるページを開くと、意図しない書き込みなどが行われる脆弱性だ。クッキーを使ってログイン状態が保持されているときに、通常ではそのサイト内で行われる機能、例えば日記の書き込みが、外部のサイトからも行われてしまう。そうするとユーザーが意図しない内容が日記に書き込まれたりする。
これを防ぐためには、送信されたデータ(日記の書き込み内容)がサイト内から送信されたものかどうかを判断できるような仕組みを実装しておくことが必要だ。
Webサービスの脆弱性に対応するために
まず、サービス制作時に脆弱性が入り込まないようにすることが重要だ。システム設計時、実装時にはIPA【01】の「セキュリティチェックリスト」などを使って、もれなく脆弱性を防ぐようにする。また、プログラムの脆弱性を発見・改善方法を提示してくれるツールを使うのもよい。こういったプロセスは開発工程に含めることが望ましい。そして更に重要なことは、被害が起きた時、に備えて準備をしておくことだ。被害をいち早く検知し、問題のある箇所を修正すること、被害がそれ以上広がらないように対処すること、ユーザーに被害が及んだ場合の対応、必要に応じて謝罪や補償を素早く行えるようにしておくことが大切だ【02】。
大切なのは、チームメンバー全員がリスクを把握することである。Webサービスを提供するとき、ユーザーや運営側にどういうリスクがあるか、それらを防ぐにはどうしたら良いか、起きてしまったときはどのように対応するか、の意識と情報を共有しておくことが肝要だ。なおIPAのサイトにあるセキュリティチェックリストの一部を【03】に掲載してあるので参考にして欲しい。
【01】IPA(独立行政法人情報処理推進機構)が提供する
「安全なウェブサイトの作り方(http://www.ipa.go.jp/security/vuln/websecurity.html)」
【02】Webサイトのリスクを正確に認識し、問題が起きたときには対応できるようにプロシージャを整備しておくことが望ましい。
■ ウェブアプリケーションのセキュリティ実装 チェックリスト (1/2)
【03】IPA(独立行政法人情報処理推進機構)のホームページにある「セキュリティ実践チェックリスト」の抜粋。このリストを活用して、漏れのないセキュリティ対策を実施するといいだろう。
※はいずれかの実施項目を行った場合に「対応済」にチェックを入れる。
OS・ミドルウェアのセキュリティ対策
一般的に、WebサービスはLinuxなどのOS、各種サーバーソフトウェアの上に構築される。たとえばWebサーバーソフトウェアのApache、データベースサーバーソフトウェアのPostgreSQLなどがある。これらのソフトウェアでは新たな脆弱性が発見されることがある。日常的にセキュリティ情報をウォッチし、これに対応するためのセキュリティアップデートを行うことが必要だ。ソーシャルメディアリスクとどう向き合うか
ユーザーとのコミュニケーション、ソーシャルメディアの活用はWebサービス運営上の必須項目だ。技術的なことに加えて、ユーザーとのコミュニケーション上のリスクも把握しておきたい。炎上リスク
「炎上」のリスクは、どのサービスにもある。「炎上」とは、サイト内の掲示板やコメント、あるいはFacebookやTwitterなどのソーシャルメディアで、サービスや製品について批判的な書き込みが殺到することをいう。発生の発端は、運営者の不用意な発言だったり、サービスや製品そのものに問題があったりする場合も、もちろんある。だが、全く予期しない方向から飛び火することもある。そのため、炎上の発生を100%防ぐことは難しい。これを防ぐには、普段からユーザーとのコミュニケーションに重きをおくことだ。具体的にはユーザーからのフィードバックに常に気を配り、チーム内でその情報を共有、迅速に対応することが大切になる。炎上の兆候を見逃して影響が大きくなるケースが多いからだ。
また、ユーザーとのコミュニケーションを行う上で明確なガイドラインを決めておくこと、サービス運営のスタンスが正確にユーザーに伝わるように表現することが大切だ。そして何よりもWebサービスの運営ではユーザーを大切にする姿勢が問われる。
炎上への対応
万一炎上が起きたときは、スタンスを貫き、迅速かつ真摯に対応することが重要だ。ネガティブな書き込みを削除したり、ユーザーに対する姿勢を二転三転させたりするような印象を与える行動を取った場合、炎上がさらにエスカレートするケースが多く見られる。Webサービス上では、ユーザーは感情をベースに行動するので、運営サイドがユーザーを尊重しない姿勢を取ったりすると、それはすぐにユーザーに伝わる。
逆に、しっかりと対応すれば、それが評判を高めることもある。2010年2月に起こったUCC上島珈琲のTwitter炎上事件は、その顕著な例と言えるだろう。
キャンペーンに関連する単語を含むツイートにボットを使って過剰にリプライしたため、これをスパムと感じるユーザーが多かった。批判のツイートが多く投稿され「炎上」したが、運営側は数時間のうちにアカウントを停止し謝罪文を公開した。その結果ユーザーからは好意的な反応が寄せられ、事態は収束した。
ソーシャルメディアの時代、サービスや製品・ブランドをユーザーに「提供する」という従来の方法から、「ユーザーとともにつくりあげていく」スタイルに変化している。これにあわせてユーザーと向き合う姿勢を変化させることができた場合、そのサービスはユーザーに受け入れられるものになる【04】。
【04】上島珈琲のTwitter。炎上事件を起こしたが、その後の迅速かつ真摯な対応により、逆に評判が高まった。現在では約1万人のフォロワーがいる人気のアカウントとなっている。
[目次に戻る]
【本記事について】
2012年1月28日発売のweb creators特別号「Webサイト制作最新トレンドの傾向と対策」から、毎週記事をピックアップしてご紹介! HTML5・CSS3によるコーディングから、次々と生まれてくる新しいソーシャルサービス、Webアプリケーション、スマートフォンやタブレット端末への対応など、いまWeb制作で話題になっているトピックを網羅した内容になっています。
※本記事はweb creators特別号『Webサイト制作最新トレンドの傾向と対策』からの転載です。この記事は誌面でも読むことができます。