2017-06-06 14 views
0

私は自分のサイト用に設計したいくつかの粗いWeb APIにアクセスするためにトークンベースの認証を使用しています。ログイン時には、ユーザー名とパスワードがログインAPIに送信され、一意の秘密鍵を持つトークンが生成され、そのキーがデータベースに格納されます。その後の各呼び出しで、トークンは要求とともに送信され、サーバー上で秘密鍵で検証されます。トークンベースの認証システムのトークンを保護する

私はこのAPIサービスを利用してユーザーにフロントエンドを提供するためにウェブアプリケーションを使用しています。 WebアプリケーションはHTML/Bootstrap/JQueryを使用して設計されており、バックエンドはPHPで書かれています。

私は正常に私のアプリをテストし、トークンベースの認証が動作します。しかし、私には一つの懸念があります。私は、ユーザーのIDとトークンはブラウザのアドレスバーにURLエンコーディングを使用して直接表示されることがわかりました。

http://hasconpanel.ckoysolutions.com/hasconpanel.php?inputs={%20%22username%22%20:%20%22Debopam%20Parua%22%20,%20%22uid%22%20:%20%2220170520193421DP%22%20,%20%22token%22%20:%20%22Sa2pHyooWPoI79vfvJzLlw7UO%252B2p5hOpBttkEq7LQ%252BjAGm9XEmxfhLAcnJoLbqrsXCp75%252BG1M7nEUoCgsDVbIQ%253D%253D%22%20,%20%22list_of_devices%22%20:%20[{%22device_code%22:%22b8:27:eb:f1:b3:0f%22,%22device_name%22:%22First-Pi%22}]%20} 

、このアドレスをコピー、またはブラウザが、それをアクセスしようと関係なく、前のセッションを再開するためになされたものであり、彼らはエントリを取得するとしている場合。特に公共のコンピュータセンターの場合、誰かが私のWebアプリケーションに資格情報でアクセスしてブラウザを強制終了する前にログアウトしなくても、トークンシステムは悲惨に失敗するようです。とにかくそれを暗号化するようなトークンを保護するにはありますか?または、ブラウザやブラウザのタブが閉じたときにパラメータを保存しない、または少なくともアドレスバーに表示しないようにアプリを設定する私は毎回の要求で新鮮なトークンを作ることを考えましたが、システムを大幅に遅くするので、私はそれを避けたいと思います。

この問題を解決する方法をご提案ください。

ありがとうございます。

APIシステムは、共有サーバーのメインドメインでホストされている、とアプリがサブドメインでホストされています

編集:システムは現在、どのように機能するかを説明 。メインドメインには、自宅にインストールされたいくつかのラズベリーのピースから呼び出されているいくつかのWebサービスもあります。

これは動作します。ログインはプライマリWebサイトから行われ、ログインに成功すると、ユーザID、トークン、およびユーザの作業デバイスのリストを含むgetコールでWebアプリケーションが呼び出されます。これらの3つのパラメータのいずれも指定せずにアプリケーションページにアクセスしないようにするためのチェックが用意されています。新しい負荷では、ユーザーはドロップダウンメニューからデバイスを選択する選択肢を得ます。現在、これらの作業デバイスのそれぞれは、3つの別々のシステムを実行できます。したがって、デバイスを選択すると、選択されたデバイスが以前の3つのパラメータとともにパラメータとして追加された状態で、アプリケーションにget呼び出しが再び行われます。トークンとUIDがアドレスバーに表示されます。

+0

API呼び出しのポストリクエストを使用することができます。 –

+0

ポストは彼がHTTP –

+0

BTW上で動作している限り彼を守ることはできません。今では無料のSSL証明書を取得することができるので、httpsを使用しない理由はありません。人々が電子メールとパスワードで登録しなければならない場合は、HTTPSが必要です。https://letsencrypt.org/ –

答えて

2

トークンベースの認証は、Web世界では非常に標準的です。詳細はさまざまですが、確かにしようとしていることは狂っていません。ただし、セキュリティ上の懸案事項は有効であり、解決策は多数あります。

  1. HTTPSのみを使用します。これにより、あなたとあなたの間の誰もがあなたのトークンを簡単に読むことができなくなるのを防ぎます。実際には、何に関係なくこれを行う。 HTTPSは最近、セキュリティの目的でデフォルトと見なされるべきです.HTTPは推奨されていません。
  2. URLの代わりに要求のヘッダーにトークンを移動します。 HTTPSを使用している限り、これは実際にはセキュリティの観点からは何も変わりませんが、業界ではかなり標準的です。また、トークンをブラウザの履歴から削除します。

ブラウザのアドレスバーにURLが表示されるのは奇妙です。私は、クライアントサイドのアプリケーションがリクエストをajax経由で行うことを期待しています。つまり、アドレスバーには何も置いてはいけません。このアプリケーションがどのくらい正確に機能しているかをもっと明確にする必要があるかもしれません。あなたのアプリケーションURLのどれもがアドレスバーになくなり、代わりにAJAXリクエストだけで動作するようにリファクタリングする必要があると思われます。

まだ、HTTPSが最も重要な部分です。 DNSルックアップ後のトランザクション全体が安全に送信されるため、man-in-the-middleによってトークンを盗まれることはありません。これは、セキュリティを確保するために必要な最も重要なステップです。 HTTPSを使用しない場合、それを世界にブロードキャストすることもできます。もちろん、クエリパラメータのトークンでURLに非Ajaxリクエストを行う場合、トークンはブラウザのアドレスバーと履歴に表示されます。ここでも、ajaxリクエストのみを使用してヘッダーにCookieを入れないでください。

ajax-onlyリクエストでHTTPSを使用すると、トークンを盗まれる可能性はかなり低くなります。それでも(特にXSS攻撃を介して)起こる可能性があるので、「深い防御」の原則に慣れてください。また、盗まれたトークンを検出して無効にするための手順があります。以下のようなもの:ユーザーならばIPアドレスの変更(これはおそらく望ましくないとする、モバイルユーザーに影響を与えることができます)

  • がトークンを無効場合

    1. は、(ユーザーのために再度ログインする)トークンを無効エージェントの変更(偽装されている可能性もありますが)
    2. サーバー側最大セッション長を適用する
    3. 電子メール/パスワードを変更する場合は、再認証を要求してください。

    これは、私の頭の上のほんの少しの提案です。繰り返しますが、これはかなり標準的な問題ですので、Googleはあなたの友人になります。

  • +0

    こんにちは、 ありがとうございました。 私はシステムの働きを説明するために最善を尽くします。投稿を編集して情報を追加しています。 –

    関連する問題