1

概要: PHP でアプリを作成しました。コールセンター向けのリード管理システムです。ここで、私たちのアプリを独自の CRM と統合することで、パートナーが新しいリードをアプリに追加できるようにする必要があります。要するに、アプリ用の API を構築する必要があると思います。

私が考える最も簡単な方法は、単純な HTML 投稿です。これはあまりにも安全ではないと考えられますか? もしそうなら、この種の状況に最適なアプローチは何ですか?

助けてくれてありがとう、

アンドリュー。

4

3 に答える 3

8

API を構築するための探求を通じて、おそらくこれらのいくつかに出くわすでしょう。使用可能で、オープン スタンダードに準拠する API を実際に構築するのに非常に便利な概念を概説します (これにより、サードパーティが既存のコードを適応させて操作することが簡単になります)。 .

API の性質

最初のキーワードは SSL です。使わないなんて絶対に考えないでください。これにより、セキュアな方法で通信を行うことができるセキュア ソケット レイヤーが提供され、その結果、盗聴や MitM 攻撃を想像することが大幅に困難になります。

何があっても、これをスキップしないでください。証明書の費用は年間 60 ドル未満であるため、正確に費用がかかるわけではなく、長期的には大幅に節約できます。

サーバー技術に関しては、必要なものを使用してください。主な要件は、GET、POST、PUT、DELETE の 4 つの一般的な HTTP 動詞を処理できる Web サーバーです。その理由はすぐに説明します。

API 認可

多くの人が「安全な方法があると考えている」ため、これは論争の的となっている分野です。答えは単に真実ではありません。認証のポイントは、クライアントが資格情報を使用して簡単に認証できるようにすることですが、特権を持たないサードパーティがそうするのを防ぐことです。

API キーをフィードに追加するだけでは、最終的に誰かがそれを手に入れることになります。私はこの特定のことを何度も見たので、特に非常に簡単なオプションがあるため、強くお勧めしません.

認証と署名をそれぞれ(A)または(S)とラベル付けして、いくつかのことを説明します。署名は、リクエストの改ざんを防止するために使用される方法です。認証は、あなたが誰であるかを証明します。

HMAC-SHA512 署名 (A) (S)

この手法は、Amazon がすべての S3/AWS API で使用しており、リクエストの署名と認証を行う非常に軽量な方法です。私は個人的にそれが比較的独創的だと思います。

基本的な考え方:

  1. すべての GET および POST フィールドを切り上げます (公開鍵を含む)
  2. アルファベット順に並べ替えます
  3. URLEncode または同等のものを使用してそれらを連結します
  4. 秘密鍵を HMAC の鍵として、データに対して HMAC ハッシュ暗号を実行します。
  5. 4 の結果をリクエストに追加します。

これはシンプルかつ独創的です。保証内容:

  1. 秘密鍵と公開鍵を知らずにリクエストを変更することはできません
  2. リクエストを変更せずにキーを変更することはできません

これにより、1 つの予約済み GET/POST フィールドを犠牲にして、同じ HTTP リクエストを使用して両方の問題を適切にラップできます。Amazon では、リプレイ攻撃を防ぐために、リクエストにタイムスタンプも必要です。きちんとした！

(参照用: HMAC - ALGO = ALGO( (key XOR PAD) concat ALGO(key XOR PAD2) concat message). ALGOは任意のハッシュ暗号にすることができます - SHA256 はその軽量な性質のために推奨されます)

OAuth (A)

おそらく聞いたことがあるでしょう。アイデアは単純です。キーとシークレットが与えられます。これにより、一時トークンをキューに入れることができます。このトークンは、リクエストの実行に使用されます。

これの主な利点は、クライアント側とサーバー側の両方で、それを処理するための多くのライブラリが存在することです。もう 1 つの利点は、OAuth には 2 つの操作モードがあるということです。

主な欠点は、トークンを取得するための 2 つの HTTP 要求です。

（A）を介して秘密鍵を送信するだけ

... リプレイ攻撃につながります。考慮しないでください。

メソッドの混合は可能なものです。たとえば、HMAC サイネージは OAuth と組み合わせると素晴らしいものになります。

API の概念

最近の API エンドポイントは、SOAP (XML-RPC) または REST という 2 つの主要な標準に従っています。見込み客を投稿するためのエンドポイントを構築している場合は、対応する API を構築して見込み客を読み取り、将来のためにそれらを削除することもできます。

したがって、API は次の形式になります。

 /my/endpoint/
  - GET: gets a list of leads
  - POST: creates a new lead
 /my/endpoint/ID/
  - GET: get lead info
  - PUT: modifies lead
  - DELETE: deletes the lead

これにより、API を便利に将来にわたって保証することもできます。

于 2013-05-21T16:27:48.760 に答える
1

HTML 投稿で十分です。それは問題ではありません。転送されるデータが確実にエンコードされるように HTTPS を使用できるとさらによいですが、これは重要ではありません。

この種の API を保護する最も一般的な方法は、ハッシュのエンコードに使用される共有の「シークレット」または「キー」を提供することです。その後、リクエストが信頼できるソースからのものであることを確認できますが、共有キーを秘密にしておくことはユーザー次第です。

たとえば、API のユーザーは次のことを行う必要があります。

// build hash string to be sent with API POST request (use a sensible combination of values)
$string = sprintf('%s.%d.%d.%d', $username, $orderId, $currentTimestamp, $price);

// hash
$encodedString = sha1($string);

// concatenate with shared key
$stringWithKey = sprintf('%s.%s', $encodedString, $sharedKey); // GET KEY FROM SECURE PLACE

// hash again to get hash that will be sent with the POST request
$hash = sha1($stringWithKey);

次に、提供された POST 値から最後に同じロジックを実行し、それらのハッシュがユーザーの共有キーで構築したハッシュと一致することを確認します。

于 2013-05-21T16:15:29.763 に答える