はじめに：なぜフロントエンドエンジニアが知るべきか？

近年、開発プロセスを加速させるローコード/ノーコードツールが普及しています。Budibaseもその一つで、フロントエンドの構築からバックエンドの連携までをサポートする強力なツールです。しかし、便利なツールであっても、その裏側で動作するシステムにはセキュリティリスクが潜んでいます。今回の脆弱性は、Budibaseがデータベースと連携する部分で発生するSQLインジェクションであり、直接SQLを書く機会が少ないフロントエンドエンジニアの方々にとっても、開発環境や本番環境のセキュリティを考える上で非常に重要な情報です。

脆弱性の概要と深刻度

今回解説する脆弱性（GHSA-qqf5-x7mj-v43p）は、開発ツールBudibaseのPostgreSQL、Microsoft SQL Server、およびMySQL向けのデータベースコネクタに存在する複数のSQLインジェクションです。深刻度は「High」と評価されており、認証された管理者権限を持つユーザーによって悪用される可能性があります。

この脆弱性が悪用されると、接続先のデータベースが完全に制御され、機密情報の漏洩、データの改ざんや削除、さらには基盤となるサーバー上での不正なコマンド実行など、広範囲な被害が発生するリスクがあります。

具体的な脆弱性の詳細

Budibaseのデータベースコネクタでは、ユーザーがデータソース設定で入力するスキーマ名やテーブル名が、データベースへのSQLクエリに適切にエスケープやパラメータ化されずに直接組み込まれることが問題の本質です。これにより、SQL文字列の区切りを突破し、任意のSQL文を実行できるようになります。

具体的な脆弱性は以下の3つが報告されています。

**1. PostgreSQLにおける `SET search_path` SQLインジェクション**

`schema` データソース設定フィールドが、エスケープ処理なしで直接SQLステートメントに挿入されます。特に、スキーマ名に含まれる二重引用符がエスケープされないため、攻撃者は任意のSQLコードを注入できます。悪意のあるスキーマ名を設定して接続テストや保存を行うと、データベース内の全ての情報を読み取ったり、任意のDDL/DMLコマンドを実行したりして、データベースを完全に侵害できます。

**2. Microsoft SQL ServerにおけるスキーマイントロスペクションSQLインジェクション**

スキーマ情報を取得する処理において、ユーザーが設定したスキーマ名やテーブル名が、シングルクォートで囲まれたSQL文字列にエスケープなしで直接挿入されます。悪意のあるスキーマ名を登録し、テーブル情報を取得する動作をトリガーすると、任意のSQLコマンドが実行されます。さらに、データベースサーバーで `xp_cmdshell` のような機能が有効になっている場合、データベースが動作しているサーバー上で任意のOSコマンドが実行される可能性があります。

**3. MySQLにおけるバッククォートインジェクション**

MySQLコネクタが複数SQLステートメントの実行を許可する設定（`multipleStatements: true`）になっていることと、テーブルのイントロスペクション時にテーブル名がバッククォートで囲まれた `DESCRIBE` クエリにエスケープなしで挿入されることが組み合わさっています。攻撃者（または悪意のあるデータベースユーザー）が、バッククォートを含む悪意のあるテーブル名（例: `foo`; DROP TABLE users; --`）を事前にデータベース内に作成しておくと、Budibaseの管理者がそのデータベースのスキーマ情報を取得しようとした際に、注入されたSQLが実行され、任意のSQLコマンドがトリガーされます。

どんな影響があるのか？

これらの脆弱性により、機密情報の流出（顧客情報、個人情報、認証情報など）、データベース内のデータの改ざんや削除（Webサイトの破壊、業務停止）、さらにはMS SQL Serverの場合、データベースが動作しているサーバー上での任意のOSコマンド実行によるサーバー乗っ取りといった、極めて深刻な被害に繋がる可能性があります。これは単なる開発環境のリスクにとどまらず、本番環境に接続されたデータベースにも影響を及ぼし得ます。

フロントエンドエンジニアとして取るべき対策

直接データベースを操作しない場合でも、Budibaseのような開発ツールを使用している場合は、以下の対策をチーム全体で講じることが重要です。

**1. 速やかなパッチ適用:** Budibaseの公式から提供されている最新のセキュリティパッチを直ちに適用してください。これが最も直接的かつ効果的な対策です。

**2. 設定の見直しと確認:** Budibaseのデータソース設定において、不審な値が入力されていないか定期的に確認し、必要に応じて設定を修正してください。特に、手動でスキーマ名やテーブル名を入力する箇所には注意が必要です。

**3. 最小権限の原則:** データベース接続には、必要最小限の権限のみを持つデータベースユーザーを使用し、管理者権限を安易に与えないようにしてください。これはバックエンドエンジニアやインフラ担当者と連携して実施すべき点です。

**4. 不要なデータベース機能の無効化:** `xp_cmdshell` のようなOSコマンド実行を可能にするデータベース機能は、特に必要がない限り無効にすることを検討してください。これにより、仮にSQLインジェクションが成功しても、攻撃範囲を限定できます。

**5. セキュリティ意識の向上:** 自身の担当範囲外のツールであっても、そのセキュリティリスクについて関心を持ち、チームや組織全体で情報共有と対策を講じる文化を育むことが大切です。

まとめ

今回のBudibaseのSQLインジェクション脆弱性は、SQLインジェクションという古典的ながらも未だに深刻な脅威であることを改めて示しました。そして、ローコード/ノーコードツールのようなモダンな開発環境においても、サプライチェーン全体のセキュリティを考慮し、使用するツールやライブラリの脆弱性情報に常にアンテナを張ることの重要性を私たちに教えてくれます。フロントエンドエンジニアの皆さんも、ぜひこの機会に自身の開発プロセスにおけるセキュリティリスクについて再考してみてください。