CVE-2013-0155やCVE- 2013-0156などの Rails の脆弱性により、信頼できないソース (XML/YAML パラメーター) から作成された任意のコードをユーザーが実行できる可能性があります。
$SAFE=4 (たとえば) を使用すると、そのような悪用を防ぐことができますか? はいの場合、Rails 開発者はそのようなセキュリティ レベルを使用しますか? いいえの場合、なぜですか?
ありがとう
CVE-2013-0155やCVE- 2013-0156などの Rails の脆弱性により、信頼できないソース (XML/YAML パラメーター) から作成された任意のコードをユーザーが実行できる可能性があります。
$SAFE=4 (たとえば) を使用すると、そのような悪用を防ぐことができますか? はいの場合、Rails 開発者はそのようなセキュリティ レベルを使用しますか? いいえの場合、なぜですか?
ありがとう
基本的に、$ SAFEレベルは、汚染されたデータからアプリケーションを保護することに要約されますが、悪魔は詳細にあります。プログラミングRubyには、さまざまなレベルに対応する章全体があり、時間をかけて読む価値があります。
一般的に言って、平均的なRailsアプリケーションは汚染された入力を招きます。paramsハッシュは定義により汚染されており、ユーザーの操作のほとんどは汚染されたデータに依存しています。入力をサニタイズしたり、フレームワーク機能を使用して大量割り当ての脆弱性を防止したりできることは確かですが、ほとんどの場合、アプリケーションはユーザー提供のデータと対話して本当に役立つ必要があります。
の場合、Railsアプリケーションを有効に実行できる場合とできない場合があります$SAFE = 4
。率直に言って、「野生の」プロダクションコードでそれを行う人を見たことがありません。可能であっても、ユーザーが提供したデータを汚染せず、ActiveRecordオブジェクトをインスタンス化し、ファイルシステムの書き込み(ロギングやファイルのアップロードなど)を実行するために、セキュリティのトレードオフに値しないほど多くのフープを飛び越えなければならない可能性があります。
より低い$SAFEレベルを使用し、目標を達成するために他のセキュリティのベストプラクティスに依存することで、より良いサービスが提供される可能性があります。それは本当にあなたが達成しようとしていることに依存します。すべてのセキュリティ管理と同様に、マイレージは間違いなく異なります。
Rails 全体で $SAFE が 4 に設定されている場合、何も起こりません。このように、あなたのアプリは静的ビューのみを提供することができません。少なくとも、それは少し前の私の経験です。