HTTPヘッダーを介してアクセストークンを送信しても安全ですか？

これは最初のRESTful Webサービスであり、セキュリティの問題が心配です。アクセストークンをHTTPヘッダー経由で送信しても安全ですか？例えば：

POST /v1/i/resource HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e
Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8

parameter1=foo&parameter2=bar

を介して行われた接続SSL。また、scopeすべての属性として定義する必要があるものaccess token

— ahmedsaber111
ソース

回答:

HTTPを介してアクセストークンヘッダーを送信すると、中間者攻撃に対して脆弱になります。

HTTPSを介してアクセストークンヘッダーを送信すると、リクエストは安全な接続を介してトンネリングされるため、クライアント以外の誰もこのトークンを見ることができません。

— CodeART
ソース

ずさんなクライアントは、SSLを使用してもMITM攻撃に対して脆弱である可能性があります。

— ott-- 2013

例を挙げていただけますか？

— CodeART 2013

クライアントを制御しない場合、クライアント側のセキュリティを保証することはできませんが、それはほとんどすべての場合に当てはまります。

— マット

@CodeWorksほとんどのブラウザは、SSL証明書がリソースに対して間違っている場合でも、HTTPSリソースに接続する機会をユーザーに提供します。これは、間違いなく、ブラウザ作成者がこれまでに行ったことのない馬鹿げたことの1つであり、本質的にMITM攻撃を受け入れることを提供しています。

— ロスパターソン2013

@Dan次に、その特定の MITM証明書をクライアントのルート証明書リストに追加する必要があります。それ以外の場合は、HTTPS警告を文字どおり「泣き狼」に減らし、A）ユーザーにそれを永久に無視するように訓練します。B）現実の悪意のあるMITM攻撃と区別するのが困難です（Aのため不可能）。

— Nick T

SSLを使用すると、転送されるデータは暗号化されるため、httpヘッダーを介したアクセストークンの転送には重大な問題はありません。つまり、その要求を行った特定のクライアントと、その要求に応答するサーバーだけが理解できるため、その間に第三者によるデータの理解。

もう1つaccess tokenは時間ベースであるため、特定の期間の寿命があり、将来使用される可能性がありません。

— アシュウィン
ソース

-1

考慮すべきことはキャッシングです。

バックエンドは、同じGET / POSTパラメーターを使用して同じURLへの複数の呼び出しを確認できますが、ヘッダーアクセストークンが異なり、コンテンツをキャッシュして任意の本文にサーバー化できると考えます。

— トーマスデコー
ソース