Zenn
🧐

改めて人に聞かれると説明が微妙に難しいやつ[4] トークン編

2023/02/04に公開
初心者
Security
tech

微妙に難しいシリーズ4回目、今回のテーマはこちら

"トークン"ってなんだ？


例えばクレジットカードやデビットカードを持っていて、
web上からサイトにログイン後、登録情報を変更したい場合に

ワンタイムトークン を入力してください

と画面上で案内されたのち、登録情報の変更をした経験がある方もいるかもしれません。
そんな身近なようで、それでいて説明が微妙に難しい用語「トークン」について解説したいと思います。

後述しますが、今回はややサーバーサイドエンジニア向けの内容になります(基本的な概念・仕組みの部分では非エンジニアの方でもお読みいただける内容になっています)

その前に

今回参考にさせていただいた書籍・サイトの紹介をさせていただきます。
(この記事よりも、↓を参照することでより確実な情報が得られます)

① 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 第2版

https://www.sbcr.jp/product/4797393163/
独立行政法人情報処理推進機構(IPA)非常勤職員でもある徳丸浩氏の著書です(通称:徳丸本)
第2版が出版された2018年6月から5年弱経過しましたが、2023年現在においても重要かつ必要な情報が満載の一冊です。

また、徳丸氏は上記書籍に加えて継続的にさまざまな形で情報発信をされている方なので、
https://blog.tokumaru.org/

YouTubeのvideoIDが不正ですhttps://www.youtube.com/@websecstudy

これらと併せて読むと、より理解が深まると思います。
なお2022年12月に、上記書籍のサポートサイトにM1/M2 Mac向けDocker実習環境の情報が追加されました。
https://wasbook.org/wasbook-docker.html
これから手を動かして学習を始める方・かつ上記に該当する方は、↑を参照の上環境構築すると良さそうです。

② 安全なウェブサイトの作り方 改訂第7版

(※版数は2023年2月1日現在の情報です)

https://www.ipa.go.jp/security/vuln/websecurity.html
こちらは書籍ではありませんが、IPAが公開しているwebアプリケーションエンジニア向けの資料集です。
第1章の内容だけでも基本的なセキュリティの知識を十分に味わうことができるでしょう。
また、セキュリティに関係する設計・実装を行う場合の参考書としても重要な情報源と言えます。

あとがき(ではありませんが)

ここまでお読みいただきありがとうございました🙏
正直言えば、この記事を目にした方が上記参考書籍・サイト参照してくれたのなら
この記事の役割はほぼ果たされたことになります。

このままブラウザバック/タブ閉じしていただいて構わないのですが、
それで終わってしまうとおもしろくないので、もう少し足掻いて調べた結果をここに記します。
(タイトルにもある通り、私自身が微妙に説明が難しいままの状態からの脱却を目的とした記事シリーズなので)

故にここから先は個人的な備忘録となります、

  • 上記参考リンクの内容が難しいと感じ、理解のとっかかりが欲しいと感じた方
  • 私の公開したn次情報を鵜呑みにせず読んでいただける方
  • 私の公開した情報を確認の上、誤りの指摘・補足事項があればコメントしたいと感じた方

よろしければ引き続きお付き合いください🙇

これを読む前の前提知識

本記事の想定読者

ITエンジニアか否かを問わず、

  • トークンの概要だけでもまず知りたい方
  • トークンの利用法・利用例を知りたい方
  • トークンの扱いが適切でないとどうなるかを知りたい方

本記事執筆の目的

  • webアプリケーションにおける最低限のセキュリティ知識を持ちたい読者の
    最初のステップとなる文章であること
  • 上記で紹介した参考書籍・サイト情報の理解を補助する文章であること
  • 筆者自身がより明確に用語(本記事ではトークン)の理解し
    他者への適切な説明能力の獲得出来る取り組みであること

本記事では取り扱わないこと

  • トークンに関する詳細な仕様・乱数生成の仕組みなどの解説
    (別記事で取り上げます)

本題

■ "トークン"の語源について

📗 辞書で調べる

まずはいつも通りの手順で、理解へのヒントを得るために和訳してみましょう。
例によって私の手元にある コウビルド エッセンシャル英英辞典 を参照します。(余談→)[1]

token

a round, flat piece of metal or plastic that you can use in a machine instead of money　(コインの代わりに機械で利用可能な、丸く平らな金属またはプラスチック板)
例: The machine uses plastic tokens rather than coins.
(この機械はコインではなく、プラスチックのトークンを使用します。)

雰囲気としては「なにかの対価として利用される、コインの形状をした貨幣の代わりに使われるもの」といったところでしょうか。

💡 webの世界以外での使用例

また、ボードゲームの専門用語として

「代用貨幣」、「引換券」、「しるし」などを意味する英語で、ゲーム内においてさまざまな数をカウントするときの用語です。小さなタイルやチップなどをトークンとしてよく使用します。
「コストとして◯◯トークンを3つ場に払う」といったように説明書に記載されている場合があります。

JELLY JELLY CAFE トークンの項目より引用
↑ゲーム上では、このような意味合いで使われるそうです(初めて知りました👀)

いずれも概念というより物理的に存在するアイテムという書かれ方ですね。なんとなく理解。

■ "トークン"の意味(仮説)

ではwebアプリケーションの世界では何を意味するものになるでしょうか？
物理的存在ではなく概念・仕組みから捉えるとして、
何らかの権利(情報の閲覧や更新・削除)を得るための対価、とすると・・・
なんだかログイン認証におけるID, パスワードの概念にも似ているような気がします。
トークンとID, パスワード、両者に違いはあるのでしょうか？

次は具体的な例を挙げつつ、その正体を追ってみましょう。

■ トークンの具体例・利用例

様々な場面で利用されているトークンですが、大規模なシステムでの例を2つ挙げます。
まずはそこから大枠の概念と仕様をみていきましょう。

IBM Db2[2]

IBM社が公開しているドキュメントには下記のような記載があります。

IBM Documentation トークン認証

トークン認証は、統一された方式で Db2®サーバーへの認証に使用できるようにトークンを汎用化するためのメカニズムです。
文字列およびトークン・タイプとして表されたトークンは、クライアントからサーバーに送信されます。
クライアントにはトークンの内部は見えませんが、サーバーはトークンを認識して検証できます。

現在、Db2はJSON Web トークン(JWT)をサポートしています。
トークンは、ユーザーIDとパスワードの代わりに使用されます。
トークンは、ユーザーのIDとそのIDの証明を1つのエンティティーとしてカプセル化します。
トークンはDb2の外部で生成され、connectステートメントで入力として渡されます。
同じトークンを複数のサービスに使用するアプリケーションまたはIDプロバイダーで生成されたトークンでは、一種のシングル・サインオン(SSO)を利用できます。(以下略)

https://www.ibm.com/docs/ja/db2/11.5?topic=details-token-authentication より引用

Okta クラウド型ID管理・統合認証サービス

Okta社が公開しているドキュメントには親切な説明書きがありました。

トークンベースの認証とは？ 仕様とJWTのメリット、デメリット

トークンベースの認証とは、ユーザーが自分のアイデンティティを確認し、代わりに一意のアクセストークンを受け取ることを可能にするプロトコルです。
トークンの存続期間中、ユーザーはトークンが発行されたWebサイトやアプリにアクセスできます。
同じトークンで保護されたWebページ/アプリ/リソースに再度アクセスするたびに、資格情報を再入力する必要はありません。
認証トークンは、刻印されたチケットのように機能します。認証トークンが有効である限り、ユーザーはアクセスを保持します。
ユーザーがログアウトするか、アプリケーションを終了すると、認証トークンは無効になります。
トークンベースの認証は、従来のパスワードベースまたはサーバーベースの認証手法とは異なります。
認証トークンはセキュリティの第2レイヤーを提供し、管理者は各アクションとトランザクションを詳細に制御できます。(以下略)

https://www.okta.com/jp/identity-101/what-is-token-based-authentication/ より引用

さらに文中の アクセストークン のリンク先にはより具体的な情報がありました(Google翻訳にかけた結果を記載しています↓)

アクセストークン

アクセストークンは、大量のデータを含む小さなコードです。
ユーザー、アクセス許可、グループ、および時間枠に関する情報は、サーバーからユーザーのデバイスに渡される1つのトークンに埋め込まれています。
多くのWebサイトがアクセストークンを使用しています。
たとえば、あるWebサイト(Facebookなど)の資格情報を使用して別のWebサイト(Salesforceなど)にアクセスしたことがある場合は、アクセストークンを使用したことになります。[3]

↑を読んでいて、TwitterやGoogleアカウントで別なサービスにアクセスしたこと経験を思い出しました🤔
これは引用文中の例と比べても近似性がありそう。
考察はさておき、以下続きです。

Access Token: Definition, Architecture, Usage & More

一般的なアクセストークンには3つの異なる部分があり、これらすべてが連携してユーザーのリソースへのアクセス権を検証します。
ほとんどのアクセストークンには、3つの重要な要素が含まれています。

  1. ヘッダー:トークンのタイプとそれを作成するために使用されるアルゴリズムに関するデータがここに含まれます。
  2. ペイロード:アクセス許可や有効期限など、ユーザーに関する情報がここに含まれます。
  3. 署名:受信者がトークンの信頼性を確認できる検証データがここに含まれます。通常、この署名はハッシュ化[4]されているため、ハッキングして複製することは困難です。(以下略)

https://www.okta.com/identity-101/access-token/ より引用

🖋 情報を整理する

先ほど仮設の段階で、こんな個人的疑問を書きました。

トークンとID, パスワード、両者に違いはあるのでしょうか？

これに対する解答は得られました。違いは下記の通りです。

  • 認証の有効期限があるかどうか[5]
  • ”ユーザーIDとパスワード”の代わりに使用されるものである点
    (そもそもの用途が違うということなのでしょうか)
  • クライアント(ユーザー含め)からはトークンの具体的な内容は分からない点[6]
  • ユーザー自身で文字列を直接入力するかどうか
  • シングル・サインオンが実現可能かどうか[7]
  • 認証, 証明, 資格の検証方法が異なる

逆に両者の共通点は、
特定のユーザーがある情報にアクセスする際に、権限があるかどうかの検証を行う仕組み
という点でしょうか。
詳細な仕様・検証の仕組みについては引用元に委ねるとして、
これでトークンの正体はほぼ掴めました。

■ トークンの具体例・利用例(身近なもの)

ここまでの調査の結果、具体的なことが分かってきました。
今度はトークン技術が、実際のところ私たちの日常生活でどのように使われているのか？
身近な例を挙げつつ、トークンの恩恵についての理解を深めてみましょう。

🛒 ECサイトで買い物する

ECサイト(ショッピングサイト)での買い物を行うケースを考えてみます。ここでもトークンの技術が活躍します。

ECサイトでの商品購入での一般的なフローとしては

  1. 商品を選択して「カート」に入れる
  2. 購入個数や送り先・決済方法などを入力する
  3. 確認画面で注文内容を確認する
  4. 購入を確定する

このような流れでユーザーは実店舗に行くことなくオンライン上で買い物を完結することができますが、
トークンが用いられるのは3~4、注文の確定時です(「購入を確定する」ボタンをクリックしたとき)
webアプリケーションのサーバーに注文情報を送信するタイミングで、トークン情報を併せて送信することで正常に購入処理を行う対策に用いられます。

💻 サイトにログインする

SNSや業務用アプリケーションにログインするケースを考えてみます。
例えばユーザーIDとパスワードを入力してログインボタンを押し、入力ミスがなければログインに成功する場合です。
この際にセキュリティ上問題なくログインできるように、トークンが使用されるケースがあります[8]

💻 サイトの登録情報の変更をする

SNS等のアカウント情報を変更するケースを考えてみます。
特に金銭のやり取りに必要な情報(クレジットカード情報や保有ポイントに関する操作)の変更時に、トークンは重要な役割を担っています。
ECサイトの例と同様に、トークンが用いられるのはアカウント情報の入力後、変更内容を確定するタイミングです。

いずれもユーザーが入力フォームに情報を入れてそれをサーバーに送信する点で共通していますね💡

■ トークンの利用が不適切だと何が起きるのか？

下記の例はトークン以外の要素も絡んでくる場合もありますが結論から言えば、

  • 個人情報を盗まれます。
  • アカウントの乗っ取り・なりすましをされます。

その結果、身に覚えのないクレジットカード利用をされたり、他者によるSNS投稿をされる可能性があります。
また業務用webアプリケーションの場合は、社外秘情報の漏洩や不正操作による損害を被る可能性があります。[9]

多くのwebサイトでは、そのような不正アクセスや攻撃を回避するような仕組みを取り入れて開発されていますが、
長期間最新の対策がなされないまま放置されたサイトは、特に攻撃の標的とされやすいため
システムの開発・保守運用担当者は定期的なセキュリティ診断及び適切な対策、
システム内部のバージョンアップデートが欠かせません。[10]

あとがき

最後の最後までお読みいただき本当にありがとうございます🙏
今回は深く突っ込んだ解説には至らなかったのでいずれより開発者向けの内容で記事を書いてみたいと思います。

最新の言語・フレームワークで開発していると、さほど意識せずセキュティ対策が組み込まれていたり
もし実装に不備があった場合でも警告が出るので、ミスを事前に気付けるのは便利なのですが、
セキュリティについての深い知識がなければそれでもなお脆弱性を残したまま本番リリース・・・という可能性は十分にあり得ます。
その点を意識してこれからも開発を行っていきたいと改めて再認識させられました。

Typo指摘, ここは正しく無いのでは？ 等あればお知らせください。
改めてよろしくお願いいたします。

それでは次のシリーズ記事でまたお会いしましょう。

脚注

  1. 発音が似ているので、記事を書いていて一瞬勘違いしましたが、動詞"take"の過去分詞はtakenなのでトークンとは全く関係なさそうです ↩︎

  2. IBM社が販売しているデータベース製品を指します ↩︎

  3. 前述のシングル・サインオン(SSO)を指します ↩︎

  4. 対象のデータを不可逆的に変換する手法を指します ↩︎

  5. システムの仕様によっては、定期的にログインパスワードが強制変更され・別途新しいパスワードが配布されるケースもあります ↩︎

  6. 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 ではトークンをユーザーが知り得ない情報であることから '秘密情報' と説明しています ↩︎

  7. ユーザー個人が”IDとパスワード”を複数サイトで使い回すというケースはここでは除外します ↩︎

  8. このケースでは必ずしもトークンが使用されるわけではありませんが、いわゆる セッションID固定攻撃 に対する防御として用いられることがあります ↩︎

  9. 攻撃の種類には様々なものが存在しますが、ここでは特に CSRF (クロスサイトリクエストフォージェリ)攻撃による危険性について記載しました ↩︎

  10. システム開発で用いられるプログラミング言語やミドルウェアが日進月歩で改良されるのと同じく、システムに対する攻撃の手口も日々巧妙化しています。そのためセキュリティに対応した技術を選定し、理解しいた上で活用することが重要です ↩︎

Discussion