バックエンドで一般的な Web フレームワーク (rails、sinatra、flask、express.js) を使用する安らかな Web アプリを開発しています。理想的には、Backbone.js を使用してクライアント側を開発したいと考えています。JavaScript クライアント側だけがこれらの API 呼び出しとやり取りできるようにするにはどうすればよいですか? curl
これらの API 呼び出しを公開したり、ブラウザーでリンクを入力したり、単にリンクを入力したりするだけで呼び出されることは望ましくありません。
6 に答える
最初の原則として、API が JS クライアントによって消費される場合、API がパブリックであると想定する必要があります。彼が選んだツール。
とはいえ、私があなたの質問を正しく読んだ場合、これはあなたが避けたいことではありません.あなたが本当に望んでいないのは、JSクライアントが関与せずにAPIが(定期的に)消費されることです. 強制しない場合に、少なくともクライアントの使用を奨励する方法に関するいくつかのアイデアを次に示します。
あなたの API には、ある種の認証フィールド (たとえば、クライアントで計算されたハッシュ) があると確信しています。そうでない場合は、This SO questionをご覧ください。セッションベースでJSクライアントに与えられるソルト(またはAPIキー)を使用するようにしてください(ハードコードされていません)。このようにして、API の許可されていないコンシューマーは、より多くの作業を強いられます。
JS クライアントをロードする際に、いくつかの HTTP ヘッダー (ユーザー エージェントが思い浮かびます) と IP アドレスを覚えておいて、それらが変更された場合は再認証を要求し、通常の容疑者にはブラックリストを使用します。これにより、攻撃者は宿題をより徹底的にやり直さなければならなくなります。
サーバー側では、最後のいくつかの API 呼び出しを覚えておいてください。別の API 呼び出しを許可する前に、ビジネス ロジックが今すぐ新しい呼び出しを許可しているかどうかを確認してください。他の手段と組み合わせることで、これにより虐待者を簡単に検出できるようになります。
必要な明確さでそれを言ったわけではないかもしれません.虐待者があなたのサービスを利用することを完全に不可能にすることは不可能だと思います.
ある種の認証システムを実装する必要があります。これを処理する良い方法の1つは、いくつかの予想されるヘッダー変数を定義することです。たとえば、セッショントークンを返すauth /loginAPI呼び出しを行うことができます。その後のAPIの呼び出しでは、セッショントークンが「your-api-token」のような特定の名前のHTTPヘッダー変数に設定されることが期待されます。
あるいは、多くのシステムは、ある種のapiアカウントシステムを使用して、期待されるアクセストークンまたはキー(youtube、facebook、twitterなど)を作成します。そのような場合、クライアントはこれらを何らかの方法でクライアントに保存する必要があります。
次に、セッションのチェックをRESTフレームワークに追加し、例外をスローするだけです。可能であれば、ステータスコード(安らかな)は401エラーになります。
現在、「JSON Web Token」と呼ばれるオープン スタンダードがあります。
https://jwt.io/ & https://en.wikipedia.org/wiki/JSON_Web_Tokenを参照
JSON Web Token (JWT) は、いくつかのクレームをアサートするトークンを作成するための JSON ベースのオープン スタンダード (RFC 7519) です。たとえば、サーバーは「管理者としてログイン」というクレームを持つトークンを生成し、それをクライアントに提供できます。クライアントはそのトークンを使用して、管理者としてログインしていることを証明できます。トークンはサーバーのキーによって署名されるため、サーバーはトークンが正当であることを確認できます。トークンはコンパクトで、URL セーフであり、特に Web ブラウザーのシングル サインオン (SSO) コンテキストで使用できるように設計されています。通常、JWT クレームは、ID プロバイダーとサービス プロバイダーの間で認証済みユーザーの ID を渡すために使用できます。また、ビジネス プロセスで必要なその他の種類のクレームを渡すこともできます。[1][2] トークンは、認証および暗号化することもできます[3][4]。
すみません@MarkAmeryとEugeneですが、それは正しくありません。
ブラウザーで実行されている js+html (クライアント) アプリは、次のように API への不正な直接呼び出しを除外するように設定できます。
- 最初のステップ: 認証を要求するように API をセットアップします。クライアントは、最初にサーバー (または他のセキュリティ サーバー) を介して自身を認証する必要があります。たとえば、人間のユーザーに正しいパスワードを提供するように要求します。
認証前は、API への呼び出しは受け入れられません。
認証中に「トークン」が返されます。
認証後は、認証「トークン」を使用した API 呼び出しのみが受け入れられます。
もちろん、この段階では、パスワードを持っている許可されたユーザーのみが API にアクセスできますが、アプリをデバッグするプログラマーである場合は、テスト目的で直接アクセスできます。
- 2 番目のステップ: 次に、追加のセキュリティ API を設定します。この API は、クライアントの js+html アプリがサーバーから最初に要求された後、短い制限時間内に呼び出されます。この「コールバック」は、クライアントが正常にダウンロードされたことをサーバーに伝えます。クライアントが最近正常に要求された場合にのみ、REST API 呼び出しが機能するように制限します。
API を使用するには、まずクライアントをダウンロードし、実際にブラウザで実行する必要があります。コールバックを正常に受信し、短い時間内にユーザーが入力した後でのみ、API は呼び出しを受け入れます。
したがって、資格情報を持たない無許可のユーザーである可能性があることを心配する必要はありません。
(質問のタイトル、「REST API 呼び出しを保護するにはどうすればよいですか」、そしてあなたの発言のほとんどから、それはあなたの主な関心事であり、あなたの API がどのように呼び出されるかという文字通りの質問ではなく、誰によって、正しいですか? )