HTTPSおよびクライアント側の改ざんに関する質問
誰かが私に何か説明してもらえますか？
ローカルプロキシからHTTPSサーバーへのリクエストを傍受しています。 POSTの本文には、「ID = 4001」などのデータが含まれていますが、インターセプトするとプレーンテキストで表示されます。まず、これは正常ですか？このサーバーのHTTPSは弱いですか、それとも光沢がありませんか？
機密情報がここでは平文であると私が考えるものをここで誰かが説明できますか？
- 開発者はボールをドロップし、クライアントが簡単に改ざんできるようにプレーンテキストで提示しましたか？
- HTTPSが適切に構成されている場合、これは暗号化されますか？
- 自分のマシンからローカルでリクエストをインターセプトしているため、HTTPSはリクエストがネットワーク/送信を通過するまで効果がありませんか？
クライアントからのリクエストを直接（つまり、ネットワークを介してではなく）直接インターセプトしています。私自身の理解のためにこれについて少し明確にすることを試みています、私はこの段階でHTTPSがほとんどまたはまったく影響を与えず、ID = 4001が開発者側の障害であると考えて正しいですか？
ps。このIDは非常に機密性が高いため、誰かがそのIDを知っていたり、改ざんしたりしてはなりません。
更新：私の質問は、自分で実行されているWebアプリケーションに対してクライアントパケットを傍受すると、burpsuiteでこのID param/valueがプレーンテキストで表示されると思います-signed HTTPs cert（自己署名は関係ないと思います）、このIDを確認できるという事実は開発者の責任ですか？または私は愚かであり、これは実際の運用環境で暗号化されますか？画像を見る：
HTTPSトラフィックの監視を許可するようにBurpSuiteを構成したように聞こえます。 ドキュメント によると：
デフォルトでは、Burp経由でHTTPS Webサイトを閲覧すると、プロキシは各ホストのSSL証明書を生成し、独自の認証局（CA）証明書で署名します。このCA証明書は、Burpが初めて実行されたときに生成され、ローカルに保存されます。 Burp ProxyをHTTPS Webサイトで最も効果的に使用するには、BurpのCA証明書を信頼されたルートとしてブラウザーにインストールする必要があります。
注：信頼されたルート証明書をブラウザーにインストールした場合、その証明書の秘密鍵を持っている攻撃者は、傍受を使用していない場合でも、明らかな検出なしにSSL接続の中間者になる可能性があります。プロキシ。これを防ぐために、Burpはインストールごとに一意のCA証明書を生成し、この証明書の秘密キーはコンピューターのユーザー固有の場所に格納されます。信頼できない人があなたのコンピュータのローカルデータを読むことができるなら、あなたはBurpのCA証明書をインストールしたくないかもしれません。
つまり、本質的に、BurpSuiteはローカルマシンで実行され、独自の証明書をインストールするという事実を利用して、man-in-the-middle攻撃を実行しています。
通常の使用例では、BurpSuiteはクライアントマシンにインストールされておらず、ハッカーはルート証明書をインストールすることができません。この機能がないと、ハッカーはブラウザでセキュリティ警告をトリガーしないと中間者攻撃を実行できず、Chromeでは次のようになります。
あなたの質問に答えるには：
開発者はボールをドロップし、クライアントが簡単に改ざんできるようにプレーンテキストで提示しましたか？
いいえ。プロトコルは意図したとおりに機能しています。これは、ネットワーク上で起動された中間者攻撃からユーザーを保護します。証明書をインストールするのに十分な権限を持つローカルマシンで実行されているプロセスによって起動される中間者攻撃からユーザーを保護することはできません。この方法でローカルで侵害されたマシンを保護できるテクノロジーは、宇宙にはありません。
HTTPSが適切に構成されている場合、これは暗号化されますか？
はい
自分のマシンからローカルでリクエストをインターセプトしているため、HTTPSはリクエストがネットワーク/送信を通過するまで効果がありませんか？
正しい。 HTTPSは一般にローカルアクセスからユーザーを保護しません（結局のところ、Chrome開発ツールでもトラフィックを確認できます）。これにより、ネットワーク上のリスナーが盗聴しようとするのを防ぎます。