1 of 29

認証しないWeb認証

限定公開URLのセキュリティについて考える

  • 2020/8/7 API Meetup Online #3-

フューチャー株式会社 渋川よしき

2 of 29

お前誰よ？

Yoshiki Shibukawa�　Honda R&D：〜Dec/2010�　DeNA：〜Aug/2017�　Future Corporation：Sep/2017〜�　Family: wife and three daughters��Books�　つまみぐい勉強法、�　Real World HTTP第2版、Mithril、�　Goならわかるシステムプログラミング��Translations�　Expert Python Programming�　Agile Software Development with Scrum�　Pomodoro Technique Illustrated�　The Art of Community etc�

Favorite Languages�　JavaScript®️ / Go / Python��Hobbies�　Inline Skating��Account�　github.com/shibukawa�　twitter.com/shibu_jp

2

3 of 29

※Company Logo was changed the day before yesterday

4 of 29

フューチャーをざっくり言うと

  • 二人のエンジニアが創ったITコンサル会社
  • コンサルからSIまで全部やる
  • 中立（ニュートラル）のポジション
  • 「ないものはつくる」の精神

5 of 29

有名企業のお客様のシステムを多数手がけています

  • 日本貿易振興機構（JETRO）の「AI等を活用した貿易投資相談及び社内業務アシスタント構築」を受託
  • カワサキ機工の農機を連携し、茶葉生産情報管理サービスを共同開発
  • 新型コロナウイルス感染症等のワクチンの世界的な研究開発の促進のためエピトープ予測データセットとソースコードを無償公開
  • 企業活動オンライン化を実現する研修サービスをコードキャンプが提供開始
    • ～オンライン研修、バーチャル株主総会など300社以上の導入実績～
  • 内閣府「戦略的イノベーション創造プログラムスマート物流サービス」の研究開発を受託～物流ビッグデータの自動収集、多面的な活用に向けて～
  • 敷島製パンと共同で製品パッケージの印字チェック業務AI適用検証を開始

弊社プレスリリースサイトから抜粋

https://www.future.co.jp/press_room/

6 of 29

7 of 29

📛 Sponsor of Go Conference 2019

My Advent Calendar will describe Tofu on Fire of Go Conference 2019 Autumn

8 of 29

Real World HTTP 第2版好評発売中です

9 of 29

Real World HTTP 第2版好評発売中です

本日は第3版に入るかもしれないネタを特別にお届け

10 of 29

限定公開URL

11 of 29

限定公開URL

  • 認証していなくても秘匿されたコンテンツにアクセスできる特別なURL
    • 推測しにくいパス
  • 認証していないでOK
    • ユーザーを作る必要がない
    • 認証できない人にも
    • 認証のためのやりとりも不要
  • セキュリティ的に大丈夫？
    • きちんと論じた資料などがみあたらなかった�ので今回考えてみました
    • セキュリティ専門家ではないのですが、�なるべく正確な判断ができるように�明らかにしていこうと思います

12 of 29

正式名称？

  • 名前はいろいろ
    • 限定公開URL、共有URL、公開URL: サービス上で使われる名前
    • Magic Link: ログイン用途でよく使われる気がする
    • Signed URL: S3でコンテンツを限定公開するのに利用
    • Signed ID: Ruby on RailsのAPIで最近追加された
    • Capability URLs: W3Cのドキュメントにある→本文はこれで統一します！

13 of 29

Capability URLsの機能

  • コンテンツ・リソースの共有
    • Google Photos、Flickr、Google Calender
  • 限定アクセスのAPI
    • Second Lifeがそうだったらしい
  • パスワードのリセット
    • 一時的なURLを発行してメール送信→それをブラウザで開いてパスワード再設定
    • HTTP→SMTP→HTTPというAPIのリレー

14 of 29

Second Life

  • ユーザーID&パスワードでログインするとCapability URLsが入ったリストが送られてくる。クレデンシャルはなしに、これでAPIアクセスをしたらしい
  • 今では見ない方式

<llsd>

<map>

<key>create_user</key>

<string>https://cap.secondlife.com/cap/0/35ff3b8c-a30d-4d18-b29a-e3f7f6c79cb6</string>

​

<key>check_name</key>

<string>https://cap.secondlife.com/cap/0/6e528ba1-a8b0-4f6b-8b56-362ee6f5cef8</string>

​

<key>get_last_names</key>

<string>https://cap.secondlife.com/cap/0/be4e4d2e-c00a-46cd-bb8d-d17cb8e92c9b</string>

​

<key>get_error_codes</key>

<string>https://cap.secondlife.com/cap/0/e75f81a5-b7da-4480-8f95-b1cf9d2d680f</string>

</map>

</llsd>

15 of 29

メリットとデメリット

  • メリット
    • ユーザーがアカウントを作らなくていい・忘れていてもいい
    • サーバー側の負荷が低い（トークンの検証が不要・実装も軽い）
      • ビット数をあげたらサーバー負荷が上がってDDoS耐性が下がることがない
    • ユーザーが招待する人の詳細を知る必要がない（知らせればよい）
    • ステートレスが実現可能（ウェブからメール、QRコードへ）
  • デメリット
    • URLはユーザーがアクセスしやすいもの
      • コピぺされて伝搬、伝搬手段からの漏洩の危険（リファラーなど）
    • 誰からアクセスされたか追跡が不可能（フィンガープリンティングは可能か？）
    • 無効にすると、同じURLを利用している人全員に影響がでる
    • 複数のCapabilities URLsで公開されたものを同時に利用しにくい
      • 複数リソースをまとめて公開する別機能が必要

W3C: Good Practices for Capability URLsに加筆

16 of 29

コンテンツとユーザーのリテンション

最初のユーザー登録・ログインは最初の離脱ポイント

👦< これ面白いよ�　　　わかった見てみる > 👧

💻< はいどうぞ！🏄

　　　面白そうだからサイトに�　　　　登録してみよう > 👧

​

👧< これ面白いよ�　　　　　わかった見てみる > 👦�💻< アカウントが必要です�　　　　　　え、仕方ないな > 👦�💻< SSH公開鍵の登録が必要です�　　　　え、面倒だな・・・ > 👦

💻< MFAのために指紋と電話番号が・・� 　　　（不安になってきた） > 👦

  • 楽しい体験の前の作業は負担でしかない
  • 紹介者の信用貯金が高い・受け手が疲れてない・紹介の仕方がうまいと先まで進んでくれるかもしれない

17 of 29

どのようにアプリケーションを設計すべきか？

  • リソースアクセスの補助手段でなければならない
    • あくまでもログインユーザーのリソース管理があって＋αとして利用する
    • 参照のみ（更新機能は提供しない）
    • 他の方法がないか検討する
      • 今ならOAuth2もある
    • 一次公開→本公開の場合、一時公開URLからリダイレクトさせる（正規URLを参照）
  • URL情報がなるべく漏れないようにする
    • HTTPSを使おう
    • 期限を設ける・ワンタイムアクセスのみ許可するなど
    • ユーザーがキャンセルできるように、あるいは公開範囲ごとにパスが生成できるように
    • Referrerをきちんと制御（Referrer-PolicyヘッダーでURLのパス情報が漏れないように）
    • robots.txtで検索エンジンにキャッシュされないように
    • アドレスバーを書き換えてURLが表示されないようにする

W3C: Good Practices for Capability URLsに加筆

18 of 29

それでもCapabilities URLsを

使いたい人のためのセキュリティ

19 of 29

セキュリティについて考えてみた

  • 今後実装するシステムでこれを利用することがあったとした時に、�「これ！」ときちんと根拠をもって仕様を語れる根拠が欲しかった��しかし�
  • 周りの人に聞いたが、これ！という情報を持っている人はいない
  • OWASPのWebシステム／Webアプリケーションセキュリティ要件書 3.0とかを見ても「予測困難なURLを用いることもできます」と書かれているのみ

20 of 29

セキュリティ強度の考え方

  • 安全は攻撃に必要な計算量で計測
    • 1ビット増えれば2倍強い
    • いわゆる鍵長とは異なる
      • RSA 2048bitは112bit
    • 現実的な時間で解析（攻撃）できてしまうと�安全ではない
    • 時代が進んでコンピュータが速くなると安全の�ボーダーがあがっていく
  • 迂回できないのも大切
    • ローカルに保存した鍵で復号化する方式は鍵が漏れると後からでも復元できる
      • 前方秘匿性

https://www.jpcert.or.jp/present/2009/ciip090220IPA-Yamagishi_sama.pdf より引用

21 of 29

既存のサービスのセキュリティ強度を計算してみる

  • セキュリティの考えを持って既存サービスを評価してみる
  • セキュリティの突破の基準は「攻撃者が欲しい情報の取得」だが、�より厳しい「何かしらの有効なデータの取得」でも見てみる�
  • 例えば、8ビットの空間に16個のデータがある場合
    • 特定のデータの探索だと1/256�→期待値は半分なので7ビットがセキュリティ強度
    • 何かしらのデータの探索だと16/256�→セキュリティ強度は3ビット

22 of 29

Google Photos

  • 全ユーザーが同じ空間に作成する
  • 40文字の英数字なので空間の広さは��
  • 10億人のユーザーが1万枚ずつ写真を投稿したとすると���
  • 今どきの暗号よりも10の20乗倍ぐらいは安全

​

23 of 29

Gist

  • 昔はAnonymousもあったが、今は個人ごとに空間がある
  • 32文字の英字なので空間の広さは��
  • 一人1万ファイル作ると���
  • コンテンツを作ると自動でURLが生成されるし、個人も固定されるし、Google Photosよりも26万倍脆弱といえるがそれでも圧倒的に十分な広さ

24 of 29

Qiitaの限定公開

  • ユーザーごとの空間で、20文字の英数字なので空間の広さは���
  • 一人1000記事ぐらい公開するとなると���
  • gistよりもだいぶ低いが、それでも10の33乗ぐらいのアクセスが必要
  • この発表の元ネタが qiita.com/shibukawa/private 以下にありますよ

25 of 29

ngrok

  • ローカルのサーバーをインターネットに公開してくれるサービス
  • 8文字の英数字なのでだいぶ少なく感じますね��
  • 開発者限定なのでユーザー数は少なそうです。10万人だとすると���
  • 10億回に1回で誰かのサイトにはヒットします
  • ただ、ローカル開発サーバーの寿命（半日もなさそう）からすると十分？

26 of 29

Capabilities URLsとビット数

  • 計算量が増えることと、安全性の相関は低い
    • ネットワーク越しなので、秒間アクセス数を限定すると相手が正解を探索するチャンスを限定できる→通常のビット数よりも相当安全が得られるボーダー低い
      • WAFで保護
      • ホスト当たりの秒間アクセス数制限→ボットネットがある時代なので焼石に水？
      • たまにダミーのレスポンスを返すとか、reCAPTCHAを使うとか�
    • アクセスの時間制限や回数制限も実施可能
      • ビット数を上げるのと同じ効果
      • 何ビット分上がるのに相当するのかの計算方法、だれか知っている人いたら教えて

27 of 29

トークンの生成

  • UUIDv4を使えば122ビット
    • 1万人のユーザーが1000コンテンツを登録しても98ビットぐらいの強度は確保可能
    • 10万人でも90ビット以上なので、簡単に使うにはこれで十分
  • もっと短いトークンを作るには
    • crypto/randとかの暗号用乱数を使って生成し、URLで使える文字列に変換
    • メルセンヌツイスターとかXorshiftとかの疑似乱数はダメ絶対
    • base62だと記号が入らないのでコピペがしやすい
  • 予測可能なトークンは使っちゃダメ
    • xid, snowflake, sonyflakeなどの日時を含んでソート可能なトークンはダメ
    • シーケンシャルなリソースのIDを単にハッシュ化とかはだめ
      • そもそも、元のリソースとは関連しないIDでないと無効化や複数発行できない
    • 欲しい情報の前後に登録されたトークンがわかると、かなりの絞り込みができてしまう

28 of 29

まとめ

  • Capability URLsの特性、用途、欠点など網羅的に理解いただけたと思います
  • おそらく、現時点で世界で詳しい資料！？
    • 僕の知らない情報源とかネタがあったら教えてください！
  • WebAPIのサーバー側の進化の方向性を考えると復権もありえる
    • サーバーレス（ステートレス）
    • BaaSでより、サーバー実装が少なくなる・なくなると、権限確認ロジックの置き場が減る
    • ユーザーのレスポンス最大化のためにCDNにコンテンツを置こう！
      • 権限確認ロジックの置き場が（あまり）ない
      • JSやWebAssemblyなどでロジックをエッジで動かせるCDNサービスは増えているが
  • 安全性の計算の一助になれば
    • 例「宝くじ1等が4回連続で当たる確率のさらに1/10万です」

29 of 29

WebAPIは楽しい

  • 新しい機能を理解するときには幅広い知識が必要
    • 知れば知るほど、選択肢が広がっていく
  • Capabilities URLsを使うことはなくても、周辺知識を深掘ると、�WebAPIに関する知識が広がるきっかけになる
  • Capabilities URLsはRFC上では単なるGETアクセス
    • Real World HTTPは今後もこのようなリアルな応用例を集めてワクワクする第3版を作りたい