Rails でのセキュリティ問題の防止

セキュリティは、Web アプリケーションの成功と持続可能な開発を目指す開発者にとって大きな懸念事項です。すべての開発者は、アプリケーションがあらゆる攻撃から可能な限り安全になるようなコードを作成したいと考えていますが、100% にバグがない、または安全なコードは存在しません。したがって、開発者は、攻撃に対する脆弱性を最小限に抑えたアプリケーションを作成するために最善を尽くす必要があることを認識しています。脆弱性の検出は簡単ですが、セキュリティ侵害やハッキングにより損失が生じる可能性があります。これが、アプリケーション開発プロセスの開始直後からセキュリティ上の問題をチェックし、順調に進めるために定期的な品質チェックを実施することが常に良い理由です。

1]セッション

セキュリティの評価を始めるには、特定の攻撃に対して脆弱になる可能性があるセッションから始めるのが良いでしょう。

session[:user_id] = @current_user.id User.find(session[:user_id])

– デフォルトでは、Ruby on Rails は Cookie ベースのセッション ストアを使用します。これは、何かが変更されない限り、サーバー上でセッションが期限切れにならないことを意味します。つまり、パスワードや ID などの機密データをセッション内に決して保持すべきではないということになります。
– したがって、ベストプラクティスはデータベースベースのセッションを使用することです。Rails を使用すると非常に簡単です –

プロジェクト::Application.config.session_store :active_record_store
セッション ID は、32 文字のランダムな 16 進文字列です。

セッション ID は、OpenSSL、/dev/urandom、Win32 などのプラットフォーム固有のメソッドを使用して、暗号的に安全な乱数を生成するランダムな 16 進文字列を生成する SecureRandom.hex を使用して生成されます。現時点では、Rails のセッション ID のログイン資格情報に対してブルートフォース攻撃、つまり試行錯誤攻撃を行うことはできません。

一般的なセッションベースの攻撃のいくつかを次に示します。
セッション ハイジャック:- これにより、攻撃者はユーザーのセッション ID を盗み、被害者の名前で Web アプリケーションを使用することができます。
セッションの固定:- 攻撃者は、ユーザーのセッション ID を盗むだけでなく、既知のセッション ID を固定することもできます。これはセッション固定と呼ばれます。
セッションの有効期限:- 攻撃者は、期限切れのないセッションを使用して攻撃の時間を延長しようとします。クロスサイト リクエスト フォージェリ (CSRF)、セッション ハイジャック、セッション固定などの攻撃がその例です。

2]コマンドインジェクション

攻撃者がコマンド ライン パラメータまたは Unix コマンド全体に影響を与えることができる場合、アプリケーションはコマンド インジェクションに対して脆弱になります。ただし、Rails で UNIX コマンドを実行することは一般的ではないため、このような攻撃が発生する可能性は低くなります。
一方、顧客データに対して Unix コマンドを直接使用するバックグラウンド プロセスで脆弱性が発生する可能性があります。

一般的な Rails コマンド ライン メソッドのいくつかを次に示します。
%x[…]
システム（）
実行()
`…`
コマンドを連鎖させる方法は複数ありますが、それはホスティング オペレーティング システムにも依存することにも注意してください。例: 「&」、「&&」、「|」、「||」等
コマンドの実行中に環境変数を保護する
Rails アプリケーションによって実行されるプロセスは、API キーなどで構成される親プロセスの環境変数を取得します。

3] SQLインジェクション

SQL インジェクションは、SQL クエリ内で安全に使用されない値をユーザーが操作できる場合に発生します。これにより、データ損失、データ漏洩、特権の昇格などの望ましくない結果が発生する可能性があります。

SQL インジェクションは非常に簡単で一般的な攻撃であり、Web サイトや発生状況によっては、その影響が非常に深刻になる可能性があります。

開発者として、SQL インジェクションが発生する可能性のあるすべての可能性に注意し、それに応じて同様に処理する必要があります。

SQL インジェクションは次のようになります。

Employee.all(:conditions => "指定 = #{params[:指定]}")

上記のコードは SQL インジェクションに対して脆弱ですが、次のコードは SQL インジェクションを防ぎます。

Employee.all(:conditions => ['指定 = ?', params[:指定]])

または

Employee.all(:conditions => {:designation => params[:designation]})

RailsにおけるSQLインジェクション対策

SQL インジェクションのすべてのステートメントをテストするのは退屈な作業になる可能性がありますが、Brakeman のような静的コード スキャナーなどの対策を講じる必要があり、いくつかの単体テスト ケースを作成できます。
a) 一般規則:– このように文字列変化 (#{}) で params を使用しないでください。
例えば

User.where("name = '#{params[:name]}'")

b)params が配列である場合もあることに注意してください。次に例を示します。

?user[]=1 を URL に追加した場合は、params[:user]。ユーザーは存在しますか?次に、params[:user] はクエリ SELECT 1 AS one FROM “users” WHERE (1) LIMIT 1 を実行します。

4] クロスサイトスクリプティング (XSS)

XSS を利用すると、攻撃者は Web アプリケーションのセキュリティ コンテキストでスクリプトを実行できるようになります。

Rails ビュー スニペット <%= @ flat.title %> を考えてみましょう。フラットのタイトルが HTML の追加とともに編集された場合、この Rails ビューはアプリケーションのセキュリティ コンテキストでその HTML をレンダリングします。したがって、ブラウザは HTML (XSS) を実行します。

実際、これは最近の Rails ではまだ機能しません。Rails バージョン 2 では、ユーザー入力をすべてエスケープする必要があります: <%= h(@ flat.title) %>
最近では、Rails には各文字列に、安全かどうかを HTML としてマークするフラグ (@ flat.title.html_safe?) が付属しています。安全でない場合 (たとえば、パラメータ、データベースなど)、次の方法で使用しているときに自動的にエスケープされます: <%= @ flat.title %>
Rails 3.0 では、XSS に対する保護がデフォルトの動作です。

対策

a) コンテンツ セキュリティ ポリシー (CSP) 戦略

コンテンツのセキュリティ ポリシー は基本的に HTTP ヘッダーの形式であり、これにより、あらゆる種類のアセットに対してすべてのソースが許可されることに関するルールが宣言されます。これらのルールに従った結果、それ以外のルールはすべて禁止されます。適切に実装すると、アプリ内のすべてのクロスサイト スクリプティング (XSS) 脆弱性を一掃できます。

b) HTML セーフ、ActiveSupport::SafeBuffer

ActiveSupport::SafeBuffer モジュールは、文字列に HTML セーフ フラグを追加するために Rails 3 によって導入されました。デフォルトでは、特に文字列にデータベースやパラメータなどの外部ソースがある場合は false になります。フラグは「string」.html_safe?で返されます。

HTML エスケープ メソッド h() は、文字列を HTML セーフとしてマークする文字列をエスケープします。

h("html>").html_safe? #=> true ("html>").html_safe? #=>false

c) OWASP (Open Web Application Security Project) XSS 防止

XSS を防止するには、信頼できないデータをすべて拒否し、HTML やその他のコンテキスト (JavaScript、CSS、属性コンテキストなど) に直接入れられないよう制限する必要があります。

d) HAML テンプレットでの XSS 保護

ERB ではなく Haml テンプレートを使用すると、文字列は ERB テンプレートと同じ方法で自動的にエスケープされます。また、ERB テンプレートの場合と同様に、HTML セーフ文字列 (string.html_safe? は true を返す) は自動的にスキップされません。 Haml の != 表記は、ERB で <%= raw(…) %> が動作するように動作するため、エスケープされていないバージョンがレンダリングされます。
デフォルトでは、

="強調" != "強調"

コンパイルすると次のようになります:

強調された

そのため、Haml で != を使用するときは注意が必要で、ユーザー データがエスケープされずにレンダリングされないようにする必要があります。
以下は、Rails アプリケーションの開発中に対処できるいくつかの予防策です。

1]認証

Device または Authlogic gem を使用します。
– 認証を有効にするには、-> を追加することを忘れないでください。

クラス ProjectController < ApplicationController
before_filter :authenticate_user
– デフォルトでは、Devise はパスワードに 6 文字のみを必要とします。最小値は /config/initializers/devise.rb で変更できます。
config.password_length = 8..128
– ユーザー モデルに次のコードを追加することで、パスワードの複雑さを変更できます。

validate :password_complexity defpassword_complexity ifpassword.present?ではなく、password.match(/\A(?=.*[az])(?=.*[AZ])(?=.*\d).+\z/)errors.add :password, "を含める必要があります少なくとも 1 つの小文字、1 つの大文字、および 1 つの数字" end end

2] 安全でないオブジェクトの直接参照または強制的なブラウジング

– Ruby on Rails アプリは、Restful URL 構造を利用しており、使用されるパスのほとんどが推測可能かつ直感的になっています。したがって、ユーザーが別のユーザーに属するデータにアクセスしたり変更しようとしたりしないようにするには、アクションを特別に制御する必要があります。バニラの Rails アプリケーションには、すぐに使えるこのような組み込みの保護機能はありません。さらに、コントローラーレベルで手動で実行することもできます。
– アクセス制御にcancancanまたはpanditを使用する

3] 質量の割り当てと強力なパラメータ

- class Project < ActiveRecord::Base attr_accessible :name, :admin end

上記の例によれば、アクセス可能な admin 属性を使用すると、次のことが機能します。
–curl -d “project[name]=triage&project[admin]=1” host:port/projects
– config.active_record.whitelist_attributes = true

4] リダイレクトと転送

– パラメータを使用するリダイレクトの使用は避けることをお勧めします。
例:- //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– 制限的な保護では、:only_path を使用します。

begin if path = URI.parse(params[:url]).path redirect_to path endrescue URI::InvalidURIError redirect_to '/' end

– 承認されたサイトのハッシュを保持し、それらのみがリダイレクトされることを許可します。

5] 動的レンダーパス

– 何らかの条件に基づいてビューを動的にレンダリングする場合は注意が必要です。管理ビューが読み込まれる可能性があります。

6] クロスオリジンリソース共有

– ファイルのアップロードなど。
– 受信サイトは、ホワイトリストに登録されたドメインのみを制限および許可し、リクエストもそれらのドメインのみから送信されるようにする必要があります。
– OPTIONS リクエストに対する応答と POST リクエストの両方に Access-Control-Allow-Origin ヘッダーも設定します。これは、リモート サイトまたは受信サイトが要求元のドメインを許可するかどうかを判断するために、OPTIONS 要求が最初に送信されるためです。
– POST リクエストが送信されます。もう一度言いますが、トランザクションが成功したと表示されるためには、ヘッダーを設定する必要があります。

7] ビジネスロジックのバグ

– アプリケーションは、ベースとなっているテクノロジーに関係なく、セキュリティ バグにつながる可能性のあるビジネス ロジック エラーを含む可能性があります。自動ツールを使用してこのようなセキュリティ バグを検出するのは非常に難しい場合があります。コードの定期的なレビュー、ペア プログラミング、単体テストの作成などの実践は、このようなセキュリティ バグの発生を最大限に回避するのに役立ちます。

8] 機密ファイル

以下は、Web アプリケーションの開発中に注意する必要があるいくつかのファイルです。
/config/database.yml - 運用認証情報が含まれる場合があります。
/config/initializers/secret_token.rb – セッション Cookie をハッシュするために使用されるシークレットが含まれます。
/db/seeds.rb – ブートストラップ管理者ユーザーを含むシード データが含まれる場合があります。
/db/development.sqlite3 – 実際のデータが含まれる場合があります。

9]暗号化

Ruby on Rails は OS 暗号化を使用します。暗号化用の独自のソリューションを作成することはほとんどないはずです。
Rails を更新し、依存関係を更新するプロセスを用意する。

Rails アプリケーションのセキュリティ問題を検出するツール

• ブレーキマン
• バンドラー監査
• コードセイク::ドーン
• ラック::攻撃
• タランチュラ
• ハキリツールベルト