例のサイゼイヤをIPAに通報した
まず、サイゼリヤの「安さを徹底追求する」企業努力にはとても感謝しています。
だからこそ、この高校生(自称)の行為は、醤油ぺろぺろテロ行為と何ら変わりがないことを言いたいです。
彼がやったことは「やりすぎ」「法に触れる可能性」
彼がもし、本当にエンジニアとしてデベロッパーとしてクリエイターとして、将来を担っていきたいのであれば、サイゼリアのコードを解析した結果、容易に非公開APIを通じて、サイゼリヤのサーバーに到達する可能性があることを、まずIPAに報告すべきでした。
本件の問題は、 セキュリティホールを発見したことではなく、その後、その脆弱性を利用したことです。その時点でアウトですから、それをさらにOSSとして公開したことは、頂き女子りりちゃん事件(幇助)と変わりません。
IPAの「法令に抵触する可能性を危惧しております」報告
IPAに相談・報告すると、次のような返信をもらうことがあります。
本件の脆弱性について、
本来ウェブサイトで提供している機能以外の手段で、
API を用いて送信を行った結果、店舗側のサーバにアクセスされたものと認識しております。
IPA は法律の専門家ではないため確定的な判断をするものではありませんが、
法令に抵触する可能性を危惧しております。
「情報セキュリティ早期警戒パートナーシップガイドライン」でも
「発見者が心得ておくべき法的な論点」をご案内しております。
ご留意くださいますようお願いいたします。
情報セキュリティ早期警戒パートナーシップガイドライン
https://www.ipa.go.jp/security/guide/vuln/ug65p90000019by0-att/partnership_guideline.pdf
ガイドラインには「セキュリティホールを見つけても、ここまでにしておけ。それ以上は法に触れる」という指針が書かれています。
ガイドライン:付録3 法的な論点について
付録3 法的な論点について
1 発見者が心得ておくべき法的な論点
発見者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
1-1.脆弱性関連情報の発見に際しての法的な問題
(1)関係する行為と法令の関係
a) ネットワークを用いた不正
- 例えば、脆弱性関連情報を利用して、アクセス制御機能を回避し、インターネット等を介してシステムにアクセスした場合には、不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)に抵触します。
- 例えば、管理者の了解無く、他人のパスワードを取得し、それを用いて権限なしでシステムにアクセスした場合には、不正アクセス禁止法に抵触します。
- 故意にサーバの機能や性能の異常を来たそうとして何らかの行為をなし、コンピュータの性能を低下させたりした場合、刑法上の偽計(もしくは威力)業務妨害罪に抵触する可能性があります。さらに、その妨害の程度によっては、刑法の電子計算機損壊等業務妨害罪にも抵触すると解される可能性があります。
b) 暗号化されている無線通信の復号化
- 暗号化されている無線通信を傍受し復号する行為(無線 LAN の WEPキーを解読して通信内容を復号すること)は、電波法109条の2に触れる可能性があります。
(2)不正アクセス禁止法に抵触しないと推察される行為の例
脆弱性の発見に最も関係が深い不正アクセス禁止法に対しては慎重な扱いが求められます。といっても脆弱性を発見する際に、必ずしも不正アクセス禁止法に抵触するとは限りません。以下に、不正アクセス禁止法に抵触しないと推察される行為の例を挙げます。
- ウェブアプリケーションの利用権者が、正規の手順でログインする等して通常のアクセスをした際に、ブラウザとサーバとの通信の内容を観察したところ、それだけで脆弱性の存在を推定できた場合。
- ウェブページのデータ入力欄にHTMLのタグを含む文字列を入力したところ、入力した文字列がそのまま表示された。この段階ではアクセス制御機能の制限を回避するに至らなかったが、悪意ある者に別の文字列を入力されれば、このサイトにセキュリティ上の問題が引き起こされかねないと予想できた場合。
- アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察されるURL中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。(ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。)
(3)IPAの対応と発見者の法的責任
IPA は、脆弱性関連情報の入手方法に関して関知しません。ただし、違法な手段で入手されたことが明白な脆弱性関連情報に関しては、受け付けないことがあります。
また、IPAが脆弱性関連情報を受け付けた場合でも、IPAは脆弱性関連情報の入手手段に関して合法であると判断したわけではありません。さらに、IPAが脆弱性関連情報を受け付けた場合、発見者の脆弱性関連情報の発見に係る法的責任が免責されるわけではありません。
1-2.脆弱性関連情報の管理および開示に際しての法的な問題
発見者の脆弱性関連情報の管理および開示に際しては、以下の法的な問題への注意が必要です。
- 脆弱性についての調査・報告は、その率直な交換により、ソフトウエアやウェブアプリケーションシステムのセキュリティが結果として強化され・向上するという側面があります。
- しかしながら、その情報については、悪用というデメリットがあるので、その点についての十分な配慮がなされるべきであり、その一つの方向性を提唱するのが、このガイドラインといえます。
- また、情報自体そのような性格をもつので、発見者についても脆弱性関連情報の管理および開示について真摯な態度が必要とされます。
- そのような真摯な態度を保つ限り脆弱性関連情報についての調査・報告は、社会的に有用なものと考えられます。
しかしながら、管理および開示について真摯な態度を欠く場合については、上述の限りではありません。そのような真摯な態度を欠く場合の具体的な例として以下があります。
a) 脆弱性関連情報の公表は、その情報の内容が真実と異なることを知っていた場合、あるいは、真実である場合であっても、特定人の名誉を毀損する意図で公表がなされ、かつ、公共の利益と無関係である場合には、刑法の名誉毀損罪に触れる可能性があります。
b) 特定人の信用を毀損する意図で事実と異なる脆弱性関連情報を、事実と異なると認識して公表がなされる場合には、刑法の信用毀損罪に触れる可能性があります。
c) 通常人に求められる程度の相当の注意をもって調査・検証したりしたのではなしに脆弱性関連情報であるとして公表し、かつ、脆弱性関連情報の開示に起因して損害が発生した場合、損害賠償責任等の民事責任を追及される可能性があります。
2 製品開発者が心得ておくべき法的な論点
製品開発者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
(1) ソフトウエアの提供行為についていえば、セキュリティに問題が生じず、日頃の運用で安心して使えるというレベルのソフトウエアを提供することが、法律上、債務の本旨に従った履行(民法415条)として求められています。
(2) もし、提供したソフトウエアにおいて、設計上の問題、プログラミング上の問題、運用上の問題の如何を問わず、社会通念上、安心して使えるというレベルにいたらない箇所が生じている場合には、その点に対してサポートの約定の趣旨に従い対策をすべきことが求められています。
(3) もっともその対策方法の選択については、種々の考慮が必要になります。
この対策方法の選択に際しては、以下の点を論点として意識する必要があります。
(a) 上記の対策方法の選択について、状況に応じて債務不履行責任(民法415条)、不法行為責任(民法709条)の対象となる可能性があります。
(b) 提供の際の契約で、これを免除する場合については、消費者契約法の適用がある場合には、責任の全部免除が認められない場合がありえます。
(c) 製造物責任法上の問題として、現時点において、ソフトウエアそれ自体については製造物責任が問われないと一般に解釈されていますが、電気機器や電子部品その他の工業製品等に組み込まれたソフトウエアは動産である製造物ですので製造物責任法に定める責任規定の適用がなされることがありえます。
3 ウェブサイト運営者が心得ておくべき法的な論点
ウェブサイト運営者が心得ておくべき法的な問題に関する法律専門家の見解を述べます。
- ウェブサイト運営者と、ウェブサイト利用者との間においては、そのウェブアプリケーションの利用に際して、一定の契約関係にはいると考えられます。そして、ウェブサイト利用者が、そのサイトに一定の個人情報等をゆだねる場合には、ウェブサイト運営者は、そのサイトの利用契約に付随した義務として一定レベルのセキュリティ維持を果たすべき義務を負担していると考えることができます。
- 各サイトに「プライバシポリシ」等が記載されている場合には、その内容をも前提にウェブサイト利用者とウェブサイト運営者は、契約関係にはいると考えられます。
- この場合、ウェブサイト運営者において、上記のセキュリティ維持等について過失がある場合、その過失による損害賠償の責めを免れるような規定は、消費者契約法上、全部免責の規定については無効となることがあります。
サイゼリヤ側のセキュリティ設計上の問題
あのコードが「動いてしまう」原因
サイゼリヤの注文システムは「ブラウザでQRを読んだ客だけが使う」という前提で設計されている。しかし実際には ブラウザが行う制約をすべてサーバー側で再検証していない。これがこのリポジトリが成立する根本原因。
- サイゼリヤ自体の問題
| 問題 | 影響 | 根本原因 |
|---|---|---|
| ■■■■■ の無検証 | ■■■■■■■■■■■■■■■■■■■■■■■■■ | ■■■■■ をブラウザ任せ |
| ■■■■■に認証なし | ■■■■■の業務妨害が可能 | ■■■■■前提のAPI設計 |
| ■■■■■がほぼ認証なし | ■■■■■の列挙・スクレイピング | ■■■■■検証が不徹底 |
| ■■■■■ = ■■■■■権限の全て | ■■■■■で■■■■■が可能 | ■■■■■の技術的証明なし |
| ■■■■■APIと■■■■■APIが混在 | 攻撃対象が広い | 一貫した■■■■■モデルの欠如 |
サイゼリヤ側の問題有無
「つまり、サイゼリヤの注文フォームには、セキュリティ上の問題があるということか?」
→「YES」
だからといって、このセキュリティ脆弱性を利用して良いことにはなりません。
正しい手順はIPAに通報。
本件の脆弱性関連情報届出制度(ウェブアプリ対象)番号
IPAへの届出は 脆弱性関連情報届出制度(ウェブアプリ対象)で、番号体系は以下の通りです。
- 該当するCWE番号
| 脆弱性 | CWE番号 | 名称 |
|---|---|---|
| ■■■■■ | CWE-■■■■■ | ■■■■■ https://jvndb.jvn.jp/ja/cwe/CWE-■■■■■.html |
| ■■■■■ | CWE-■■■■■ | ■■■■■ https://jvndb.jvn.jp/ja/cwe/CWE-■■■■■.html |
| ■■■■■ | CWE-■■■■■ | ■■■■■ https://jvndb.jvn.jp/ja/cwe/CWE-■■■■■.html |
| ■■■■■ | CWE-■■■■■ | ■■■■■ https://jvndb.jvn.jp/ja/cwe/CWE-■■■■■.html |
主訴は CWE-■■■■■ が最も当てはまる(■■■■■)。
IPAへの届出内容
脆弱性を確認したウェブアプリケーション等に関する情報
脆弱性を確認したウェブサイトのURL
https://■■■■■ (サイゼリヤの注文フォーム)
脆弱性の確認日
2026年5月5日
脆弱性の種類
その他(認証・認可の不備)
CWEとの関連付け
-
CWE-■■■■■: ■■■■■。
-
CWE-■■■■■: ■■■■■。
-
CWE-■■■■■: ■■■■■。
-
CWE-■■■■■: ■■■■■。
脆弱性の発見に至った経緯
【発見のきっかけ】
X(旧Twitter)上で、サイゼリヤの注文システムAPIを利用したOSSが公開されているという投稿を目にした。その投稿をきっかけに公開されたソースコードを調査したところ、サイゼリヤのAPIに認証不備が存在することを確認した。
【具体的な調査手順】
- X投稿( https://x.com/nakasyou0/status/2050830565117759656 )を確認した。
- 関連するOSSリポジトリ( https://github.com/■■■■■/■■■■■ )のソースコードを読んだ。
-
■■■■■.tsの■■■■■を確認したところ、■■■■■が店舗ID(■■■■■)・テーブル番号(■■■■■)のみで、■■■■■や■■■■■が含まれていないことを確認した。 -
■■■■■.tsを確認したところ、■■■■■・■■■■■ヘッダーを■■■■■に偽装するだけで、■■■■■(■■■■■.php)へのアクセスが通過し、■■■■■・■■■■■コード(0000〜9999)を総当たりでスクレイピングできることを確認した。サーバー側で■■■■■の検証が行われていないため、■■■■■以外からの任意の■■■■■によるアクセスが可能な状態になっている。
【発見した内容】
■■■■■(■■■■■.php)は、■■■■■かどうかを検証する仕組みがなく、インターネット経由で誰でも任意の■■■■■・■■■■■への■■■■■を実行できる状態にある。
以上の経緯から、CWE-■■■■■(■■■■■)、CWE-■■■■■(■■■■■)に該当する脆弱性が存在すると判断した。
脆弱性であると判断した理由
-
観測した事実:
■■■■■.phpへのPOSTリクエストに必要なパラメータは■■■■■(■■■■■)・■■■■■(■■■■■)・■■■■■のみ。■■■■■・■■■■■・■■■■■は一切要求されない。■■■■■と■■■■■はいずれも小さい整数値で、推測可能な情報である。 -
本来あるべき挙動: ■■■■■のような物理的アクションを引き起こすAPIは、有効な■■■■■または■■■■■により、正当な■■■■■であることをサーバー側で検証すべきである。
-
差分: サーバー側で■■■■■が行われていないため、任意の■■■■■から直接■■■■■状態になっている。
-
そのため、本APIはCWE-■■■■■「■■■■■」、CWE-■■■■■「■■■■■」に該当すると判断した。
脆弱性により発生しうる脅威
可用性への脅威(主要):
■■■■■と■■■■■を列挙することで、全国約1,500店舗の■■■■■に対して■■■■■を行う業務妨害が技術的に可能である。
機密性への脅威:
■■■■■・■■■■■ヘッダーを■■■■■するだけで■■■■■(■■■■■.php)のバリデーションを通過できる。■■■■■・■■■■■の総当たりにより、■■■■■・■■■■■の無制限なスクレイピングが可能である。実際にこの方法で取得されたとみられるデータ(3,252件)が上記OSSリポジトリ内に含まれている。
完全性への脅威:
■■■■■送信には■■■■■が要求されており、現時点では直接的な注文改ざんは確認できていない。
検証コードの有無
あり(補足情報として)。
本脆弱性を発見するきっかけとなったOSSが、以下のとおり公開されている。
このリポジトリは本脆弱性を突く動作が可能なコードを含んでおり、実害リスクの高さを示す根拠となる。
なお、当該コードを用いて実際に攻撃を行ったわけではない。
脆弱性が再現した証跡
上記OSSの作者によるX(旧Twitter)動画投稿にて、システムが動作することが確認できる。
手元のスクリーンショット・ログは現時点では未取得。
ログファイルの有無
なし(現時点では未取得)。
ウェブサイト連絡窓口
(サイゼリヤ株式会社 公式お問い合わせ)
IPA以外の組織への届出について
サイゼリヤ株式会社への直接連絡は現時点では未実施。
なお、本脆弱性を突くOSSがGitHubおよびX上ですでに公開されており(上記参照)、攻撃コードが誰でも入手できる状態にある。迅速な対応を要請する。
深刻度と影響範囲
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
基本値: 5.3(Medium)
利用者数の根拠:
サイゼリヤは国内約1,500店舗(2025年時点)。全来店客が潜在的な影響範囲。
重要インフラへの影響:
飲食業は重要インフラ指定対象外のため、該当しない。
攻撃コードの公表の有無:
あり。GitHubリポジトリおよびX動画投稿として公開済み。
攻撃発生の有無:
現時点では未確認。ただし攻撃コードが公開されているため、潜在的リスクは高い。
(IPAからの進捗状況連絡は、こちらに追記していきます)
第三者への情報公開について
IPA以外の第三者への情報公開について質問がありましたが、「正当な理由により開示が必要である場合」のフローがありますので、詳しくはIPAに メール で聞いて、そのフローに従えば問題ありません。本記事も然りです。
また、第三者への報告であれば、以下の専用フォームから入力します。
はてなブックマークのコメントはこちらです。
Discussion
コメント・議論は、すでに180件以上もついている、はてブのほうにどうぞ。
Zenn運営側のコメント削除・非表示については私に聞かれても困ります。
あと、必死に無意味なコメントを連投する人がいますが、何を焦っているのでしょうか?
ブスですよ🌱
Zenn利用規約違反と思われるユーザー1名(1人で複数アカウント)を、違反報告しました。
例の高校生関係者または本人だと思いますが、そのユーザーのせいで、実質的にコメント欄を閉鎖せざるを得ないという結果になりました。残念です。せっかくのDiscussionの場を潰されたのですから、開示請求して損害賠償を請求したいくらいの気分です。
あと、この nakasyou というアカウント、以前も炎上して見かけましたが、今回は2回目です。前回も今回と類似です。学校に納入されてるシステムを解析、自身の力で突破できるわけもなく、調べた内容をSNSに公開して、学校や大人に文句、民意を得て、自分の理想を通すという手法なのですから、何のテクニカルな話でもなく、たんなる業務妨害です。
この高校生がIPAと関わりが深い未踏ジュニアというのですから(自称)、
そもそも最近のIPA、違反業者との付き合いがバレ、国との入札が禁止になったりして信用を落としています。きちんとやってください。
ちなみに本記事のIPA通報もかなり妥協した対応です。この高校生の情報は多く出ているのですから、気をつけましょう。他の手段(民事裁判、刑事告訴、学校通報等)もあることを理解してください。私がやらなくても、誰かがやるかもしれないということです。
・悪質なユーザー1名(1人で複数アカウント)について
きちんと皆さんに謝ってください。そうしたらコメント欄を再開します。
🌱
サイゼ側は意図してあの実装にしてるので脆弱性ではないのでは...
意図というか「予算が無いから」でしょうね。
今の低価格を維持するために。
私はCLIを公開したこと自体には否定的ですが、この記事には違和感を覚えました。
そもそも当該CLIは公式クライアントの挙動を模倣した実装で、脆弱性を突いている訳ではないはずです。
そのうえ、仮にこれが脆弱性に該当すると考えているなら、なぜZennに投稿したのですか?
修正されてない脆弱性を公開することは、それこそ技術者倫理に反しているように思えます。
ありがとうございます。
ただ、下の2行の意味についてですが、
投稿した意味をDiscussionする意図はここには無いと解しているのと、
技術者倫理については、私の記事では一切触れていません。
これは客にユーザー登録という手間をかけさせずにモバイルオーダーを実現させるための、意図された設計でしょう。マジックリンクと呼ばれると思いますが、Zoomなどの招待URLとか、パスワードのリセットメールとか、実例は山ほどありますよね?
仮に他人の注文のセッションを別の手段で獲得できて、勝手にオーダーができたらそれは脆弱性と言えるでしょうけど、これはそうではないでしょう。
安易にこういうことすると、元の開発者さんやIPAさんに迷惑がかかるのでやめたほうがいいと思います。
引用部分で指摘しているのは「認証方式の問題」ではなく、「サーバー側でのビジネスロジックの再検証がない」という点です。マジックリンクとは別の問題だと思いますが、違いますか?
本当に脆弱性だと思ってるなら詳細を公開するな。
ふざけてやってるなら、IPAの業務妨害をするな。
いずれにしても、WATab2000がやっていることは一線を超えている
言い過ぎではないですか?傷つきました。謝ってください。
言い過ぎていません。
あなたが不適切なことをしているので、社会の秩序のために淡々と指摘しているだけです。謝る気はありません。
あなたがやっていることは言論の自由ではありません。
あなたが本件を本当に脆弱性だと考えているのなら、それを公開するという行為は、その脆弱性を抱えている事業者に不必要に負担を強い、業務を妨害しているということです。
あなたが本件をふざけて行っているのだとしたら、IPAの業務を妨害しているということなので、納税者の1人としてあなたを批判します。
あなたは、また私を傷つけました。
しかも、勝手に傷ついたお前が悪いって趣旨ですよね。DVですか?
謝ってください。
ん〜なんだか違和感ありますね
CVE-287に関しては仕様じゃないですかね()
脆弱性があったとしても、修正されてない脆弱性を公開するのはまずいんじゃないですかねぇ..
Zennに投稿なんてのは、思いっきり🪃な気がしますけど
ただ叩きたいだけじゃないんですか?
IPA大変そうですね
中3より
100歩譲っても全部YESではないでしょう。
トレードオフ、もっと突き詰めて言うなら「予算が無いから」でしょうね。
今の低価格を維持するために。
あと、Discussionの場なんだから、憶測でものを言うようなことを書かないほうが良いと思うよ。
嫌われるよ。
という返信をもらってるなら、なおさら本記事で触れている内容は公開するべきではないでしょう。
また技術的な内容についても不正確で、Originやリファラを検証したところで両リクエストヘッダーは偽装可能です。記事中で、「Originを偽装」と「Originを検証していない」の2つが同時に出ていますが、偽装できる時点で検証の意味はないでしょう。
そもそも、QRコード注文システムで「本当に席に居るかどうか」を検証している実装自体、存在するのでしょうかね? QRが複数人で使い回せて、いつでも読み込んで追加注文ができるという前提で、具体的にどう工夫すれば「本当に席に居るかどうか」が判別できるのか、気になりました。
読む価値のない記事
悪意を持った行為をしたわけでもない他者をテロ行為呼ばわり。
なにが「醤油ぺろぺろと同じ」だ、物事の善悪すら判断できないのか。
世の中は白と黒の2色のみじゃないと気が済まないのか。
話にならない
コメントできるだけ返信していますが、
すみません、関わりたくないタイプの人です。
ごめんなさい。
なんと言うか、ただの報告というより叩くのが目的で書かれた記事に見える
コメントも全て非表示にしているし
回答はしてるよ。
こう書いているのに、それを嬉々として公開しているのはどうなんでしょうか。脆弱性報告だと思って報告したのならば適切な修正が入るまで待つべきだと思うのですが...
問題ない状態で公開したつもりですが、
念のため、■■■を増やしました。
阿鼻叫喚・賛否両論ですが個人的にはこういう活動も必要だと思っています。評価します。
放置していたら、今はボヤ程度でもいずれエンジニアどころか日本の情報リテラシー荒れ放題ですよ。。
何がそんなにみなさんの気に食わないのかわかりませんが、そもそも…
この"通報"ってそんなに悪いことなんでしょうか?
当初から大勢がXで書いてましたが、「試みは面白いが大ごとになるからやめておけ」というのが良識あるエンジニアの総意でしたよね。
すぐに企業が動けない以上、IPAのこの制度を利用するのは当然の帰結ですし、それで企業にペナルティなどが発生するわけでもありません。
ルールに従って然るべき措置を講じただけ。
何を騒いでいるのか…これを騒ぎ立てるなら、元のリポジトリをそれこそ糾弾すべきです。
夜遅くに失礼しました。
法に触れるかは私には分かりませんが、良い試みと思います!✨
当記事による仕様公開が脆弱性拡散に繋がるという指摘がありますが、それなら件のリポジトリにも同じことが当てはまりますから、通報自体には一定の妥当性はあるんだろうと思いましたー
それを私に返信する意味がよく分からないのですが…
「通報自体が問題なのではありません。」と言われると、まるで私が「通報自体が問題だと誰かが言っている」と思っているかのようですが、そう思っていないし書いてもいないつもりです。
脆弱性拡散に繋がるとの指摘を私も読んでることは私の当初のコメントから分かるはずですし、私はその指摘を否定もしておりません。ですので「この記事の問題点を理解されていない」と言われるとムッとしてしまいます😥
私は十分に理解してるつもりですよ。恣意的に批判を書いてないだけで。
私は通報自体について良い試みだと書きました。記事自体についてではありません。(あまり関係ありませんが、既にTwitterの方でもリプライを送りましたので、このサイゼCLIの件への私のリアクションというのも見る気になれば見れます。この記事を良いと思ってるどころか、寧ろ小ばかにしてると見られても良いくらいのものですがね…)
なので、私が話していない事を返信されてきたので、それを私に返信する意味がよく分からないと書きました。
素晴らしい、脆弱性を検証されたのですね。
ですが失礼ながら本記事には、ご自身で検証された脆弱性についての記載がなく、こちらでも再現できません。
お手数ですが、再現するため手順など公開していただけますか?
再現できないように伏せろ、と指摘した人に、指摘したらどうでしょう。
他のコメントも読んでみてもいいかもしれませんね。