66

私が取り組んでいるプロジェクトの REST API の構築を開始したところ、RoR を使用して API を構築する最良の方法について少し調査することになりました。デフォルトでは、モデルは世界中に公開されており、URL の末尾に「.xml」を追加して適切なパラメーターを渡すだけで、URL 経由でモデルを呼び出すことができることがすぐにわかりました。

それで、次の質問が来ました。不正な変更を防ぐためにアプリを保護するにはどうすればよいですか? いくつかの調査を行っているときに、それらの使用方法について説明している記事をいくつか見つけましattr_accessibleたattr_protected。これらについて話しているのを見つけた特定の URL は、2007 年 5 月に投稿されたものです (ここ)。

ruby のすべてがそうであるように、それ以来、すべてが進化していると確信しています。私の質問は、これが RoR 内で REST API を保護するための最良の方法であるかということです。

そうでない場合、「新しいプロジェクト」または「既存のプロジェクト」のシナリオで何を提案しますか?

4

4 に答える 4

102

API リクエストの認証にはいくつかのスキームがあり、restful_authentication や act_as_authenticated などのプラグインによって提供される通常の認証とは異なります。最も重要なことは、クライアントがセッションを維持しないため、ログインの概念がないことです。

HTTP 認証

基本 HTTP 認証を使用できます。このために、API クライアントは通常のユーザー名とパスワードを使用し、次のように URL に入力します。

http://myusername:mypass@www.someapp.com/

restful_authentication はそのままでこれをサポートしていると思います。そのため、誰かが API またはブラウザーを介してアプリを使用しているかどうかを無視できます。

ここでの欠点の 1 つは、すべてのリクエストでユーザー名とパスワードを平文で入力するようユーザーに求めていることです。SSL経由で行うことで、これを安全にすることができます。

ただし、これを使用する API を実際に見たことはないと思います。特に現在の認証スキームですぐにサポートされているため、私にはかなり良いアイデアのように思えます。そのため、何が問題なのかわかりません。

API キー

API 認証を有効にするもう 1 つの簡単な方法は、API キーを使用することです。これは基本的に、リモート サービスのユーザー名です。誰かがあなたの API を使用するためにサインアップするとき、あなたは彼らに API キーを渡します。これは、リクエストごとに渡す必要があります。

ここでの欠点の 1 つは、誰かが他の人の API キーを取得した場合、そのユーザーとしてリクエストを行うことができることです。すべての API リクエストを HTTPS (SSL) を使用するようにすることで、このリスクをある程度相殺できると思います。

もう 1 つの欠点は、ユーザーがどこにいても同じ認証資格情報 (API キー) を使用することです。API クライアントへのアクセスを取り消したい場合、唯一のオプションは API キーを変更することです。これにより、他のすべてのクライアントも無効になります。これは、ユーザーが複数の API キーを生成できるようにすることで軽減できます。

API キー + 秘密鍵の署名

非推奨 (一種) - 以下の OAuth を参照

秘密鍵を使用してリクエストに署名する場合は、さらに複雑になります。これは、アマゾン ウェブ サービス (S3、EC2 など) が行うことです。基本的に、ユーザーに 2 つのキーを与えます。API キー (ユーザー名) と秘密キー (パスワード) です。API キーはリクエストごとに送信されますが、シークレット キーは送信されません。代わりに、通常は別のパラメーターを追加して、各リクエストに署名するために使用されます。

IIRC によると、Amazon はすべてのパラメーターをリクエストに取り込み、パラメーター名で並べ替えることでこれを実現します。次に、ユーザーの秘密鍵をハッシュ キーとして使用して、この文字列をハッシュします。この新しい値は、送信前にリクエストに新しいパラメータとして追加されます。アマゾン側でも同じことをしている。すべてのパラメーター (署名を除く) を受け取り、それらを順序付け、秘密鍵を使用してハッシュします。これが署名と一致する場合、要求が正当であることがわかります。

ここでの欠点は複雑さです。このスキームを正しく機能させることは、API 開発者とクライアントの両方にとって苦痛です。うまく動かないクライアント開発者から、サポートの電話や怒りのメールがたくさん来ることを期待してください。

OAuth

キー + シークレットの署名に関する複雑な問題に対処するために、OAuthと呼ばれる標準が登場しました。コアの OAuth はキー + シークレット署名のフレーバーですが、その多くは標準化されており、多くの言語のライブラリに含まれています。

一般に、独自のキー/署名システムを作成するよりも、API プロデューサーとコンシューマーの両方が OAuth を使用する方がはるかに簡単です。

また、OAuth は本質的にアクセスをセグメント化し、API コンシューマーごとに異なるアクセス資格情報を提供します。これにより、ユーザーは、消費する他のアプリケーションに影響を与えることなく、アクセスを選択的に取り消すことができます。

特に Ruby の場合、 OAuthのプロデューサーとコンシューマーの両方にすぐに使用できるサポートを提供するOAuth gemがあります。私はこの gem を使用して API を構築し、OAuth API を使用しましたが、非常に感銘を受けました。アプリケーションに (単純な API キー スキームではなく) OAuth が必要だと思われる場合は、OAuth gem を使用することを簡単に推奨できます。

于 2008-10-30T14:16:41.060 に答える
7

不正な変更を防ぐためにアプリを保護するにはどうすればよいですか?

attr_accessibleattr_protectedどちらも、ActiveRecord モデルで一括割り当てを実行する機能を制御するのに役立ちます。フォーム インジェクション攻撃を防ぐために、間違いなく attr_protected を使用する必要があります。attr_protected の使用を参照してください。さもないとハッキングされます。

また、だれもが Rails アプリのコントローラーにアクセスできないようにするために、何らかのユーザー認証システムが必要になりbefore_filter、コントローラーに を配置して、許可されたユーザーがリクエストを行っていることを確認する必要があります。要求されたコントローラー アクションの実行を許可する前に。

さらに役立つ情報については、Ruby on Rails Security Guide (Rails Documentation Project の一部) を参照してください。

于 2008-10-29T19:28:48.920 に答える
3

Railsアプリケーション用のREST APIも構築しているため、現在、あなたと同様の質問に直面しています。

ユーザーが編集できる属性のみが attr_accessible でマークされていることを確認することをお勧めします。これにより、update_attributes を使用して割り当てることができる属性のホワイト リストが設定されます。

私がしていることは次のようなものです：

   class Model < ActiveRecord::Base  
       attr_accessible nil  
   end

私のモデルはすべてそれを継承しているため、大量に割り当て可能にしたいフィールドに対して attr_accessible を定義する必要があります。個人的には、この動作をデフォルトで有効にする方法があればいいのにと思います (あるかもしれませんが、私は知りません)。

誰かが REST API を使用するだけでなく、通常の形式の投稿を使用してプロパティを一括割り当てできることを知っておいてください。

于 2008-10-29T15:06:42.117 に答える
0

自分で多くのものを構築する手間を省くもう1つのアプローチは、http： //www.3scale.net/のようなものを使用することです。これは、個々の開発者のキー、トークン、クォータなどを処理します。また、分析を行い、開発者ポータルを作成します。

到着時にトラフィックのポリシーに適用されるruby/railsプラグインrubyAPIプラグインがあります。oAuthgemと組み合わせて使用​​できます。アプリの前にニスをドロップし、ニスlib mod： VarnishAPIModuleを使用して使用することもできます。

于 2012-06-03T12:55:04.320 に答える