SQLインジェクション判決は他にもあった-東京地裁平成19年(ワ)16258号-

 投稿日時
2015/05/12 15:55:19
 最終更新日時
2015/05/12 17:19:46

「例の」SQLインジェクション判決

広がりと収束

2月に書いたSQLインジェクション脆弱性の有無が重過失の判断に影響を与えた判決という記事は徳丸先生に言及いただいたり、オワスプジャパンのスライドでこの判決のことが取り上げられていただきました。

あの記事は、自分の中で要素を網羅したいという動機があったため長く読みにくい記事となっていたため、もうちょっとポイントを絞った記事を書きたい、もしくはプレゼンにしたいという気持ちがあるにはあるのですが、時間も経ってしまったためにまだ取りかかれずにいます。

他にもあるのかという問題

それはさておき、今回のことが話題になってから、どこでかは覚えていないのですが「あのSQLインジェクション判決」とか「例のSQLインジェクション判決」といった呼び方を見かけたり、自分でも使うことがありました。3月くらいにそれを見かけて、「他に『SQLインジェクション』という言葉が登場する判決はあるのだろうか?」と思って調べてみたことがあります。
一般的に法律や司法制度にIT技術は馴染んでいないと思われていますが、判決にはいろいろな単語が出てきますのでもしかして…と思って調べてみたのですが、裁判所の判例検索サイトで検索しても、「インジェクション」がヒットするのは会社名だったり車の部品だったりで、「なるほど、現時点で他には無いのか。」と考えた覚えがあります。(ちなみに「SQL」はそのままの意味でヒットします。)

判例検索サイトによる違い

ところが4月末になって、裁判所のサイトには全判例が載っているわけではないので、他の判例情報サイトには載っているのでは無いかということを思いつきました。
ご存じでない方のためにご説明しますと、過去の判例というのは法曹界にいる方たちにとっては非常に重要なものですので(最近読んだ本では、法律家の武器は「条文・判例・学説」の3つと紹介されていました)、判例を検索するサービスを有料で提供している会社がいくつか存在します。私の知る限りでは、LICが提供する判例秘書、第一法規が提供するD1-Law.com、Westlawが提供するWestlaw JAPANなどが有名です。

上の3つで検索したところ、Westlaw JAPANで「SQLインジェクションという言葉が登場する別の判例」を見つけることができました。(もちろん、検索技術不足により私が見つけられなかっただけで、他の2サイトにもこの判例があった可能性があることは申し添えておきます。)

というわけで、前置きが長くなりましたが今日はその判決、平成19年(ワ)16258号の紹介です。

東京地裁平19(ワ)16258号の概要

ただ先に言ってしまうと、東京地裁平成23年(ワ)32060号では重過失かどうかの判定でIPAの文書が重要なものとされ、SQLインジェクションの存在が判断のポイントとなっていましたが、この判決ではそれほどSQLインジェクションが重要なポイントになっているというわけではありません
この裁判は、ホームページリニューアルを受注した会社(原告)が、発注元(被告)に対して開発費用を請求したものなのですが、結論から言うと原告の請求は棄却されました。裁判所がそう結論づけたのは、原告の作成したものが実用レベルに無いと判断したためなのですが、そこで挙げられている瑕疵の中で「SQLインジェクション」という単語が登場しています。
あくまで私見ですが、ここに挙げられているより多く瑕疵のあるホームページを作るのは逆の意味で骨が折れると思いますが、みなさんはどう思われるでしょうか。

登場人物

本件の登場人物は多く、関係も複雑ですのでここで整理しておきます。

原告 被告からホームページリニューアルを受注した会社。
被告 ホームページリニューアルを原告に依頼した会社。
被告の代表取締役。
被告側の担当者として、ホームページリニューアルの打ち合わせなどに参加していた。被告のホームページ関連業務と経理を行っていた。(だが被告との関係は雇用関係ではなく、委任または請負契約であると裁判所に判断された。)
米国ロサンゼルス在住のデザイン会社社員。リニューアルのデザインを依頼されて行った。
リニューアル前のホームページ運営会社。オープン時から2年ほど作業を行っていたが、リニューアルの見積もりが高かったことにAが難色を示し、Bと親交のあった原告がリニューアルを担当することになった。
SI業者。リニューアルにおけるシステム制作を行った。
従来より課金プログラムを被告に提供しており、リニューアル後のシステムでも課金プログラムを提供する予定であった会社。
不具合が見つかった本システムに関して、引き継いでシステム開発は可能かどうか被告が問い合わせた会社。
被告の代理人弁護士が、ホームページのサイト構成について調査解析を依頼した会社。。

このBの立場はかなり特殊で、争点(1)で絡んできます。

判決の目次

  • 主文
  • 事実及び理由
    • 第1 請求
    • 第2 事案の概要
      • 2 争点
        • (1) 争点(1)(原被告間の請負契約締結の有無)について
          • 原告の主張
          • 被告の主張
        • (2) 争点(2)(原告の請負代金債権の有無)について
          • 原告の主張
          • 被告の主張
        • (3) 争点(3)(被告の相殺の抗弁の当否)について
          • 被告の主張
          • 原告の主張
    • 第3 判断
      • 2 争点(1)(原被告間の請負契約締結の有無)について
      • 3 争点(2)(原告の請負代金債権の有無)について
    • 第4 結論

「第2 事案の概要」に出てくる争点は3つですが、「第3 判断」に出てくる争点は2つです。つまり、裁判の過程の中で争われた点が3つあったものの、実際に裁判所が判断を下すにあたっては2つの争点のみが影響を与えたということです。

システムの瑕疵と判断された部分

争点を見ていく前に、リニューアル後のシステムにあると判断された瑕疵について見ていきたいと思います。
この辺は被告が述べたものなのですが、どうやら原告は争わなかったようで裁判所はそのまま認めています。

これらは、の判断によるものと思われます。

プログラムについて

  • 「sqlインジェクション対策、クロスサイトスクリプト対策、セッションハイジャック対策、サニータイジング(変数チェック)」(以上かっこ内は原文ママ)については、処理が見受けられないか、処理に規則性が無く、プログラムコード・構成が納品レベルではない
  • PHPとhtmlが分離されていなく(テンプレート化されておらず)、プログラムを知らないデザイナーがいじれない。
  • 名前付けに規則性が無い。
  • セキュリティ重要なファイルが、閲覧できる領域に置いてある。
  • エラー処理が無い。
  • SQL処理について、データ数・表示速度が全く考慮されておらず、まともではない
  • 既存のバグが取り切れていない。

仕様書、資料について

  • システム設計を行うための設計書が一切存在しない。
  • フロントデザインを行うための設計書も存在しない。
  • テストの資料も存在しない。

フォルダーの構造について

  • コンテンツ構造について、オープン系とクローズド系で重複が見られ、設計思想が無い
  • 会員登録、会員認証などの重要な機能がサブページ内に隠れている。
  • コンテンツ間の移動やコンテンツの重要度、隣接性が考慮されておらず、使い勝手が悪い。
  • コンテンツ構造とフォルダー構造に整合性が無い。
  • 複雑なファイル構成になっており、更新作業が困難である。
  • フォルダー、ファイル名称が統一されていない。

ファイルの構造について

  • 基本的なタグで構成されている。
  • ライティング要素が考慮されておらず、クローリングに対応しない。
  • フォントが全て固定化されている。
  • サイトのトップページは画像1枚にmapを使ってリンクしているだけである。
  • メタネーム、alt属性、フォントの強調、アンカー、サイトマップなどの基本要素が欠落している

余談ですが、私はWebシステム開発を一応の専門にしていますが、ここの「基本的なタグで構成されている」の意味が分かりませんでした。ごくまれに、pタグのみで組んで後はfontで装飾しているというHPを見かけますがそういう意味なのでしょうか。

以前、お客様が「ひどい会社」と評する会社から仕事を引き継いだことがありますが、その会社のHPは縦にまあまあの長さがあったにも関わらず画像1枚だった(しかもaltも設定してなかった)ことをここを読んでいて思い出しました。

システムデザインについて

  • 同一プロセスが複数ファイルに分かれている。
  • コメントアウトが一切存在しない。
  • 「お悩み相談」、「エッセイ」等のRDBMSを実装しているが、HTMLで作成された本来不要なファイルも表示しており、ホームページの構造定義が曖昧であると言える。

判決に影響した争点

争点(1)(原被告間の請負契約締結の有無)

原告と被告の主張

ポイント 原告の主張 被告の主張
経緯と作業
  • 原告は、平成17年3月までが行っていた毎月の更新作業とHTML制作を請け負うと平成17年4月10日に契約した。
  • リニューアルにあたっては、被告の担当者であるととりまとめを行った。平成19年6月までに料金体系などの企画をまとめ、一部について合意を得た。
  • 合意を得たため、システム開発をに依頼すべく見積もりを依頼。200万円で被告に見積もりを提示した。
  • デザインはが行ったが、その選定に原告は関わっていない。
  • 課金プログラムについては、従前より被告と契約していたが行い、システムの打ち合わせはが直接行った。
  • 本件請負契約により原告が請け負ったのは、HTMLの制作とデザイナーのデザインのHTMLへの組み込みのみであった。
  • 被告に対して原告を紹介し、原告との打ち合わせを行っていたのは、被告の関連会社で経理をWebを担当していたである。
  • 被告ととの契約関係は雇用契約ではなく請負契約である。
  • 従って、原告はの下請に当たる。そのため、原告に請負代金請求権が発生しているとしても、支払義務があるのは被告では無くである。

裁判所の判断

ポイント 裁判所の判断
経緯と作業
  • 被告ととの間で雇用契約が締結されたことは無く、委任ないし請負契約である。
  • しかし、ホームページの原稿は被告の社員から原告に送付され、報酬は被告の関連会社から支払われていたことから、原告は下請としてではなく、原告と被告の間で直接的に契約が締結されたものと推認されるのが相当というべきである。
  • ただし、デザイン料についてはから被告に対して請求されており、の下請であったと解する余地はある。
  • 原告は、リニューアルについての企画書を作成し、システム制作を社に提案するなど、とともに中心的立場にあった。トラブル発生時も、と関係なく原告の力不足にゆえに発生したと謝罪したものと認められる。そのため、は原告の下請的立場にあり、の作業についても原告は契約責任を負担するものと考えていたのが相当である。
  • 以上により、請負契約の内容はHTML制作に限定されず、リニューアル作業全般と準備のための更新作業であったと認めるのが相当である。

争点(2)(原告の請負代金債権の有無)

原告と被告の主張

ポイント 原告の主張 被告の主張
経緯と作業
  • 原告は請負契約に基づく毎月の仕事を完成させ請求したが、平成17年9月以降の支払は無かった。被告がサイトを停止したことから39万1750円を値引きし、未払い額は合計140万円となる。
  • 被告は、ホームページには瑕疵があり、原告は仕事を完成させていない旨を主張する。しかし、被告が瑕疵として主張する問題は原告が依頼されたHTMLの制作とは無関係である。
  • 本件ホームページのプログラムコードを作成したのは原告ではなくである。は原告の下請けでは無く、と被告の間で請負契約が成立している。
  • さらに、被告が主張する制作上の問題は、被告の側のオープン直前の仕様変更が影響したためである。
  • 原告は仕事を完成させておらず、請負代金請求権は発生していない。
  • 本件リニューアルは被告がに対して外注し、が原告に対して委託した。原告はにシステムの作成を委託したのであり、は履行補助者にすぎない。
  • 原告が作業を行ったホームページは、余りにも根本的な瑕疵を多数有するものであり、到底製品としてエンドユーザーに提供できる実用レベルになく、そもそも仕事が完成されたということができない。
  • 実例はシステムの瑕疵と判断された部分の通り。
  • 原告は、瑕疵が被告の指示に起因すると主張する。しかし原告は有償契約の一方当事者であり、専門的知識・経験を有するものとして、専門的技能を駆使して仕事を遂行することが要求される。また請負人である原告には、注文者である被告の指図が不適当な場合にはこれを注意する義務があるが、原告はかかる義務を怠っている。

裁判所の判断

ポイント 裁判所の判断
経緯と作業
  • 原告は、オープン時のトラブルについて謝罪し、原告の力不足故に発生したと認めていた。
  • 原告は被告側のオープン直前の仕様変更が影響したためである旨を主張している。しかし、リニューアル作業の中心的立場にあった原告として、素人の依頼者である被告からの仕様変更要請に対して、オープン時期に間に合わせようと応じた以上、被告に原因があるとして責任を被告に転嫁できるものではない。
  • 製品としてエンドユーザーに提供できる実用レベルではなく、ゼロから構築した方が高レベルのものができると指摘されており、オープン直前の仕様変更が専らの原因であるとたやすく認められるものではない。
  • 以上の通り、多数の問題点を有するものとして実用レベルにあるものではないと認められ、原告は被告から請け負った仕事を完成させたと評価することはできない。
  • そして、前期認定の通り、リニューアル作業と更新作業は一体であるため、更新作業のみ請求することはできないというべきである。
  • 平成17年9月までの支払については、リニューアル作業に問題があることが判明する前のものであり、これを原因として報酬を請求することができると認められるものではない。
  • 以上より、争点(3)(被告の相殺の抗弁の当否)について判断するまでもなく、原告の報酬請求は理由がないというべきである。

判決に影響しなかった争点

争点(3)(被告の相殺の抗弁の当否)

判決に影響していないため、省略します。
主に主張をしたのは被告であり、ホームページに存在した瑕疵のせいで有料会員からの会費などの損害があったという主張です。

結論

以上のように争点を見てきましたが、結論として、原告の請求は棄却され、被告は代金を支払う必要がないものとされました。流れとしては以下のようになります。

  1. 作業フローや報酬の支払状況から考えると、原告はの下請けではなく、被告と直接契約していたと考えられる。
  2. 原告は企画書を作成するなど中心的な立場にいたと考えられ、更新作業とHTML制作だけではなくリニューアル全体を請け負っていたと考えられる。
  3. 制作したホームページには瑕疵があり、エンドユーザーに提供できるレベルにはない。
  4. 納期直前に被告から出た仕様変更については、応じて間に合わせようとした以上、責任を被告に転嫁できるものでない。また、瑕疵を見る限りそれだけが原因ではないと考えられる。
  5. リニューアル作業を完成させていない以上、更新作業の費用も含め報酬を請求することができると認められない。

というわけで、今日はまだあまり世に出てきていないSQLインジェクションに関する、もう一つの判決を取り上げました。
SQLインジェクションをどう防ぐかについては優良な技術書がありますが、それらを読みながら「SQLインジェクションが残っていて、何か障害を起こしたらどうなるんだろう」と思った方の参考になりましたら幸いです。

また、今回の件では瑕疵について全く争った形跡がないのでそのまま認められてしまっていますが、ここに挙げられている問題がどこまで瑕疵と言えるのかどうかは面白い論点ですよね。以前の件ではIPAの文書が重要なポイントになりましたが、例えばどんな根拠をもって「PHPとhtmlが分離されていないこと」や「設計書が一切存在しないこと」を瑕疵と呼ぶか、または瑕疵と呼ばれたときに否定するか。皆さんはどんな意見をお持ちでしょうか。