安全なウェブサイトの作り方 安全性向上 要約

ウェブサーバ

OS やソフトウェアの脆弱性情報を継続的に入手し、脆弱性への対処を行う

ウェブサーバをリモート操作する際の認証方法として、パスワード認証以外の方法を検討する

総当りこうげきとうにで突破されるおそれがある。 暗号技術に基づいた公開鍵認証にすべき。

パスワード認証を利用する場合は、十分に複雑な文字列を設定する

不要なサービスやアカウントを停止または削除する

不要なサービスは管理が十分でないので、 脆弱性が存在するバージョンを使用している可能性がある 不要なアカウントも管理が充分でないので不正利用される可能性がある。

公開を想定していないファイルを、ウェブ公開用のディレクトリ以下に置かない

DNS

ドメイン名およびその DNS サーバの登録状況を調査し、必要に応じて対処を行う

ドメイン名の乗っ取りを行われた場合、利用者が本物のウェブサイトの URL を指定しても、 そのドメイン名を乗っ取った人が用意したウェブサイトに接続してしまう。 登録状況を定期的に確認し、必要に応じて対処する。

DNS ソフトウェアの更新や設定を見直す

設定不備や古いバージョンが原因となって DNSキャッシュポイズニングを受けたり、 DNSリフレクション、水責め攻撃の踏み台になる可能性が高くなる。

ネットワーク盗聴

重要な情報を取り扱うウェブページでは、通信経路を暗号化する

暗号化したい情報を入力させるページは、送信先(formのPOST先など)をHTTPSにするだけでなく 入力させるページそのものもHTTPSにしなければならない。 なぜなら、入力ページが改ざんされたとき、HTTPSならブラウザに警告画面が表示されるが、 HTTPはページに電子署名が行われていないので表示されない。 よって、送信先が改ざんされると機密情報が攻撃者に渡る可能性がある。

入力ページがHTTPSであるという確認を利用者が怠る場合に備え、 ウェブサーバのレスポンスヘッダに「Strict-Transport-Security」を出力する。 そうすると、一度そのサイトを訪れた利用者のブラウザは、 それ以降そのサイトにはhttps:// でしか接続しないようになる。

フィッシング詐欺

EV SSL 証明書を取得し、サイトの運営者が誰であるかを証明する

フレームを利用する場合、子フレームの URL を外部パラメータから生成しないように実装する

リダイレクト先の URLには自サイトのドメインのみを許可する

ログインに成功したあとのリダイレクト先を、動的に クエリ文字列やhiddenパラメータで決定するウェブサイトがあるとする。 たとえば、利用者がログイン画面だけ正規のサイトであることを確認しても、 遷移後のページがログインページと見た目が同じで、 「ログインに失敗。再入力」というメッセージが表示されていたとき、 利用者は大きな疑いを抱かずに偽サイトに認証情報を入力するかもしれない。

リダイレクト先のURLとなるパラメータに自ドメインのみ許可していれば、 この攻撃を防ぐことができる。

パスワード

初期パスワードは、推測が困難な文字列で発行する

英数字や記号を含めた長い文字列で発行する。 もしも規則性があったら、調査のためのテストユーザを複数登録され、 その際に発行されたパスワードから規則性を導き出されるかもしれない。 利用者によっては初期パスワードを変更せずにそのまま使い続けるかもしれないので、 推測されやすいものは避けるべき。

パスワードの変更には、現行パスワードの入力を求める

入力後の応答メッセージが認証情報の推測のヒントとならない工夫をする

ユーザIDもしくはパスワードが違います、というように曖昧にする

入力フィールドでは、パスワードは伏せ字で表示されるようにする

パスワードをサーバ内で保管する際は、平文ではなくソルト付きハッシュ値の形で保管する

単にハッシュ化だけだと、レインボーテーブル攻撃に弱い。

ユーザごとにソルトを用意しなかった場合も、攻撃者が予め登録しておいた 弱いパスワードのユーザと一致するハッシュを探すことでパスワードを推測できる。

しかし、ユーザごとにソルトを用意しても弱いパスワードは 時間をかければ復元できるので、あえて計算の遅いハッシュ関数を使う技法がある、 それを実現する方法の一つにハッシュ化を繰り返し行う「ストレッチング」がある。

 

WAFによるウェブアプリケーションの保護

WAFにおけるフォールスポジティブ

例: HTMLの特殊文字である「\<」を検出パターンとして定義したら、 単なる数式もWAFによって遮断されてしまった。

WAFにおけるフォールスネガティブ

例: クエリ文字列やメッセージボディ、Cookieに同じ名前のパラメータがあったとき、 WAFは後のパラメータのみ検査するようになっていたが、 ウェブサーバは同じ名前のパラメータを結合するようになっていたとき、 WAFの検査をすり抜けてしまう。 これはHTTPパラメータ汚染と呼ばれている。 RFCが明確に定義していない部分において、 各ソフトウェアによって解釈、動作の差異が生じて起こる。

これらの2つを減らすには

WAF導入時に攻撃を検出しても監視するだけで通信を遮断しないテスト期間を設ける。 この期間で攻撃が正しく遮断されるか、正規の通信が遮断されないかという確認を行う。