【Railsセキュリティ検証】no-corsリクエスト、DNSリバインディング、本番環境のSSL

no-cors

先日の続き。

下記のようにnor-corsモードでリクエストすると、クロスオリジンでもブロックされなくなるとのことなので、セキュリティの穴にならないか調べた。

リクエストをno-corsモードで送ると、opaqueレスポンスが返ってくる。中にはデータは入っていないとのことなので、気にしなくてよさそう。

fetch('http://localhost:3001/api/rooms/TIciF1vZjzUfq4dqpHKQ/maps/106.json', {
    method: "GET", 
    mode: "no-cors",
})
.then(data => console.log(data))

参考: Note that mode: "no-cors" only allows a limited set of headers in the request:

参考: fetchのmodeについて - Qiita

ほとんどの場合、opaqueレスポンスは使えないとのこと。

参考: What is an opaque response? by Tamas Piros

DNSリバインディング

IPアドレスは偽装できるので同一オリジンのリクエストに見せかけることができるという話。

DNSリバインディング対策 - Qiita

⇒ ダミーVirtualHostによって防いでいるが、よくわからない

⇒ 確認のcurl

curl -v -H 'Host: evil.example.com' http://$(dig weak.example.jp | grep -v '^;' | grep 'A' | awk '{print $5}')

⇒ ブラウザベース、DNSベースでの防御策があるとのこと。サーバーベースでは、HTTPSを推奨している。これは、やっているので、できることは十分やっているという理解。

本番環境でのSSL

通信中にデータを盗む攻撃から守るために本番環境でSSLを設定する。Herokuデプロイの場合は、サーバー側の設定もよしなにやってくれるらしい。

https://railstutorial.jp/chapters/sign_up?version=5.0#sec-professional_grade_deployment

config/environments/production.rb

**Rails.application.configure do.
  .
  .
  *# Force all access to the app over SSL, use Strict-Transport-Security,
  # and use secure cookies.*  
  config.force_ssl = true
  .
  .
  .
end**