SSTエンジニアブログスマートフォン用の表示で見るSSTエンジニアブログSSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。CTOのはせがわです。弊社では、スマートフォン向けのアプリケーションについても通常のWebアプリケーション同様にバックエンドのWebサーバーに対しての診断を行なっています。スマホアプリはブラウザーと同じくHTTPで通信しているとは言っても、細かなところでブラウザーとは異なることがあるため、ごく稀に診断の過程でうまく通信ができないなどの問題が出てしまうことがあります。そのときに、Fiddlerを使って回避することができましたので、その内容を紹介したいと思います。使うと通信ができないある日、弊社福岡ラボの診断員がスマートフォン向けアプリを対象としたWebアプリケーションを診断している際に、理由がよくわからない現象があるので誰か教えて欲しいというというヘルプがSlackに投げられました。スマートフォンとバックエンドのWebアプリケーションの間にFiddlerのみを挟んでいる場合には正常に通信ができるのに、Burpを挟むと一部の通信でだけスマホアプリ上で「通信エラーが発生しました」というメッセージが表示され、正常な画面遷移ができなくなるというものです。以下の4パターンを試したところ、Fiddlerのみのパターン1では正常に通信ができていましたが、Burpを挟んだパターン2〜4では通信が失敗してしまいました。通信できないパターン1のFiddlerを使い正常に通信が行えたときのFiddler上でのHTTPのログは以下の通りでした(もちろん、一部を伏字にしています)。keep-alive(バイト列、以下省略)一方、パターン2のBurpを使い通信が行えなかったときもBurp上では以下の通り通信を記録できていました。keep-alive(バイト列、以下省略)特定のプロキシーツールを挟んだ場合に通信できなくなるといった場合の典型的な理由としては、TLSのサポートされているプロトコルバージョンや暗号方式が異なるというものですが、Burp上では通信が記録できているということは、どうもTLSが理由というわけではなさそうです。Modification)などを色々変更してみますが、一向に状況は改善しません。タブで表示させてみるとそれぞれ以下のようになっていました。パターン1のFiddlerのみの通信では以下の通りです。0:00:00.241(略)一方でFiddlerの後段にBurpを挿入したパターン4での通信では以下のようになっていました。0:00:11.315違いがわかるでしょうか。まで、つまりサーバーがリクエストを受信してからレスポンスを返し始めるまで、10秒ほど時間がかかっています。このあたりに問題がありそうです。して存在していることがわかります。この違いはどこから出てきたのでしょう。記録されていることがわかりました。リクエストヘッダーを送出していないということになります。リクエストヘッダーを付与すべきといえます。これが付いていないためにBurpではスマホアプリからのリクエストを受信した際にどこで通信を終了するかの判断ができずconnectionが切れるまでの間スマホアプリ側へレスポンスを返さずに待ち続けてしまい、一方スマホアプリ側はその間レスポンスを待ち続け10秒間でタイムアウトのエラーが発生するというのが今回の事象のようです。リクエストヘッダーがないことだとわかってしまえば、あとは簡単です。挿入することにします。メソッドに以下を追加します。付け加えるという処理をFiddlerScriptで行いました(実際にはヘッダーを付け加える場合はもう少し複雑な条件を加味しました)。これでFiddlerの後段にBurpを配置した場合でもスマホアプリは正常に通信させることができました。まとめスマートフォン向けアプリケーションでバックエンドのサーバーとはHTTPで通信をしている場合であっても、ブラウザーによる通信とは細かなところで差異があり、そのためにBurpや診断ツールなどを利用した場合にうまく通信できなくなることがあります。今回はうまくFiddlerだけで調査から解決まで行うことができましたが、場合によってはWiresharkのようなツールを使ってより低いレイヤーから調査を行ったりと、Webの診断といえど相応に広い知識が要求されることも多くあります。reserved.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。