LoginSignup
29
10

More than 1 year has passed since last update.

ミクシィグループAdvent Calendar 2021Day 9mixi
@naoki_kameyamain株式会社MIXI

harファイルくれっていわれるとハァ？って言いたくなる話

Last updated at Posted at 2021-12-08

はじめに

こんにちは ミクシィアドベントカレンダー2021 の9日目の記事です。
完全に出落ちなんですが、このような記事を開いて頂きありがとうございます。引き返すなら今です。

harファイルくれっていわれるとハァって言いたくなるっていう駄洒落を言いたかっただけなんですが、皆さんは「harファイルくれ」って言われたことありますでしょうか。

エンジニアの人：ハァ…。
非エンジニアの人：har？
セキュリティの人：ハァ？

無いかもしれませんが、言われた時の感想は人によって様々だと思います。私はHTTPを中心にWeb系技術を扱うことが多いのですが、不具合調査等で製品サポートや社外の方とお話させて頂く機会があり、わりと良く言われます。

実はわたくしセキュリティの仕事をしており、ハァ？ってなる時やハァ…ってなる時やハァハァってなる時がありまして、そういったハァポイントやハァってなった時に気を付けているポイントをまとめて紹介するという企画になります。ハァハァ。

harファイル

har は HTTP Archive の略のようで、この HTTP Archive format のファイルをharファイルと呼んでいます。中身はJSON形式でHTTP通信の内容に加えてページのロード時間等のパフォーマンス分析に役立つ情報が含まれています。私はWebページのパフォーマンスを分析したり不具合の調査をする時に利用させて頂いています。とても便利。この素晴らしき仕組みに感謝します。

HTTP Archive format の細かい歴史は良くわかっていませんが仕様は下記のようです。
http://www.softwareishard.com/blog/har-12-spec/
※ W3C Web Performance Working Group のほうは *DO NOT USE* とあるので恐らく上記が正しいと思います。

私は Google の Chrome DevTools で扱うことが多いですが、下記を見ると色々な所で使われているようです。
http://www.softwareishard.com/blog/har-adopters/
恐らくもっと多くの場所で使われている気はします。

Chrome DevTools

Webページで何かあった時にとりあえず開くコレです。私のPCではF12で開きます。わくわくする見た目ですね。
image.png
上記の Chrome DevTools の Network の画面を開いてレコーディング（赤い丸）が有効な状態でページをロードすると、HTTP通信の内容やロードタイミング等の情報を記録＆可視化してくれる優れものです。そして画面には次のような上下の矢印ボタンがあると思います。
image.png
この下矢印ボタンを押すとharファイルとしてエクスポートする事ができます。また逆に上矢印ボタンを押すとharファイルをインポートする事ができ、他人が記録したharファイルの内容をDevTool上で見る事ができます。サクッと開けて他にも便利な機能がいっぱいあるわけなんですが、詳しくは下記のドキュメントを見るのが良いと思います。これも本当に便利で感謝しています。
https://developer.chrome.com/docs/devtools/

harファイルの注意点（セキュリティ視点）

実は前述の HTTP Archive format の仕様の序盤にも下記の記載があります。

Notice that resulting HAR file can contain privacy & security sensitive data and user-agents should find some way to notify the user of this fact before they transfer the file to anyone else.

  • harファイルにはプライバシー情報や秘密情報が含まれる可能性がある点
  • harファイルを他人に渡す前にユーザエージェントはこの事実を通知する必要がある点

え？常識でしょって？いやまぁほんとそうなんでしょうけど。ええ確かに通知されました。全然覚えてないですが、間違いないです。うん覚えてない。仕様をみて設計者のやさしさに気づきました。すみません悪いのは自分なんです。でも今回は通知の話では無いのと、そこまで問題とも思えないので通知の話はスルーします。

秘密情報が含まれるかもヤバイというのは、harファイルの中身を見た時に気づいたり、周りから聞いてて知ってるって方も多いと思います。私もharファイルの中身を見た事があったので知ってたというだけでした。

でも仕事をしていると結構カジュアルにharファイルのやり取りがあるような気もしていて、正直余計なお世話だとは思いますが、どれくらいヤバイかを力説していきたいと思います。

harで他人に渡したらヤバイよランキング（私見）

すみませんランキングにする意味は特に無いです。盛り上がるかなと思って勝手にランキング形式でharに含まれる情報のヤバさをお届けします。とはいえ誤解が生まれるのは本意ではないため予め言っておきます。

ランキングに意味はありません。大事なのはharにどういう情報が含まれるのかを知り、相手に渡しても良いものなのかを考えたり、渡すならこうしないといけないよね。というのを考えたり判断する事です。

そのきっかけになる事を祈り、盛り上がって行きましょうということで。次のような観点でランキングしたいと思います。

  • harへの含まれやすさの観点
  • 情報漏洩の観点　※私が他人に知られたくない度合い
  • なりすましの観点

第1位 cookie(s)

例えばWebアプリケーションのセッションIDのような秘密情報がここに含まれる可能性があります。もちろんcookieを使わずにセッション管理を行う可能性もありますが、多くのWebアプリケーションでセッションIDをcookieでやり取りしているものと思います。

認証後に発行されたセッションIDの多くは、ユーザアカウントの所有者本人である事の証となります。この証をcookieという仕組みにのせて、Webアプリケーションにアクセスする際の通信に毎回含める事で、サーバ側はユーザを識別し情報を返します。そのため、自分のセッションIDを他人に渡してしまうと、他人が自分のユーザアカウントになりすましてWebアプリケーションを利用できてしまいます。

つまりharファイルを考え無しに渡してしまうと、他人が自分のユーザアカウントで好き勝手できてしまう可能性があります。

下記はとあるWebアプリケーションのプロフィール画面を表示した時のharファイルから抜粋＆マスクしたものです。user_session_key や secure_token がばっちり入ってます。

"cookies": [
    {
      "name": "user_session_key",
      "value": "xxxxxxxxxx",
      "path": "/",
      "domain": "xxxxxxxxxx",
      "expires": "2022-12-06T10:15:07.875Z",
      "httpOnly": true,
      "secure": false
    },
    {
      "name": "secure_token",
      "value": "xxxxxxxxxx",
      "path": "/",
      "domain": "xxxxxxxxxx",
      "expires": "2041-12-06T10:14:47.007Z",
      "httpOnly": true,
      "secure": true
    },

ちなみに仮にcookieでセッション管理をしていなくとも、ログイン後のページであればharファイルにセッションIDが含まれる場合が殆どだと思います。また呼び方もセッションIDである保証はありませんが、それに相当する値がどこかに入る場合が殆どだと思います。

第2位 postData

例えば入力したパスワードやクレジットカード情報がここに含まれる可能性があります。もちろん queryString もharファイルには入りますし、そちらも秘密情報が含まれる可能性はゼロではありません。ピンポイントで狙わないとharに入らないことと、MFA等で一命をとりとめるケースもあるため第2位としました。

下記はとあるログイン処理時のharファイルから抜粋＆マスクしたものです。パラメータに見覚えのある方もいるかもしれません。今回はthisispasswordという適当なパスワードを入力していますが、ばっちりharファイルに含まれています。

"postData": {
    "mimeType": "application/x-www-form-urlencoded;charset=UTF-8",
    "text": "action=iam-user-authentication&account=xxxxxxxxxx&username=xxxxxxxxxx&password=thisispassword&client_id=xxxxxxxxxx&redirect_uri=xxxxxxxxxx&metadata1=undefined&mfaType=U2F&mfaSerial=xxxxxxxxxx&signatureData=undefined&clientData=undefined&keyHandle=undefined&code_challenge=xxxxxxxxxx&code_challenge_method=xxxxxxxxxx&rememberAccount=false",
    "params": [
      {
        "name": "action",
        "value": "iam-user-authentication"
      },
      {
        "name": "account",
        "value": "xxxxxxxxxx"
      },
      {
        "name": "username",
        "value": "xxxxxxxxxx"
      },
      {
        "name": "password",
        "value": "thisispassword"
      },

第3位 content

レスポンスに含まれるコンテンツも持っています。ページに表示される情報はもちろんですが、コンテンツを丸ごと記録しているのでhiddenで埋め込んでいる値なども含まれる可能性があります。昨今のアプリでは秘密情報をレスポンスとして極力返さない作りも多いですが、何が含まれるかはページによって様々です。秘密情報や見られたくない情報が含まれるかもしれないため注意が必要です。第2位と甲乙つけがたいですがなんとなく第3位としました。

下記はとあるトークン発行処理時のharファイルから抜粋＆マスクしたものです。contentのtext要素内にばっちりトークンが入ってます。

"content": {
  "size": 140196,
  "mimeType": "text/html",
  "text": "
  （～ 長いので省略 ～）
  <input class=\"form-control\" id=\"new-oauth-token\" type=\"text\" placeholder=\"Access token\" aria-label=\"access token\" disabled value=\"ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\">\n          <span class=\"input-group-button\">\n
  （～ 長いので省略 ～）
  "
},

第4位以降

ヘッダなど他にもあると思っていますが、ランキングはどうでもいいので終了します。

何が言いたいか

繰り返しにはなってしまいますが、整理すると私が言いたいのは下記の3点です。

  • harファイルにはプライバシー情報や秘密情報が含まれる可能性がある点
  • 極力他人に渡したくないが、渡すならそれ相応の扱いや注意をもって行いたい点
  • でも結構カジュアルにharファイルを要求されるような気がする点

渡す側が（出来れば要求する側も）細心の注意を払って扱う必要がある。
当たり前なんだけど、何かそこまで注意が払われていないような気もする。という話ですね。

harでよくあるハァポイント

この駄洒落を引っ張るのがきつくなってきましたが、セキュリティに関わらずいくつか紹介していきたいと思います。

  • ハァ？（言われた通りにすると私の認証情報が見えちゃうじゃないですか）
  • ハァ…（作業後の削除や受け渡し方法など安全に配慮してくれるのだろうか）
  • ハァ…（このタイミングのhar渡して意味あるのかな）
  • ハァ？（再現方法不明なのにharとれるわけないじゃないですかぁぁ）
  • ハァハァ（なんか不安だから面倒臭いけど頑張ってマスクしよう）

皆さんも経験ありますでしょうか。まぁ色々あったりなかったりするかもしれません。

セキュリティ的にどうしているか

セキュリティに関するハァポイントについて、私が注意している内容を紹介してこの記事を終了したいと思います。

  • まず相手と機密保持契約があることを確認する。
  • 極力余計な通信が入らないようにする。
    • レコードタイミングに気を付ける。
    • ログの取り漏れが無いよう Chrome DevTools の Preservelog を有効にしている場合等は特に。
  • とりあえずhar取得後に現在のセッションを破棄する。
    • ログアウトすれば大体のアプリで現在のセッションIDを無効にしてくれる事でしょう。
    • ログアウトが通用しない場合は暫くharファイルを寝かせる。タイムアウトさせる。
  • 各種セキュリティ対応のファイル転送サービスでやりとりする。メールに添付しない。
    • 大前提としてhttpsなサービス。E2Eの暗号化をしたいため。
    • 相手がDropBoxのようなファイルリクエストを送ってくれると楽。
    • 自分から渡すなら DL回数制限/履歴閲覧/DL期限/パスワード機能 などがあるとなお良い。
    • 転送し終わったらファイル転送サービスから消す。自動で消えるならそれで良し。
  • 作業後に削除を依頼する。削除する or 削除した の旨を記録に残る形で返信頂く。
  • 機密保持契約も無いしどう頑張っても不安が拭えない場合はマスクする。

harファイルの内容を確認して秘密情報や漏れて困る情報が含まれない事が明らかならばここまでする必要は無いと思いますが、私の経験では含まれる事のが多いので上記のような事に注意して扱っています。

さいごに

har も Chrome DevTools も大好きです。harの仕様を読んで優しさを感じつつ、利用する側も相応の認識を持って取り扱わなければと改めて感じたのと、皆が注意しあってより良い世の中になっていけたら良いなと思っています。OSSには全然貢献していませんが、harに関するセキュリティ意識醸成の一助となる事を祈りつつ、わたくしのアドベントカレンダーの記事を終了します！

29
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
29
10