web-dev-qa-db-ja.com

Rails-コードインジェクションとXSSに対する保護

RailsでRuby=）の使用を開始しました。特にコードインジェクションとXSSに関して、Railsで注意すべきセキュリティ上の問題があるかどうか疑問に思っていましたか？

私は知っていますRails入力をサニタイズすることによってそのような攻撃を防ぐことを試みますが、これは間違いないはずがないと思います。

appsecattack-preventionsource-codexssrails
21
Magnus

Rails 3には、デフォルトで有効になっているいくつかの非常に優れた保護機能があり、多くの一般的なセキュリティ問題をキャッチします。

具体的には、出力エンコーディングはXSS攻撃を緩和するのに役立ちます。CSRFトークンは、ここで役立つすべてのフォームでデフォルトで有効になっています。正しく使用する限り、ActiveRecordまたは他のORMがSQLインジェクションの緩和に役立ちます。

入力検証の最前線には、明らかに注意すべき点がいくつかあります。 Railsはデフォルトでは入力検証を行わないため、アプリに入力されたデータが他のWebアプリケーションに転送される場合でも、XSS攻撃が発生するリスクがあります。

とはいえ、Railsはモデルの検証をサポートしています。可能であれば、そこで入力のホワイトリスト検証を行うことをお勧めします。

SQLインジェクションでは、ActiveRecordで生のSQLを使用することも可能です。その場合、SQLインジェクションで通常の問題が発生する可能性があるため、すべての入力のホワイトリスト検証が役立ちます。

そのほかにも注意すべき点がいくつかあります。ベースRailsインストールでは認証/認証が提供されないため、プラグインから取得するか、開発者が作成する必要があります。

Railsアプリが通常生成するRESTfulスタイルのURLの欠点の1つは、通常、攻撃者がURLを変更して認証を破るのは簡単です。たとえば、 http：// mysite/users/1 これは、最初のユーザーを示し、2以上に簡単に変更できます。安全性が低いということではありませんが、攻撃者が認証制御を迂回することを容易にします。

Railsセキュリティには、より多くの情報を読む価値がある、いくつかの優れた情報源があります。

OWASP Railsセキュリティガイドはこちら と本もあります Security on Rails プラグマティックプログラマーによるRails 2.3にはまだ検討すべき多くの良い情報があります（Railsのセキュリティは現在絶版になっていることに注意してください）。

11
Rory McCune

OWASP XSSチートシート は、XSSが発生する可能性があるすべての方法を理解するための優れたリソースです。

  • ルール＃0-許可された場所以外で信頼できないデータを挿入しない
  • ルール＃1-信頼できないデータをHTML要素コンテンツに挿入する前のHTMLエスケープ
  • ルール＃2-信頼できないデータをHTML共通属性に挿入する前の属性エスケープ
  • ルール＃3-信頼できないデータをHTML JavaScriptデータ値に挿入する前のJavaScriptエスケープ
  • ルール＃4-信頼できないデータをHTMLスタイルのプロパティ値に挿入する前のCSSエスケープ
  • ルール5-信頼できないデータをHTML URLパラメータ値に挿入する前のURLエスケープ
  • ルール＃6-HTMLポリシーエンジンを使用して、アウトバウンドの方法でユーザー主導のHTMLを検証またはクリーンアップする
  • ルール＃7-DOMベースのXSSを防ぐ

上記のすべてのルールがRails=によって自動的に処理されるわけではなく、バージョンによって異なります。

Rails 3.x = "プレーンな文字列が<％=％>に渡された場合、Railsは常にそれをエスケープします"
Rails 2.x = h() method（or Cross Site Sniper または 安全なErb ）

ホワイトリストは1日を支配します。2文字の米国の郵便略称が予想される場合は、検証を使用してそれのみを受け入れます。

一般的なセキュリティガイド： http://guides.rubyonrails.org/security.html

11
Tate Hansen