フロントエンド担当者必携：パケットキャプチャの原理とパケットキャプチャツールホイッスルの使い方を詳しく解説

3 年後、モバイル H5 ページ開発に再び触れました。最後にインターンを行ったのは 4 年生の時でした。今回は、h5 ページとネイティブ アプリの間の対話を含むハイブリッド開発です。h5 ページは、ネイティブ アプリでログイン状態を開き、ネイティブ カメラを呼び出すなど、ネイティブ アプリのインターフェイスを呼び出す必要があります。 QRコードをスキャンします。 WeChat ミニプログラム開発とは異なり、WeChat ではローカル開発用の WeChat 開発者ツールが提供されており、ローカルでシミュレートして呼び出すことができますが、毎回静的ファイルをパッケージ化してデバッグ用にサーバーにアップロードする必要があり、非常に面倒です。

ネイティブ アプリがオンライン h5 を読み込むときに、ローカル コードを実行できますか?答えは「はい」です。ホイッスルなどのパケット キャプチャ ツールを使用して、オンライン ページのリクエスト データをインターセプトし、ローカル コードに応答できます。この記事では、主にパケット キャプチャの原理とパケット キャプチャ ツール ホイッスルの使用方法について説明します。

1. パケット キャプチャの原理

1.1 パケット キャプチャとは何ですか?

#パケット キャプチャとは、ネットワーク伝送中に送受信されるデータ パケットを傍受、再送、編集、転送することです。パケット キャプチャを通じて、次のことが可能になります。

• #ネットワーク問題の分析

• ビジネス分析

• ネットワーク情報フローの分析

• ネットワーク ビッグデータ財務リスク制御
  ##ネットワークに侵入しようとする攻撃を検出

• ##内部および外部ユーザーによるネットワーク リソースの悪用を検出

##ネットワーク侵入の影響を検出する
リンク インターネット ブロードバンド トラフィックを監視する
ネットワーク使用トラフィックを監視する (内部ユーザー、外部ユーザーを含む)およびシステム)

• #インターネットとユーザー コンピュータのセキュリティ ステータスを監視

• #侵入と欺瞞

• ...

• コンピュータ ネットワークの知識を思い出すと、データは

  frames
という小さな単位でネットワーク上に送信され、フレームはドライバーと呼ばれる特定のネットワークを通過します。プログラムが作成され、ネットワーク カードを介してネットワーク ケーブルに送信され、ネットワーク ケーブルを介して宛先マシンに到達し、宛先マシンの一端で逆のプロセスが実行されます。受信側マシンのイーサネットはこれらのフレームをキャプチャし、フレームが到着したことをオペレーティング システムに通知して、それを保存します。この送受信プロセス中に、パケット キャプチャ ツール (スニファー) を使用してパケットをキャプチャできます。フロントエンド開発者は通常、アプリケーション層で HTTP/HTTPS パケットをキャプチャします。

HTTP/HTTPS は、一般的なアプリケーションであるアプリケーション層で使用される通信プロトコルです。レイヤ システム アーキテクチャはクライアント サーバー アーキテクチャです。

異なるシステム上で実行されているクライアント プログラムとサーバー プログラムはどのように相互に通信するのでしょうか?実際、オペレーティング システムの用語では、実際に通信するのはプログラムではなくプロセス

Web アプリケーションでは、クライアント ブラウザ プロセスがサーバー プロセスとセッション メッセージを交換します。

プロセスは家にたとえることができ、そのソケットはそのドアにたとえることができます。ソケット

#2 つのプロセス間の通信プロセスがわかったので、パケットをどのようにキャプチャすればよいでしょうか?人生の一例を挙げると、シャオミンはシャオ・ウェンに憧れていたのでラブレターを書きましたが、少し恥ずかしがってシャオ・ウェンの親友であるシャオ・ホアにラブレターを届けるのを手伝ってくれるように頼みました。このとき、シャオファはシャオウェンとシャオミンの間のラブレターを届ける役割を担うことができ、仲介者として二人のラブレターの内容をこっそり見ることができます。

アイデアは、パケットのキャプチャを担当する仲介プロセスをセットアップすることです。ターゲット プロセス間の各セッションは、最初に仲介プロセスと通信し、次にそれを転送します。

http 規格では、通信終了認証に関する規格がありません。サーバーの場合、受信した HTTP リクエスト メッセージの形式が仕様を満たしている限り、応答メッセージを送信します。

同じことがクライアントにも当てはまります。クライアントは、接続先のホスト (http://www.jecyu.com

http://www.jerry.comのホストになる可能性があります。

1.2.2 HTTPS パケット キャプチャの原則HTTP はクリア テキスト送信であるため、中間者攻撃に対して脆弱であり、安全ではありません。

HTTPS セマンティクスは引き続き HTTP ですが、セキュリティ層SSL/TSLが HTTP プロトコル スタックの http と tcp の間に挿入されます。

セキュリティ層は対称暗号化を使用して送信データを暗号化し、非対称暗号化を使用して対称キーを送信しますという 3 つの問題を解決します。http データが暗号化されない、ID を検証できない、データが暗号化されない簡単に改ざんされるキーの問題。

HTTP 暗号化認証整合性保護 = HTTPS

ID 検証の問題は、サードパーティ組織 (CA 証明書) であるサーバーの証明書を検証することによって実現されます。発行局）は、デジタル署名テクノロジーを使用して、証明書の作成、証明書の保存、証明書の更新、証明書の失効などのを管理します。

ブラウザは HTTPS Web サイトに接続します。サーバーはサーバー エンティティ証明書だけでなく証明書チェーンも送信しますが、ルート証明書は含まれません。ルート証明書はWindows、Linux、macOS、Android、iOS などのオペレーティング システムに組み込まれています。

#1. 証明書チェーンの検証:

1.1 ブラウザは、サーバー エンティティ証明書の上位証明書 (B 証明書など) から公開キーを取得し、サーバー エンティティ証明書の署名を検証します (署名はプライベート 証明書を介して行われます)。 CA 組織の署名済みのキー)、検証が成功した場合は続行し、そうでない場合は証明書の検証は失敗します。

• #1.2 ブラウザは、証明書 B の上位証明書 (証明書 C など) から公開キーを取得して、証明書 B の署名を検証します。

• 検証が成功した場合は続行します。それ以外の場合、証明書の検証は失敗します。

1.3 ブラウザは各証明書の署名を繰り返し検証し、最終的に自己署名ルート証明書を見つけます (発行者とユーザーは同一人物です)。ブラウザはルート証明書を統合しているため、ルート証明書の公開キーを完全に信頼して、最終署名を完了できます。

• 2. サーバー エンティティ証明書の検証: アクセスされたドメイン名情報が証明書、日付、証明書拡張子の検証などと一致しているかどうか。

証明書の検証を理解した後、具体的な https 通信プロセスを見てみましょう:

• 非対称暗号化ハンドシェイクプロセスに従います

• ##クライアントは乱数を送信します

  random1
サポートされている暗号化アルゴリズムセット

• サーバーは情報を受信し、選択された暗号化アルゴリズム証明書 (S_公開キーを含む) を返します。

  random2

• クライアントは、その有効性を検証します。

  random1 random2
を使用し、
• pre-master-secure

  を生成し、server公開キー暗号化を介してサーバーに送信します##サーバーは、pre-master-secure

  に対して、
S_秘密鍵
• を使用して、合意されたアルゴリズム

  ## に従ってpre-master-secureを復号化します。#次に、暗号化アルゴリズムを使用してmaster-secure(対称暗号化キー) を生成し、それをクライアントに送信します

• クライアントは受信します生成されたmaster-secure、対称暗号化キーの送信が完了します

• 最後に、master-secureを実際の対称暗号化送信に使用できますデータの。

• #仲介者がパケットをキャプチャしたい場合は、HTTPS 通信を暗号化する前にクライアントから送信された証明書を傍受する必要があります。

• これにより、暗号化通信が確立され、仲介者は通信データ鍵を取得し、HTTPS通信メッセージを閲覧・変更できるようになります。

• ここでは、クライアントは仲介者と通信し、仲介者はサーバーと通信します。これらはすべて、通常どおり HTTPS 暗号化接続を確立します。

• 最も重要な手順の 1 つは、

  ブラウザのルート証明書の検証
です。CA 機関が証明書を発行することは不可能です。自分に属さないドメイン名証明書はクライアントのオペレーティング システムに存在しません。したがって、

にインポートすることしかできません。暗号化通信を確立する際に仲介者証明書の検証を完了します。

1.3 コンピュータは携帯電話のパケットをどのようにキャプチャしますか?コンピュータを通じてモバイル Web アプリケーションのデータ パケットを取得したい場合は、次のとおりです。これまでに学んだことを踏まえると、仲介者戦略が必要です。

Web アプリケーションのターゲット サーバーになりすます、PC 側でサーバー仲介プロセスを作成します。モバイル Web アプリケーションによって送信されたリクエスト データは、まず仲介者を通過し、中間者がそれを傍受して処理し、ターゲット サーバーに送信します。次に、ターゲット サーバーによって送信されたデータ パケットは、最初に仲介者を通過し、次に仲介者がブラウザ クライアントに応答します。

ここで注意すべき点は、パソコンであれ携帯電話であれ、インターネットネットワークに接続し、お互いを見つけて通信できる必要があるということです。

一般に、開発の場合、パーソナル コンピュータ上でローカルに起動されたサーバー プロセスには、パブリック ネットワーク上からアクセスできません。一般的には無線LANのことで、同じルーターから送られてくるWi-Fiにパソコンと携帯電話が接続して通信することができます。

• PC 上でサーバー プロセスをローカルに開始し、8899

  # などのポートをリッスンします。

##携帯電話で同じ LAN に接続し、ネットワーク プロキシを構成し、PC の IP アドレスとポート 8899
このようにして、携帯電話のすべてのネットワーク通信がブロックされます。まず PC 側の 8899 ポートに転送してから、データ パケットを分析して処理できます。
youtuBe へのアクセスを例として考えます。たとえば、[サーバー ソフトウェア] を使用してコンピューターに正常にアクセスできました。このとき、携帯電話の設定がプロキシに指定されている限り、プロキシはコンピューターの IP アドレスと指定されたポートを指し、携帯電話も youtuBe にアクセスできます。

Whistle は、以下に基づくクロスプラットフォームのパケット キャプチャです。ノードフリー デバッグ ツール、その主な機能:

1. 完全なクロスプラットフォーム: Mac や Windows などのデスクトップ システムをサポートし、サーバーなどのコマンド ライン システムをサポートします

2. 強力な機能:

HTTP、HTTPS、SOCKS プロキシおよびリバース プロキシとしてサポート

• ##HTTP、HTTPS、HTTP2、WebSocket、TCP リクエストのパケット キャプチャと変更をサポート

• HTTP、HTTPS、HTTP2、WebSocket、TCP リクエストの再生と構築をサポート

• ##アップストリーム エージェント、PAC スクリプト、ホスト、遅延の設定をサポート(高速限定) リクエスト応答など

• #コンソール ログとリモート ページの DOM ノードの表示をサポート

• ノードを使用した開発をサポートプラグイン拡張機能、独立した npm パッケージ リファレンスとしても使用可能

• 3. 簡単な操作

パケット キャプチャの表示と変更ブラウザ経由で直接リクエスト

• すべての変更操作は構成 (システム ホストと同様) を通じて実装でき、グループ管理をサポートします。

• ## プロジェクト独自のプロキシ ルールを持ち込んで、ワンクリックでローカル Whistle プロキシに設定できます。また、カスタマイズされたプラグインを使用して操作を簡素化することもできます

• #Whistle をすばやく使用する方法

#ホイッスルのグローバル インストール

##

npm i -g whistle & w2 start

w2 proxy // 设置全局代理 w2 proxy off // 关闭全局代理

SwitchyOmega

#Whistle エージェントの選択

##Whistle エージェントの設定

いくつかの構成例を以下に示します:

#3. ホイッスルの実際のケース

3.1 ネイティブ アプリのロード PC ローカル コード開発

ネイティブ アプリでは、Web ページは h5 ドメイン名を介してロードされていますが、ローカルで開発する場合はロードされません。毎回、組み立てラインやローカルでパッケージ化してコードをアップロードする必要はありません。

ネイティブ アプリのリクエストをローカル サーバーにプロキシする必要があります。前提条件は、Wi-Fi 電話とコンピュータが相互にアクセスできること、つまり、コンピュータが前述の PC パッケージをキャプチャできることです。

私の Web サーバーは https アプリケーションであるため、Whistle によって提供されるルート証明書をダウンロードし、手動で携帯電話にインポートする必要があります。

此时，再在手机上配置代理指向 PC 电脑的 IP和 whistle 监听的端口即可在电脑上截获数据包。

我本地webpack 启动的服务器应用访问地址为：xxx.xxx.xxx.xxx:8080

whistle 的配置规则：

# Rules # 访问首页走本地 jecyu.com/webs/short-transport http://xxx.xxx.xxx.xxx:8080?deptCode=755DL # 首页路径 # 后续的请求都使用本地代码 jecyu.com http://xxx.xxx.xxx.xxx:8080?deptCode=755DL

其中试过在原生 app 访问本地应用时出现错误“ webpack 会提示 invalid host header”，解决方案是在 devServer 配置添加即可：

devServer: { allowedHosts: 'all', }

至此，成功让原生 app 访问PC 端本地的开发代码。

3.2 查看移动端的 DOM 样式

Whistle 能够通过内置的 Weinre 去实现查看移动端的DOM样式，配置规则如下

# 设置 weinre https://juejin.cn weinre://test

手机上重新访问juejin.cn网站，然后打开 weinre 可以看到如下，绿色表示远程连接成功。

可以点击 Element 查看手机上网页 DOM 结构、样式等信息。

也可以在 console 控制台中，执行代码，比如 alert ，手机应用上会显示弹框。

4. 总结

学会抓包是软件开发人员必须掌握的调试技能，本文先介绍抓包的原理，再介绍抓包工具 whistle 的使用，whistle 非常强大，本文只是粗略的介绍，更多的使用技巧，大家可以查看官方文档whistle 文档。

参考资料

• 扯一扯HTTPS单向认证、双向认证、抓包原理、反抓包策略

• 网络抓包原理及Fiddler的使用

• 前端应该知道的web调试工具——whistle

• 移动端调试痛点？——送你五款前端开发利器

• whistle工具全程入门

• Whistle 配置 https 抓包

• 解决webpack5 invalid host Header问题

• whistle localhost不能代理

• Proxying to localhost no longer works

• 使用线上域名访问本地代码调试——whistle代理

• wiki数据包分析器

原文地址：https://juejin.cn/post/7140040425129115684

（学习视频分享：web前端）