2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tekka

セキュリティ事故分析「Skillable SCORM 起動問題」と非保持型権限委譲

2
Last updated at Posted at 2026-07-21

0. はじめに

この記事は、セキュリティ関連のニュースを取り上げ、それに対して非保持型権限委譲をどのように適用できるか考察する技術記事です。

非保持型権限委譲については、以下の記事を参照してください。

1. SkillableのSCORM lab起動問題

この記事では、2026年7月12日に公開された、SkillableのSCORM lab起動処理において、SCORMトークンとユーザーIDが結び付けられていない問題について、紹介したいと思います。

この脆弱性は、現時点で実被害が確認されていないものの、CVE-2026-56877として公開されています。1

脆弱性の内容を要約すると、認可トークンの扱いが不適切であり、LMSサーバーのログイン制御が外部サーバーに正しく伝搬しなかった、という事のようです。

本稿では、Skillableの公開情報、研究者側のadvisory、SCORMの一般的な性質を整理し、そのうえで非保持型権限委譲をどのように適用できるかを示します。

2. SCORMとは何か

SCORMは、LMS（Learning Management System、いわゆる学習管理システム）にアップロードする教材パッケージの、eラーニング規格です。

教材ベンダーがHTML、JavaScript、画像、動画、設定ファイルなどを含むSCORMパッケージを作成し、それをLMSへアップロードします。

受講者がLMSにログインして教材を開くと、教材がブラウザ内で動作し、JavaScript APIを通じて進捗、スコア、完了状態などをLMSへ返却します。
2

3. Skillable SCORM lab起動処理の構造

SkillableのSCORM lab 起動処理は、次のような手順で進みます。

受講者
  ↓ LMSにログイン
LMS
  ↓ SCORM教材を表示
ブラウザ
  ↓ SkillableのSCORM 起動エンドポイントへアクセス
  ↓
外部サーバーのVM / 演習環境を起動

この外部サーバーは、Skillableが提供する正規の演習環境のVMです。

このようなリソース消費を伴う操作は、ユーザーである受講者に紐づいているべきです。

しかし、外部サーバーは、渡された認可トークンは検証をするものの、ユーザーIDは検証せずに信用し、VMを起動していました。

そのため、悪意のあるユーザーが、任意のユーザーIDに差し替えて外部サーバーにリクエストを送信することで、

  • 他ユーザーのリソースを消費させる
  • ユーザーに紐づかないリソースを消費させる

ことができました。

4. 研究者側の主張

研究者側のアドバイザリでは、SkillableのSCORM 起動エンドポイントがSCORM 起動トークンを検証して許可する一方で、
ユーザーリミット制限をブラウザが供給する ユーザーIDクエリパラメータ に対して評価していた、と説明されています。

起動トークンとユーザーIDは相互検証されていませんでした。34

研究者側は、同じSCORM 起動トークンのまま ユーザーIDを変更すると、新しい labインスタンスID が返り、別インスタンスが配備されたと報告しています。
さらに、同意した同僚のユーザーIDを用いたクロスユーザーテストでは、同僚側が対象labを起動できなくなるクロスユーザーサービス拒否を確認したとしています。4

5. Skillable側の主張

Skillableは、本件をSkillable固有の脆弱性ではなく、SCORM標準の構造的な限界と説明しています。

LMSが各ユーザーを認証し、何を起動できるかを管理するとしています。
一方、Skillableはユーザー情報もLMSへの接続も持たないため、渡されたユーザー識別情報が本物かを検証できない、という言い分です。

Skillableは、この構造により次のリスクがあることも認めています。

  • ユーザーリミット制限や同時実行制御が回避され得る
  • 他ユーザーのリソース消費
  • ユーザーに紐づかないリソース消費

そのうえで、SkillableはSCORM lab起動処理を推奨せず、APIベースまたはLTI 1.3への移行を推奨しています。

6. 争点の整理

研究者側とSkillable側、双方の言い分は、次の事実について、ほぼ一致しています。

SCORM lab起動処理では、ユーザーの検証ができない。
その結果、ユーザーの権限制御が崩れ得る。

しかしながらSkillableは、脆弱性の指摘に対し、
SCORMの限界であるから他の方式を推奨する、と述べるに留まっています。

私見ながら、この主張は苦しいですね。
ユーザーIDだけで、ユーザーを検証できないのは自明なことです。
したがって、ブラウザという改ざん可能な環境からユーザーIDを取得し、そのまま信頼してリソース消費を許可する設計は、認可設計の不備といえるでしょう。

また、問題の脆弱性は今も修正されないままです。
そのため、他ユーザーやSkillableシステムのリソース消費攻撃が、引き続き可能な状態です。

7. 非保持型権限委譲の適用方針

ここまで、Skillable / SCORMの脆弱性を見てきました。
この問題に対して、非保持型権限委譲を適用すると、どのように問題が解消できるかを確認します。

非保持型権限委譲を適用する場合の目標は次のとおりです。

  1. ブラウザに認可情報を決めさせない
  2. ブラウザから渡されたユーザーIDを信用しない
  3. LMSログイン済みセッションと外部サーバー暗号鍵をLMSサーバー対応関係として結び付ける
  4. 外部サーバーには、暗号化済み命令だけを渡す
  5. 外部サーバーやブラウザにLMS認証情報を渡さない

前提として、外部サーバーだけでなくLMSサーバーの改修も必要になります。

8. 適用案: LMS主導の暗号化起動処理

8.1 前提

事前に、LMSと外部サーバーの間で次を登録しておきます。

LMS側の登録情報:

外部サーバー公開鍵
LMS秘密鍵

外部サーバー側の登録情報:

外部サーバー秘密鍵
LMS公開鍵

ブラウザが渡した公開鍵をLMSが自動的に信用すると、攻撃者が公開鍵を差し込めます。
そのため、外部サーバー公開鍵は、LMS側で事前登録された信頼済み設定から選ぶ必要があります。

8.2 フロー

1. 受講者がLMSにログインしている

2. 受講者がLMS上で外部サーバーVM起動を選ぶ

3. LMSが共通鍵を生成し、ログイン済みセッションと対応付けて保持する
   （この対応関係が、後の権限の成立根拠になる）

4. LMSが登録済み外部サーバー公開鍵で共通鍵を暗号化する

5. ブラウザが暗号化済み共通鍵を外部サーバーへ中継する

6. 外部サーバーが秘密鍵で共通鍵を復号する

7. LMSと外部サーバーの間で、共通鍵による暗号化通信が確立される

8. LMSが、対応付けたセッションからユーザーIDを確定し、起動コマンドを作る
   （ユーザーIDはブラウザからではなく、LMS内のセッションから取得する）

9. LMSが起動コマンドを共通鍵で暗号化する

10. ブラウザが暗号化済みコマンドを外部サーバーへ中継する

11. 外部サーバーが共通鍵でコマンドを復号し、VMを起動する

この方式では、ブラウザは情報の配達人で、起動権限に関与しません。
暗号化命令を改ざんできず、外部サーバーを差し替えることもできません。

ここで重要なのは、ユーザーIDがブラウザからではなく、LMS内で共通鍵に結び付いたセッションから確定されることです。
権限の本体は、ブラウザが運ぶ値ではなく、LMSサーバー内部にある「セッションと共通鍵の対応関係」そのものになります。
ブラウザがユーザーIDを書き換えても、そもそも認可判断に使われないため、意味を持ちません。

9. この方式で防げること

この方式で防げることは次の通りです。

  • ブラウザから渡されるユーザーIDの改ざん
  • 認可トークンとユーザーIDのバインド欠落
  • 他ユーザーのリソース消費
  • ユーザーリミット制限の回避
  • 不明な外部サーバーへの鍵共有
  • 起動コマンドの改ざん
  • 別外部サーバーへのコマンド流用

これらの効果は、ブラウザが権限に関与せず、中継路に徹する構成から発生します。

さらに、権限がLMSサーバー内の対応関係として存在するため、LMSでログアウトやセッション失効が起きた瞬間に、発行済みの起動コマンドも無効になります。
トークンや証明書を配る方式のように、発行済みのものが期限切れまで生き残ることがありません。

10. この方式でも防げないこと

この方式で防げないことは次の通りです。

  • LMSアカウント自体の乗っ取り
  • LMS側の設定ミス
  • 外部サーバー自体の侵害
  • SCORMパッケージ内の悪性JavaScriptによるブラウザ上の情報収集
  • VM起動後のVM内部の脆弱性
  • ユーザーのフィッシングや誤承認

非保持型権限委譲は、ブラウザを安全な認証基盤に変えるものでありません。
それらを信頼せずに、認可関係をサーバーで成立させるための構造です。

参考資料

  1. CVE-2026-56877
    https://www.cve.org/CVERecord?id=CVE-2026-56877 ↩

  2. Skillable Docs, "SCORM Lab Packages."
    https://docs.skillable.com/docs/scorm ↩

  3. oss-sec mailing list, “Skillable SCORM launch: userId parameter not validated against session token allows allocation bypass and cross-user DoS,” 2026-07-12.
    https://seclists.org/oss-sec/2026/q3/120 ↩

  4. Greg Durys, “Skillable SCORM launch: userId parameter not validated against launch token allows allocation bypass and cross-user DoS,” GitHub security-advisories repository.
    https://github.com/GregDurys/security-advisories/tree/main/skillable ↩ ↩2

2
1
2

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
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?