web-dev-qa-db-ja.com

サードパーティのWebサイトに埋め込まれたWebウィジェットからAPIへのリクエストを保護する方法

バックグラウンド

パスワード保護されたCMSに埋め込むための新しいSaaS=のWebウィジェットを設計しています。これにより、CMSのすべてのページに次のようなものを追加して、私の情報SaaSシステム：

<script src="https://www.awesome-saas.com/widget.js?userToken=xyz" id="widget"/>

ユーザーが顧客のWebサイトに登録すると、私の顧客は私のAPIを呼び出して、my SaaS system。の新しいユーザーのUUIDを取得します。これはユーザートークンです。顧客のCMSで使用される一意のIDはAPI呼び出しで渡されません。顧客のCMSは、ユーザーの一意のIDとシステムが提供するトークン間の関連付けを保存します。個人情報はシステムに保存されません（名前、DoB、クレジットカードの詳細などはありません）。このトークン生成アプローチシステムに保存されているデータの匿名性を保証し、プラットフォームのデータ常駐コンプライアンスを保証します。

CMSはユーザートークンをJavaScriptウィジェットに提供し、ウィジェットはユーザーのトークンを渡してAPIにリクエストを送信し、ページにレンダリングするJSONスニペットを取得します。

https://www.awesome-saas.com/getInfo?userToken=xyz

返されるJSONスニペットには、個人情報は含まれていません。

CMS、ユーザーのブラウザー、および私のAPI間のすべての通信は、SSLを介して行われます。 CMSと私のSaaSシステム間でのユーザーセッションの共有はありません。

問題

顧客が私のサービスをCMSと簡単に統合できるようにしながら、JavaScriptウィジェットからのAPIへのリクエストをどのように保護できますか？

私が検討したいくつかのオプション：

オプション1

UUIDトークンを私のSaaS APIに渡すだけで十分です。推測するのは非常に難しく、誰かがそれをどうにかして成功したとしても、取得したデータが誰に関連しているかはわかりません。

長所

  • 統合を容易にする
  • aPIへの応答は簡単にキャッシュできます

短所

  • 顧客、監査人、規制当局への販売が難しい場合がある
  • それは間違っていると感じているあいまいさによるセキュリティです

攻撃ベクトル

  • 侵害されたブラウザの履歴はユーザートークンを明らかにします
  • 力ずくの推測は幸運になるかもしれない

オプション2

顧客のCMSに、生成されたすべてのトークンを暗号化してもらい、公開鍵を私たちと共有してもらいます。暗号化されたトークンは私のAPIに渡され、顧客の公開鍵を使用してそれを復号化します。

長所

  • トークンがブルートフォーサーではなく顧客のCMSから発信されたものであることを確認します
  • 野蛮なフォーサーは今、信じられないほど難しい数字の暗号化されたバージョンを試して推測する必要があります

短所

  • トークンの暗号化を毎回チェックする必要があるため、APIへのリクエストをキャッシュできません
  • お客様が私と統合するためのより多くの作業、つまりコードの変更

攻撃ベクトル

  • 侵害されたブラウザの履歴により、暗号化されたユーザートークンが明らかになる
authenticationweb-service
8
AndrewKelly

トークンが期限切れにならない場合、攻撃者はトークンを取得して使用し、無期限にサイトにアクセスできます。有効期限の切れていないトークンは、まだ有効なトークンを使用している多数の攻撃者と共有できます。

ただし、有効期限のないトークンには統合の問題があります。基本的に、顧客サイトは現在有効なトークンを取得し、必要に応じてトークンを更新するために、SaaSと通信する必要があります。

OAuth 2タイプのアプローチを検討してください。あなたのOAuth 2サーバーは、トークン（有効期限が切れます）を顧客のWebサイトに配布します。SaaSがトークンを受信すると、SaaSはOAuth 2サーバーに対してトークンを検証します。顧客がOAuth 2統合、それだけで十分かもしれません。

2
Edward Barnard