安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料

上記は3章構成になっていてそれぞれ長めの内容なので、ここでは2章の『ウェブサイトの安全性向上のための取り組み』の Web サーバの運用に関する対策や、Web サイトにおけるパスワードの取り扱いに対する対策などをについてまとめます。

Web サーバに関する対策

対策	説明
OS やソフトウェアの脆弱性情報を継続的に入手し、脆弱性への対処を行う	脆弱性は日々発見されるので脆弱性情報（NVD、CVE、セキュリティメーリングリスト、セキュリティブログ等）を継続入手し、ソフトウェア更新や問題の回避を行う
Web サーバをリモート操作する際の認証方法として、パスワード認証以外の方法を検討する	パスワード認証のみだと総当たり攻撃等で突破される可能性があるので、公開鍵認証等を利用する
パスワード認証を利用する場合、十分に複雑な文字列を設定する	推測させないために左記を遵守
不要なサービスやアカウントを停止または削除する	不要なサービスが動いているとその管理が十分でなく、脆弱性を見逃す可能性あり。また不要なアカウントでも不正利用につながる可能性あり。不要なものは停止または削除しておく
公開していないファイルを Web 公開用のディレクトリ以下に置かない	公開用ディレクトリに保管されているファイル群は外部から閲覧可能。公開を想定しないファイルは公開用ディレクトリに置かない。

DNS に関する対策

対策	説明
ドメイン名およびその DNS サーバの登録情報を調査し、必要に応じて対処を行う	Web サイトが利用するドメイン名や DNS サーバにおいて、問題のある運用や設定をしているとドメイン名の乗っ取りにつながる可能性がある。登録状況を確認し、セキュリティ向上のための対処を行う（ドメインレジストラへの連絡、セキュリティ確認、脆弱性の特定、法的措置等）
DNS ソフトウェアの更新や設定を見直す	DNS を狙った攻撃に、キャッシュポイズニング攻撃、リフレクタ攻撃、水責め攻撃がある。DNS ソフトウェアの設定不備や古いバージョンが原因となる。設定見直しやソフトウェア更新等を定期的に行う

DNS を狙った攻撃についての補足：

キャッシュポイズニング攻撃

DNS キャッシュに誤った情報を送り込む攻撃。キャッシュサーバがドメイン名と IP アドレスの対応を誤って記録するように試みる。これにより正当な Web サイトへの代わりに悪意ある Web サイトへリダイレクトされる可能性がある
リフレクタ攻撃

DDoS 攻撃の一種で、リフレクタサーバと呼ばれる中継サーバを介して行う攻撃。攻撃者は小さなリクエストをリフレクタサーバに送り、リフレクタサーバはそれを攻撃対象に送る（例：送信元 IP アドレスを偽装した DNS リクエスト）。リフレクタサーバにて、リクエストを増幅させることもある。これにより攻撃対象の帯域幅を過剰に使用し、サービス中断や遅延を引き起こさせる。

リフレクタサーバは、通常無害な Web サーバや DNS サーバを経由して行われるため、攻撃者の IP アドレスを隠すことができる。
水責め攻撃

DDoS 攻撃の一種で、大量の DNS クエリをターゲットの DNS サーバに送る攻撃。DNS サーバを過負荷にし、正当なトラフィックへのアクセスを遮断する。通常は合法的なもので、増幅や中継サーバを使用しない。攻撃者は多数のゾンビポット（感染したコンピュータ）を使用してトラフィックを増幅させ、DNS を過負荷にする。

ネットワーク盗聴への対策

通信を暗号化していない場合、盗聴によって情報が悪用され、なりすまし等につながる可能性がある。盗聴自体は Web サイトと利用者との経路上で行われるため防ぐのは難しいが、通信を暗号化することで盗聴されても重要情報の不正利用を防止できる。

対策	説明
重要な情報を取り扱う Web ページでは通信経路を暗号化する	暗号化通信のプロトコルである TLS を用いた HTTPS 通信を利用する。すべてのページが https:// となるようにするために Web サーバがブラウザに対して HTTPS 通信を行うように指示する HSTS(Strict-Transport-Security) 機能を導入する。
利用者へ通知する情報は、メールで送らず、暗号化された https:// ページに表示する	メール等で重要情報を送信する場合、メール本文を暗号化することが推奨されるが利用者側に暗号化環境(S/MINE, PGP 等)やプライベートキー等が必要になり現実的ではない。よって、重要情報をネットワークを通して送信する場合、HTTPS 通信を利用したページに表示することが推奨
Web サイト運営者がメールで受け取る重要情報を暗号化する	運営については自身で管理できるので、S/MIME, PGP 等を利用しメールを暗号化して重要情報を取得する。

Rails での HSTS 機能の有効化

HSTS 機能を有効化するには、config/environments/production.rb に下記を設定するだけ。(config.force_ssl)

  config.force_ssl = true

新規に Web サイトを構築する場合は上記で良いが、HTTP で運用されていたものを HTTPS 対応する際には泥臭くやっていく必要がありそう。

また、cookie 情報を暗号化する設定になっているかも確認する。(Cookie へのアクセス制限)

Rails ではデフォルトで cookie を暗号化しているとのこと（セッションストレージ）

フィッシング詐欺を助長しないための対策

フィッシング詐欺は、利用者を誘導し巧妙に作成した偽の Web サイトを本物の Web サイトと勘違いさせ、入力された認証情報や個人情報を入手するもの。

フィッシング詐欺を助長しないためには、本物かどうかを利用者が判断しやすいように下記の点に注意する。

対策	説明
EV SSL 証明書を取得し、サイトの運営者が誰であるかを証明する	サーバの運営者が誰であるかを示すのに有効。ただし、本当に安全かどうかはユーザが最終的に判断する必要がある
フレームを利用する場合、こフレームの URL を外部パラメータから生成しないようにする	`frame` 要素を利用する場合は、子フレームの URL が任意の URL にならないようにする
利用者がログイン後にリダイレクト機能で動的に実装しているサイトについて、リダイレクト先は自サイトのドメインのみ許可する	利用者の警戒はログイン時のみで、ログイン後は安心してしまうことが多い。そこでリダイレクトされると警戒心が弱まっているため、重要情報を入力してしまう可能性がある。リダイレクトは自サイトのみとし、許可リスト方式のガードを変ける。

SSL 電子証明書の種類

サーバの電子証明書には、認証レベルの低い順から DV*1, OV*2, EV*3がある。費用も認証レベルに応じて変わり、DV は無料〜数万、OV は数万、EV は数万〜十数万となっている。

ちょっと前までは EV であればブラウザのアドレスバーは緑色になったが今は廃止されているらしい。理由は、EV は所在が実在し金さえ払えば取得できるものであり、本当に安全かどうかは保証されない。

その際に、緑色にて視覚的に安全とユーザに誤解させ、必要な警戒を解く可能性があるため廃止の運びとなったらしい。

https 通信で EV 証明書を示す緑のバーが廃止された理由について調べてみた。 - t-hom’s diary

パスワードに関する対策

Web サイトにおける認証では、ユーザ ID とパスワードを用いるのが一般的だが、取り扱い方法に問題があると、利用者の認証情報は不正取得される可能性がある。不正取得の手段の一つに『推測』があり、Web サイト運用時には、推測のヒントを与えないように注意する。

対策	説明
初期パスワードは推測困難な文字列で発行	暗号論的擬似乱数生成器を用いて、規則性のないものを設定する
パスワードの変更には現行のパスワード入力を求める	-
入力時の応答メッセージが認証情報の推測のヒントとならないようにする	認証失敗に『パスワードが違います』といった具体的に失敗した部分を表示させない。
入力フィールドは、パスワードを伏せ字で表示されるようにする	-
パスワードをサーバ内で保管する場合は、平文ではなくソルト付ハッシュ値で保管	パスワードをハッシュ付きとすることで、SQL インジェクション等で Web サイト内で保管したパスワードが漏洩しても、不正ログインに悪用されにくくする。

ソルト付きハッシュ値とは？

ハッシュ関数は、同じ入力に対しては常に同じハッシュ値を返すため、レインボーテーブル攻撃*4や辞書攻撃*5の課題がある。

ソルト付きハッシュのソルトはどこに保存するのが一般的か

そこで、ハッシュ関数にランダムなデータである『ソルト』を追加し、ハッシュ値を計算する。ソルトはユーザ毎に異なるランダムな文字列で、『パスワード＋ソルト』を組み合わせてハッシュ値を計算する。

パスワードとソルトは別々に管理し、ハッシュ生成後、ハッシュ値と関連するソルトをデータベースにて管理する。認証時は保存されたソルトを取り出して、ユーザ入力のパスワードとソルトを組み合わせたものにて認証を行う。