- Illinois FOIAの広範な公開原則が公共機関のデータベーススキーマを前に試され、Chicago CANVASの駐車違反チケットデータベースへの請求が訴訟と立法議論につながった
- FOIAは既存情報の公開を強く保障する一方、新しい記録の作成を強制することはできないため、データがアプリケーション内にあるほど、どのクエリを求めるべきかを示すスキーマが重要になる
- Chicagoは、CANVASスキーマはセキュリティを脅かすと反論し、裁判の核心はスキーマ公開がSQL Injection攻撃を実際に可能にする、または容易にするかどうかだった
- 第一審と控訴審では公開側が勝訴したが、Illinois Supreme Courtはfile layoutをそれ自体で適用除外の対象とみなし、SQL schemaもこれに該当すると判断した
- 現在、Illinoisの公共機関はデータベーススキーマの公開を拒否できる。SB0226は、請求者が具体的なデータベースクエリを求められるよう、データベース構造の説明提供を義務付けようとしている
Illinois FOIAがデータベースを前に直面した問題
- Illinois FOIAは、公共機関が収集した情報を原則として公共財産として扱い、例外は限定的である
- 請求者は通常、費用を請求されない
- 公共機関は請求数を簡単には制限できない
- 回答期限は基本5日で、書面による延長請求があればさらに5日を追加できる
- 不当な拒否を相手取って訴訟を起こした場合、弁護士費用の回収が可能である
- 大きな制約は、FOIAによって公共機関に新しい記録の作成を強制できない点である
- 望むレポートがすでに存在するなら請求できる
- 存在しない場合は、元データを請求して自分で組み立てる必要がある
- 公共機関の情報が、ファイルキャビネット、共有ドライブ、Word文書ではなく、専用アプリケーションとデータベースにより多く格納されるようになり、スキーマの価値が高まっている
- データベーススキーマは、複数のテーブル名と各テーブルのカラム名を含む構造である
- 記事では、複数のタブがあるExcelファイルに例えている
- 各タブの名前と各タブのヘッダー行がスキーマに相当する
Matt ChapmanによるCANVASスキーマ請求
- Matt Chapmanは、大規模なFOIA請求を活用してデータジャーナリズムを行うcivic hackerとして紹介されている
- Chicagoの駐車違反チケットデータに取り組む過程で、CANVASというシステムが明らかになった
- CANVASは、Chicagoのすべての駐車違反チケットデータを格納する中央リポジトリである
- Matt Chapmanは、CANVASデータベースに何が入っているのかを把握するため、FOIAでスキーマを請求した
- Chicagoは、Illinois FOIAの自動化データ処理に関する例外規定を根拠に請求を拒否した
- 当該規定には、ソフトウェア、運用プロトコル、プログラム概要、file layouts、ソース一覧、モジュール、ユーザーガイド、論理・物理設計文書、職員マニュアルなどが含まれる
- 公開時にシステムやデータのセキュリティを脅かし得る情報も例外として列挙されている
- ChicagoはMatt Chapmanを「hacker」と呼び、CANVASスキーマが悪用されれば市にとって危険になり得ると主張した
法廷での核心的な技術争点: SQL Injection
- 裁判の中心的な問いは、CANVASスキーマの公開がSQL Injection攻撃を可能にするかどうかだった
- SQLは多くのプログラムがデータベースとやり取りする際に使う言語であり、SQL InjectionはSQLを使うプログラムで発生し得るセキュリティ脆弱性である
- SQL Injectionは、アプリケーションコード内のSQLクエリテンプレートにユーザー入力が不適切に差し込まれると発生する
- 例として、名前を引用符で囲むクエリで、
Bob O’Connorのように引用符を含む入力がデータベースの解釈を混乱させる可能性がある
- 攻撃者はこうした入力箇所を利用して、残りの入力をコードのように実行させることができる
- ChicagoのCISOであるBruce Coffingは、スキーマ公開が攻撃者に3つの助けを与えると主張した
- 脆弱性を見つけられるようにする
- 脆弱性の探索をより隠密にできるようにする
- 攻撃する価値の高いアプリケーションを選べるようにする
- 反対論は、スキーマはSQL Injection脆弱性を見つける場所ではないという点に集中した
- SQL Injection脆弱性はデータベーススキーマではなく、アプリケーションソースコードのSQLクエリテンプレートで見つけるものだ
- 請求対象はソースコードではなく、テーブルのヘッダー行に近いスキーマだった
- 攻撃者はSQL Injectionによってスキーマを取得でき、スキーマは攻撃の前提というより攻撃の成果物に近い
第一審と控訴審の判断
- 第一審ではMatt Chapman側が勝訴した
- Chicagoは直ちに控訴し、Matt ChapmanはCANVASスキーマを受け取れなかった
- 控訴審は、原審が事実認定の主たる主体であるという前提で法律上の争点を扱った
- 公開によるリスクについては、“would jeopardize”の基準が争点になった
- “could”は、何かが起こり得ると想像可能な水準を意味する
- “would”の法的基準は、裁判官に合理的疑いを残さない明確な危害の証拠として説明された
- 控訴審は、危害の可能性が非常に高くなければならないという方向で判断した
- 控訴審は、例外規定の限定文言が“any other information”のみにかかるのか、それとも例外全体の“Administrative or technical information”にかかるのかを扱った
- “any other information”のみにかかるなら、file layoutsなどはそれ自体で適用除外となる
- 例外全体にかかるなら、公開がセキュリティを脅かさないという事実認定だけでMatt Chapman側が勝てる
- 控訴審は、限定文言が例外全体にかかると見て、Matt Chapman側に軍配を上げた
Illinois Supreme Courtで覆った結論
- Chicagoは再び上訴し、事件はIllinois Supreme Courtへ進んだ
- Illinois Supreme Courtは、FOIAの例外規定の解釈について控訴審とは異なる判断をした
- 限定文言は“any other information”のみに適用される
- 残りの項目はそれ自体で適用除外の対象である
- この判断により、SQL schemaがfile layoutかどうかが決定的な争点になった
- スキーマとfile layoutは技術的に異なるという反論が出た
- 同じSQL schemaを複数のデータベースエンジンが使用できる
- 各データベースエンジンは結果データを互いに異なるunderlying file layoutで管理する
- McGraw-Hill Dictionary of Scientific & Technical Terms, 6Eはfile layoutを「ファイル内のデータ配列の説明」と定義している
- SQL schemaは、データの実際の配列を意識しないように作られた抽象化に近い
- Illinois Supreme Courtは、Merriam-Webster Online Dictionaryのschemaの定義である“structured framework or plan: outline”も用いた
- 裁判所は、違いは名称だけだと判断した
- 結果としてスキーマはfile layoutとして扱われ、Matt Chapman側は敗訴した
現在の状況とSB0226
- 現在、Illinoisの公共機関はデータベーススキーマの公開を拒否できる
- データが専用アプリケーションへ移行するほど、基礎データにアクセスするにはFOIAでデータベースクエリを請求しなければならない状況が増えている
- データベースが地方政府の公共情報公開を逃れる安全地帯になってはならない、という問題が残っている
- SB0226は、公共機関が管理するすべてのデータベース構造について十分な説明を提供するよう、FOIA法に文言を追加しようとしている
- 目的は、請求者が公共機関に具体的なデータベースクエリの実行を求められるようにすることだ
- この法案は、Matt Chapmanがこの問題を継続して提起してきた流れとかなり重なっている
1件のコメント
Hacker News のコメント
この訴訟の原告です。tptacek の記事に添える関連稿もまだ執筆中で、まもなく用意できる予定なので、その間ここで質問しても構いません。
待っている間、以前の記事も参考になると思います: https://mchap.io/that-time-the-city-of-seattle-accidentally-...
ただし Matt は、全米でも最高水準の公民権弁護士である Loevy and Loevy の支援を受けても、技術的には敗訴したという点は覚えておくべき。市役所を相手に戦うことがどれほど途方もなく難しいかを示しているし、弁護士なしでやろうとすればなおさらひどい。
私たちに有利なのは、記事で提案されているように法律を変えることだ。州最高裁が判決を下してしまえば、改正なしには終わりで、Illinois は FOIA 法を頻繁に修正してきた歴史がある。ただし、その一部は公開の拡大ではなく、情報の非公開をさらに強化する方向でもあった。
もう一つ必要な変化は、こうした争いで負けた機関に強い罰則を科すことだ。Illinois では、機関に対する5000ドルの民事罰程度に限られる。民事罰が何を意味するのかも曖昧に定義されていて、以前は原告に支払われていたが、私が後に争った事件では、単に郡にお金を渡す形にさせられた。ある州検事の言葉どおり、「負けても構わない、自分宛てに小切手を書けばいいだけだ」ということになる。
最後に、訴訟で何を求めるかには注意が必要だ。こうして控訴審判決が出て、自分がまさに争っていた内容を法律として固定してしまうことがある。誰かの過失ではないが、実際に起きる。私自身も、受刑者の権利を強化するどころか取り除いてしまう、とんでもない判決を一つ得たことがある。
'); SELECT col FROM loginsができると分かっているほうが、ずっと簡単になるのではないか。スキーマとファイル配置に関する裁判所の判断にも、特に反対しづらい。スキーマはファイル配置そのものではないが似ている。「ファイル」（レコード）が「ファイルシステム」（データベーステーブル）にどのように配置されているかを教えるものだからだ。たとえば非正規化は、ファイルレコードの中にデータをインラインで入れることと非常によく似ている。ファイルシステムは事実上データベースだという見方もよく知られている。両者が似ていないとどう主張できるのか気になる。
次の段階は何だと考えているのか気になる。
市はスキーマを共有すべきで、実質的に曖昧さによるセキュリティを主張しているのだと思うが、記事の中心的な前提である「SQL スキーマを知っても攻撃者の助けにはならない」には同意しない。
記事の論旨はこう理解した。「攻撃者は SQL インジェクション攻撃によって SQL スキーマを復元する。スキーマは攻撃の前提ではなく、攻撃の産物だ。」脆弱性を見つければスキーマもどうせ復元できる、という意味に見えるが、常にそうとは限らない。SQL インジェクションの中には、現在クエリされているテーブルの一部データだけを取得でき、
information_schemaのような別テーブルは取得できないものもある。脆弱性から得られるシグナルが「クエリ失敗」または「クエリ成功、データ返却」だけなら、スキーマを知っているほうがはるかに悪用しやすい。失敗したデータベースクエリを別途記録しているなら、24時間動き続ける攻撃が見つけられるインジェクションは、すでにパッチ済みである可能性が高い。そうなると、実際のインジェクションポイント、たとえばログインユーザーにだけ存在してボットには見つけられない脆弱性が発見されるまではログは騒がしくならず、その時点で攻撃者が実際の活用方法を見つける前に確認して修正する時間がある。
スキーマを知っていると脆弱性悪用の速度が上がるだけでなく、最初からクエリ失敗を起こさずにインジェクションを探索できる可能性も高まる。
基準は「役に立つ情報はすべて検閲」ではなく、「パスワードやバックドアを明かすコードは公開するな」であるべきだ。スキーマはその範疇にはなり得ない。
それでも、完全なインジェクションがなくても、スキーマを知っているとデータ漏えいに役立つアプリケーションを実際に扱ったことがある。最も明白な例は、URL パラメータに基づいてクエリを構築しているのに、そのパラメータを許可リストで制限していない場合だ。
だから、スキーマが攻撃者に多少の利得を与え得るという点には同意する。
https://brutecat.com/articles/leaking-youtube-emails
だから、その論理は成り立たないと思う。
サーバーログにはエラーを示すものは何もない。
私が教えていた比較的入門レベルの SQL インジェクション演習も、ほとんどはスキーマを知らない状態で行われていた。だから SQL インジェクションはそれほど巧妙で危険なのだ。
Kurt が私を釣ろうとしてこれを投稿したものです。もともとの対象読者の大半は、私の地元であるシカゴランド地域の自治体政治に関わる非技術者だった、という点は知っておくとよいです。
地域政治についての公共広告をすると、全国政治に関わるのは超高層ビルの窓ガラスにぶつかる羽虫のように陰鬱で、気力を奪われます。一方で地域政治は非常に反応がよいです。私は余暇とほとんど費用をかけずに実際の成果を出し、法律を1つ通すこともできました。全国政治とは劇的に違います。
多くの地域で驚くのは、地域政治が掲示板中心に回っていることです。その掲示板はあなたが居たい場所ではないかもしれず、特に Facebook Group が多いのですが、そこは受け入れるしかありません。HN のようなコミュニティに参加するのが好きなら政治にも参加できますし、掲示板で活動するだけでも物事を実現できます。
実は米国内でもこういうケースは多いです。ホームルール権限を持つ地方政府だけが、州法・連邦法と衝突しない限りどんなテーマでも条例を制定でき、そうでない地方政府は州議会が認めた特定のテーマについてのみ制定できます。すべての郡と自治体にホームルールを与える州もあれば、まったく与えない州もあり、一部にだけ与える州もあります。たとえば Texas では、自治体が人口5000人に達した後、有権者の承認を得るとホームルール権限を持てます。
また、Chicago の政治にもっと関わりたい人が参考にできる良い資料を、Facebook でも他の場所でも、リンクしてもらえるかも気になります。以前検索してみましたが、成果はかなり限られていました。
最高裁と控訴裁判所が文の構造の問題で割れたというのは、ばかげていませんか？ よくあることだという点はさておき、「すべてのファイル配置とその他の項目も該当するが、そのその他の項目は悪いものだけ」と解釈するのは、個人的にはあり得ないと思います。法律の条文が完全に曖昧なまま残されても平気でいる現実が不思議です。
こうした曖昧さが裁量を得る裁判所にとって有利なのも知っていますし、勇敢な試みがあっても法律文を「形式的に完全な」言語にはできないことも知っています。法律がめちゃくちゃであることも、法律は誤りの多い素朴な人間が書くものだということも分かっています。
それでも、法律に書かれた基本的な文構造が裁判所にも明確でないなら、システム全体が最初の関門で失敗しているのではないでしょうか？
たいていは法律を曖昧でないように書くべきだ、という答えになりますが、言うほど簡単ではありません。さらに立法者自身も完全には合意できない場合があり、裁判所に解釈させるために一部の文言を意図的に曖昧に残すこともあります。
ソースコード例外が真正面から入っている部分に、少し困惑し不安を覚えるのは私だけでしょうか？
市が特定のソフトウェアを内部開発し、望ましくないかもしれない「偏り」や他の要素をソースコードに隠すシナリオは容易に想像できます。
しかも全部をゼロから作る必要すらありません。寛容なライセンスのサードパーティコンポーネントをパッチして使うだけでもよいのです。
私の考えでは、提案された改正案は十分に踏み込めていません。
クローズドなプロジェクトをオープンソースに転換しようとする人たちが直面するのと同じ問題です。開発者と顧客には使用する権利だけがあり、ソースを共有する権利はないプロプライエタリコードがあちこちに閉じ込められています。
政府請負業者のような直接的な商業的利害関係なしに、最初から強いオープン志向で作られたプロジェクトでさえ、この問題に直面し得ます。Linux カーネルが ZFS やカーネル／ユーザー空間のバイナリ blob ドライバをサポートする際に直面する問題はよく知られています[1]。
皮肉なことに、一方では情報は自由になろうとし、経済的にはオープンソースソフトウェアが時間とともにクローズドな競合を押し出していくでしょう。しかし、プロジェクトをオープンソースへ転換すること自体が高価で、時には手に負えないほどであるため、管理者や企業が望んでも古いツールを公開できないようにします。法務チームを巻き込み、各コンポーネントの権利者を探す作業だけで、ほとんどの管理者は諦めてしまいます。
政府が契約で、サプライヤーに依存関係ツリー全体でオープンソースコンポーネントだけを使うよう求めれば、コストは非常に高くなり得ます。多くの依存関係には同等のオープンソース代替がないか、クローズドな代替の機能が不足していて、その機能を埋める予算が必要になるからです。短期的には、どの議会もそうした追加費用を受け入れないでしょうが、長期的には大衆が利益を得ます。
[1] カーネルの問題はおおむね GPL の関数である、という点は確かです。Apache 2 や MIT のようなより寛容なライセンスならそうした問題はなかったでしょうし、BSD 系も ZFS サポートに困りませんでした。ただし、公共アプリケーションは政府が原則としてオープンソースにすべきだという立場は、ライセンス面では MIT より GPL に近いです。そうでなければ、サプライヤーが実際に重要な部分を「ベンダリングされた」バイナリ blob コードとして持ち込み、公開コンポーネントには意味のない骨組みだけを置いて要件を満たすことができてしまいます。
ただし、こうした判決は萎縮効果を生み得ます。
記憶している限りでは、今は失敗に終わったドイツの前連立政権がこれを公約に入れていましたが、実行できませんでした。新政権はやるかもしれません。
非常に興味深い記事
スキーマの公開を保護対象と見るのは、ばかげているように見える。説明どおりなら、「データベースの中にあるのだから何も知ることはできず、探し方を言えなければ詰み」といった魔法のような結果が可能になってしまう
顧客の多い小さな会社で働く立場としては、データベーススキーマをそのまま渡したくはないが、それでも顧客が望むデータを探して提供しようと努めるのであって、拒否はしない
cleartap.com プロジェクトのために、米国の水質データベース文書100万ページ以上を FOIA で請求した
ほとんどの州は文書を集めるのに少額しか請求しなかった
Michigan は FOIA 請求に5万ドルを要求した。Flint の鉛汚染問題のせいだと思う。私を諦めさせようとしたのだろう
プロジェクトは素晴らしい
「Bob O に発行されたすべての駐車違反切符データを取得し、データベース内の残りすべての情報と全員のパスワードも取得せよ」
これは平文の英語で書いた SQL インジェクションの例だが、ここでは「everyone's」にも孤立したシングルクォートが生じる点で問題になる。「Bob O'Conner」が悪いなら、「everyone's」も悪い
「彼らが実行するプログラムのソースコードも、通常は FOIA で請求できない」
残念ながら、その部分は FOIA 上、違法であるべきだと思う
ソースコードはオープンソースで、検証可能であるべきだ。FOIA の例外にすると、政府のソフトウェア利用に対する市民の信頼を迂回することになる
裁判所がすでにこの種の問題をどこでどのように判断したのか気になる
実際、政府機関が秘密にしておきたく、法的にも認められる業務ロジックもあるかもしれない。原文の駐車違反切符データベースなら、そのデータベースと通信するソフトウェアのソースコードに、駐車監視員がいつどこで「ランダムな」重点取り締まりを行うかを選ぶロジックが入っているかもしれない
こういう点のせいで、ロースクールに行こうという気持ちが折れた。訴訟のかなりの部分は歌舞伎劇場のようで、正義や論理的な結果を得るためのレトリックではなく、権限を持つ人が裁判前からすでに下したかった判断に口実を与えるためのレトリックのように見える
誰かが HTTP リクエストに含まれる
information_schemaのようなキーワードとそのエンコード変種をざっと見る、Web ファイアウォールに似たシステムを合法的に構成することはできる。こういうものは常にハッキングの試みなのでブロックできる。すでにスキーマを知っていれば、その制約を先に回避する必要なくクエリを作れる。これが重大な障壁である可能性は高いか。いいや。これが自己中心性と関係しているか。そうは見えない単に「周辺的」、つまり核心ではなく議論するほど重要ではないという意味で、ごく小さな価値があるというのは正確に見える。しかし真実だけを述べたところ、相手がそれを大きく取り上げて「ほら、相手側の専門家も価値があると言っている」と裁判所を説得しようとする。だから専門家はただ「価値はない」と言うべきだった、と結論づける。私はその言葉は間違っていると思うが、あまりにごくわずかに間違っているため、相手が完全には正しくないことを立証するのが難しい。結局、この法廷ではより不正確な言葉のほうが有利になり、専門家としての役割と同じくらいレトリックが重要になる