昨今、様々なサービスがWeb上で公開されており、ユーザの利便性が非常に向上しています。
しかし、その一方でWebシステムの脆弱性も多く発見され、その脆弱性を突いた攻撃により個人情報の流出などが多発しています。
本稿ではそうしたWebシステムの脆弱性とその対策について記載します。
Webサイトを公開している事業者の方、あるいは日々Webサイトを使用してユーザにお買い物などをさせている方などは、ぜひご一読ください。
目次
Webシステムのセキュリティ対策について
ECサイトなどのWebシステムを構築した場合、各種セキュリティ対策を施して情報の漏洩などが起こらないように配慮しているかと思います。
しかし、セキュリティ対策は常に悪意のある第三者とのいたちごっことなるため、以前問題がなかったとしても現在も問題がないとは言えないのが実情です。
実際に情報漏洩などが起こってしまってからでは後の祭りですので、構築時はもちろんのこと、常日頃から最新の対策を確認・実施しておくことが重要になってきます。
HTTPSへの対応
HTTPSとはHTTPの通信を暗号化する仕組みで、具体的にはWebブラウザからWebサーバへの通信経路を暗号化します。
個人情報を入力するフォームやECサイトなどで会員ログインが必要なサイト、あるいは、決済を行う画面でクレジットカード情報や商品の送付先住所などを入力する必要のあるサイトの場合、HTTPSを導入しておくべきです。
また、暗号化してセキュリティが向上する以外にも、Googleでは検索結果の順位にHTTPSに対応しているサイトかどうかも考慮しているので、検索結果で上位に入ってくる可能性も期待できます。
セッションへの攻撃と対策
セッションとは、Webサイトにアクセスして行う一連の行動のことを指します。
各ユーザがどういった行動を取っているのかによって、Webサイト側の処理も変わってくるため、Webシステムはセッションという単位でユーザの行動を管理しています。
ここではそのセッションの脆弱性を突いた攻撃とその対策を記載します。
〇セッションハイジャック
他人のセッションIDを推測あるいは盗聴して取得し、そのセッションを乗っ取ってしまう手法です。
セッションIDの桁数が短く簡単に推測できる場合、あるいはURLの一部にセッションIDが表示されていて、それを盗聴されてしまった場合などが考えられます。
セッションハイジャックへの対策としては、
- セッションIDは推測できないような長くて複雑なものにする
- URLなどのように一目に付くところにはセッションIDを表示しない
などが挙げられます。
〇セッション固定攻撃
他人が使用したセッションを盗むのではなく、悪意のある第三者が自身で用意したセッションIDを使用させて、他人になりすますという手法を、セッション固定攻撃と言います。
セッションIDが長い間変わらないWebシステムの場合、なりすましを許してしまうことがあります。
セッション固定攻撃への対策としては、
- ログイン処理を行った際にセッションIDを再発行する
- URLにセッションIDの情報表示しない、あるいはセッションIDをURLから取得しない
などが挙げられます。
〇クリックジャッキング
ユーザの視覚を欺いて、意図しないコンテンツをクリックさせてリクエストを投げさせる手法です。
iframeというhtmlのタグの1種を用いてユーザの視覚を欺くことが多いので、iframeの呼び出し設定が適切にされていれば防ぐことができます。
ユーザには見えないため、どう防げばよいのかと思われるかもしれませんが、iframeを呼び出す際の設定で、iframeの呼び出しに制限を掛けることができ、ほとんどのWebブラウザがその設定に対応していますので、Webサイト側で適切な設定をすれば未然に防ぐことは可能です。
なお上記設定で、iframeを完全に使用できなくしてしまう方法もありますが、ソーシャルサイトのプラグイン（Facebookのいいね！ボタンやTwitterのツイートボタンなど）をiframeで呼び出して表示しているケースの場合、そういったものがすべて表示されなくなってしまう弊害があります。
ですので、サイトの構成に合わせた適切な設定をしてください。
認証への攻撃と対策
ECサイトなどでは、会員登録してログインした上で決済を行うというのが一般的な流れとなります。
ログイン時にはIDとパスワードを用いた認証処理がありますが、ここではその認証処理への攻撃と対策を記載します。
〇ID・パスワードへの攻撃
ID・パスワードを狙った代表的な攻撃手法として、次の３つがあります。
- 総当たり攻撃
- 逆総当たり攻撃
- 辞書攻撃
いずれの攻撃方法もパスワードの複雑化や、一定回数ログインに失敗したらアカウントをロックしてユーザに通知する仕組みを施してあれば、防げる攻撃ですので、認証処理の設計時にはぜひその点を検討していただきたいと思います。
また、普段を異なるデバイスやIPからのアクセスの場合には、IDとパスワードの認証以外に、秘密の質問などを答えさせる機構を用意しておけば、より安全が担保されます。
〇クロスサイト・リクエスト・フォージェリ
クロスサイト・リクエスト・フォージェリ（以下CSRF）とは、リクエストを偽装することで、あたかも通常のユーザからの操作のように見せかけて、ユーザの不利益になるような処理を行う手法です。
このように非常に危険度の高いCSRFですが、きちんと対策すれば防ぐことはできます。
・トークンを発行してユーザのログインしたWebブラウザか確認する方法
・パスワード変更や商品購入といった重要なアクションの際には再認証を行う方法
入出力処理への攻撃と対策
Webサイトへ用意されている検索欄やコメント欄など、ユーザ側で自由に入力できる項目が非常に多くあります。
自由入力が故に、悪意を持った値を入力することで、Webシステムへ攻撃することも容易です。
ここではそんな入出力処理における攻撃の手法と対策を記載します。
〇SQLインジェクション
SQLインジェクションとは、Webシステムではまず必ず持っているデータベースへの攻撃です。
通常、入力された値を基に検索やデータの更新などが行われますが、不正な値を入力することで、データベース側で予期しない結果を実行させ、その結果ユーザ情報の流出やデータの改ざんといった行為が行われてしまいます。
SQLインジェクションへの対策としては、ユーザの入力した値をそのままデータベースに渡して実行するのではなく、記号やデータベース操作に影響を与える文字列を事前にエスケープ処理してしまう、あるいはプレースホルダ方式と呼ばれるデータベースの操作方式を使用することで防ぐことが可能です。
〇クロスサイトスクリプティング
クロスサイトスクリプティング（以下XSS）とは、Webブラウザ上で不正な動作をするスクリプト（JavaScript）を注入する攻撃手法です。
XSSは下記の3つに分けることができます。
・反射型XSS
不正なJavaScriptを含むURLをユーザに送りつけて、そのJavaScriptをそのまま実行させる手法です。
・蓄積型XSS
不正なJavaScriptを含む値をWebサイトの商品レビューやコメントに残しておくことで、その値を見たユーザにそのJavaScriptを実行させる手法です。
・DOM Based XSS
流れ的には反射型XSSと似ていますが、DOM Based XSSはWebシステム側のJavaScript処理の不備を突いた攻撃となっています。
XSSへの対策としては、適切なHTMLエンコーディングを行うことです。
例えば&や<などの記号をエンコードして、&であれば&、<であれば<と適切にエンコードすることで、不正なJavaScriptの実行を防ぐことができます。
まとめ
Webサイトのセキュリティについて簡単にまとめてみましたが、運営するサイトあるいは、普段訪れるサイトで似たような経験がありましたでしょうか？
本稿で記載したものはほんの一例となっており、実際はもっと複雑な手法あるいは異なる手法もはびこっています。
最初に記載したとおり、セキュリティ対策は悪質なユーザとのいたちごっことなりますので、Webサイトを構築する際には適切な対策を施す、あるいは施すことのできるパートナーと共に構築されることを強くお勧めします。
