日本語

エンコード・デコードツール

テキストを各種形式に変換するツール群です。処理はすべてブラウザ内で完結するため、データが送信されることはありません。

エンコードツールの選び方

テキストの経路でバイト列を運ぶにはBase64を、アドレスの中に値を安全に入れるにはURLエンコードを使います。チェックサムや、共有鍵で送信者を証明するHMAC署名にはハッシュ生成ツールを使います。

JWTデコードツールはトークンのクレームを読むために、また秘密鍵があれば署名の検証にも使えます。JWT生成ツールはテスト用のトークンを作るため、CSRデコードツールは認証局に送る前に、その証明書要求が実際にどの名前と鍵を求めているかを確認するために使います。

似て見えるが異なる4つの役割

エンコードは、データをより安全な文字集合に書き直すもので、誰でも完全に元に戻せます。Base64とパーセントエンコーディングはどちらもここに属します。ハッシュは一方向で鍵を使わないため、どちらの内容も明かさずに2つの入力が一致することを証明できます。署名は秘密鍵を加えるもので、これによってメッセージが「誰が送ったか」の証拠になります。そして確認（インスペクト）は、すでに公開されている構造をただデコードするだけで、JWTやCSRのリーダーが行っているのはこれです。

高くつく誤解は、1つ目と3つ目を混同することです。Base64のペイロードは一見かき混ぜられているように見えますが、何も保護していません。持っている人なら誰でも一瞬で読めます。ここのデコードツールに貼り付ければ、簡単に実演できます。

繰り返し起きる失敗は「層」

エンコードはべき等ではありません。値を2回エスケープすると%20は%2520になり、引用符はバックスラッシュが二重に付いた引用符になり、オブジェクトを保持すべきペイロードにJSONの文字列が入ります。これは、フレームワークがどのみちエンコードする値を、アプリケーションのコードがすでにエンコードしているときに必ず起こります。

対処法は、受け取る側で2回デコードすることではなく、2つの処理のうち1つを取り除くことです。2回デコードしてもバグの場所が移るだけです。これらのツールで1層ずつデコードすれば実際に何層あったかがわかり、余分な層を加えたのがどのコンポーネントかを突き止める最短の道になります。

何を貼り付けているかを考える

ここでの処理はすべてブラウザ内で行われるため、貼り付けたものが送信されたり記録されたりすることはありません。これは知っておく価値があります。これらのツールに入る素材が無害であることはめったにないからです。CSRには社内のホスト名や組織名が、JWTにはユーザー識別子や権限が含まれ、ハッシュの入力そのものが秘密情報である場合もあります。

それでも守っておきたい習慣が2つあります。可能なら本番の秘密鍵ではなくテスト用の鍵で署名を検証すること、そしてこのページを含め、どんなWebページにも秘密鍵を貼り付けないことです。CSRは共有しても安全ですが、それに署名した鍵はそうではありません。