SSLを介したPOSTのセキュリティ脆弱性
私は小さな会社で働き、ASP.NET Webアプリケーションを開発しています。最近、APIエンドポイントを公開する必要が出てきました。クラウドで実行されている自動化されたスクリプトが、特定のJSON形式のデータをアプリから定期的にWebリクエスト経由でプルバックできるようにするためです。これの実装は対応できますが、セキュリティの問題についてはよくわかりませんでした。私は [〜＃〜] hmac [〜＃〜] について今朝読んでいて、それが私が以前に使用した他のAPIのセキュリティプロトコルに非常に似ているように見えたので、その外観が気に入りました。しかし、それはいくつかのステップの価値が何であるか疑問に思いました。
クライアントとサーバーが以前の通信を介してパスフレーズ/キーに安全に同意した場合、POSTリクエストをHTTPSリクエストの本文の一部としてパスフレーズとともに送信することにはどのようなリスクがありますか？パスフレーズはユーザーを識別しますか？これを調べてみると、リプレイ攻撃などに遭遇しましたが、これらはSSLを介して機能し、クライアント側とサーバー側の両方の環境を信頼できますか？
編集：以下のユーザーのコメントに基づいて、説明を少し追加します。私たちの使用目的は、サーバーの1つまたはクラウドのいずれかでスクリプトを定期的（1時間、1日など）に実行することです。アプリやサードパーティのAPIから特定の情報を取得し、ビジネス開発チーム向けにクラウドベースのスプレッドシートを更新します。これは、理想的には実行したままにしておき、ユーザーの介入を必要としないものです。私たちのアプリは通常、一時的なセッションを生成するためにユーザー名/パスワードでログインする必要がありますが、プロセスを少し簡略化し、特定のデータを安全に取得するためのスクリプト用のAPIを提供することを望んでいました。
本物のSSL（はるかに古く、壊れている）ではなくTLSを意味すると仮定すると、POSTリクエストでパスワードを送信することは絶対に問題ありません。これは標準であり、どのようにすべての主要で安全なWeb認証サービスは機能します。TLSが適切に構成されていることを確認するだけで済みます。TLSは、心配しているすべての攻撃を軽減します。TLSは整合性のためにHMAC（または類似の認証）を使用し、リプレイ攻撃、リフレクション攻撃、および同様の問題を軽減します認証システムに影響します。
HTTPSはいくつかの目的を果たし、リプレイ攻撃を防ぎ、送信されるメッセージの機密性を提供します。これらの保証を守るために、クライアントはもちろんサーバーからのTLS証明書を正しく検証する必要があります。つまり、証明書を予想されるドメインと照合します（または自己署名証明書がある場合はフィンガープリントと照合します）。さもなければ、中間者攻撃はどちらの側にも気付かれずに行われる可能性があります。このようにして、クライアントは実際に適切なサーバーと通信していることを認識します。
しかし、サーバーはどのようにクライアントを信頼できますか？そのためには、クライアント証明書を使用するか、提案どおりにAPIキーを使用します。 APIキーは一般的な概念であるため、これを行うことで大きな問題が発生した場合は、それまでにそれをやめたでしょう。 APIキーを定期的に更新することをお勧めします。キーIDフィールドを簡単にローテーションできるようにすると便利な場合がありますが、通常、同じキーを数年間使用することは大きなリスクではありません-もちろん、情報の機密性、キーにアクセスできる人の数などによって異なります。