nginx/Railsのセキュリティ対策で今まで行なってきたことのメモです。
nginx
Webサーバのバージョン情報をレスポンスに表示させない
理由
バージョン情報が漏洩することで、既知の脆弱性を狙った攻撃を受けるリスクが高まる
また今後新たな脆弱性が見つかった時に攻撃対象となる可能性がある
対応方法
Nginxのバージョン情報を表示させないようにするにはnginx.confのhttpディレクティブにserver_tokens off;を追加します。
http {
server_tokens off;
...
参考：Nginx導入時やること
ちなみにnginxを使っていること自体を隠す場合には拡張モジュールが必要となるようです。
[Nginx] レスポンスヘッダを限りなく消す
Nginxでレスポンスヘッダの一部を隠蔽する方法
レスポンスヘッダにX-XSS-Protectionを付与する
理由
クロスサイトスクリプティングの脆弱性により、罠ページにアクセスした利用者のブラウザ上で任意のスクリプトが実行される可能性がある。
対応方法
nginxのconfファイルにX-XSS-Protectionヘッダーを追加する。
add_header X-XSS-Protection "1; mode=block";
レスポンスヘッダにContent-Security-Policyを付与する
理由
クロスサイトスクリプティングなどの脆弱性につながる可能性がある。
対応方法
nginxのconfファイルにContent-Security-Policyヘッダーを追加する。
add_header Content-Security-Policy "default-src 'self'";
レスポンスヘッダにStrict-Transport-Securityを付与する
理由
リダイレクト攻撃など、なんらかの理由でHTTPS通信がHTTP通信に変更されてしまった場合、特にクライアント側で通信路の安全性が確認できなくなる。
対応方法
nginxのconfファイルにStrict-Transport-Securityヘッダーを追加する。
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
SSLの暗号方式を見直す
理由
強度の低い暗号方式をサポートすると、通信の盗聴や改ざんなどが行われる可能性がある。
対応方法
参考：httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？
あくまで例ですが以下のような設定にしています。
server {
~
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!EXPORT:!DES:!3DES:!MD5:!DSS:!ADH:!AECDH;
参考サイトの設定に加えて認証機能を提供していないCipher Suite（ADH-AES128-SHAなど）を除外するように修正しています(中間者攻撃を防ぐため)
レスポンスヘッダにX-Download-Optionsを付与する
理由
X-Download-Optionsを指定していないとIEでファイル保存のダイアログに「開く」ボタンが表示される。
ブラウザ上で直接ファイルを開くことでURLに対応するドメイン上のリソースとしてブラウザ内で表示される可能性がある。
この機能を悪用してクロスサイトスクリプティングを実行することで、個人情報の漏えいの被害につながる危険性が存在する。
対応方法
nginxのconfファイルにX-Download-Optionsヘッダーを追加し値に"noopen"を指定する。
add_header X-Download-Options "noopen";
Rails
publicディレクトリに.svnを残したままにしない
理由
Subversionのentriesファイルからバージョン管理情報が漏えいし、攻撃のヒントを与える可能性がある。
対応内容
デプロイ時に.svnを削除するように自動化しておきます。
リクエストパラメータでファイルパスを渡すAPIを作成しない
理由
パストラバーサルの脆弱性によりWebサーバの権限で任意のファイルの情報が取得できてしまう。
その結果、機密情報が漏えいする可能性がある。
対応内容
IDなどファイルパスに変わる情報をパラメータとして指定するようにします。
HTTPSで通信されるSet-Cookieにsecure属性を付与する
理由
HTTPS通信で付与されたcookieの内容がHTTP通信で送信されると、cookieの内容が漏えいする可能性がある
対応方法
config/initializers/session_store.rb の session_storeの部分でsecureオプションを付与します
Rails.application.config.session_store ..., secure: Rails.env.production?
セッション情報をCookieではなくデータベースに持たせる
理由
Cookie情報が漏洩するとアカウント乗っ取りなどによる攻撃を受ける可能性が高くなる
対応方法
activerecord-session_storeを使います。
参考：Rails4でsession storeをActiveRecordに変更
HostヘッダやRefererのチェック処理を入れる
理由
HostヘッダやRefererを改ざんした場合、レスポンスのLocationヘッダに指定した文字列が出力される。
罠ページの閲覧やメール添付URLの閲覧などを行った際に、偽ページにリダイレクトされる可能性がある。
参考：Host:リクエストヘッダによるXSS
対応方法
Railsのbefore_actionでHostヘッダやRefererのドメインチェックを行ないます。
※これがベストな方法かはわからないです。
cache-controlヘッダの設定を変更しキャッシュ保存を行なわないようにする
理由
デフォルトのprivate指定ではプロキシなどにレスポンスがキャッシュされる可能性がある。
対応方法
Railsのコントローラに以下を追加
prepend_before_action :set_headers
def set_headers
response.headers['Cache-Control'] = 'no-store'
response.headers['Pragma'] = 'no-cache'
end
※nginxのconfファイルに追加する方法だとprivate指定の設定が残ってしまう。