Overview
This video covers the third CVE naoyashiga obtained with AI’s help. The target was NocoDB, an open-source, Airtable-like service for managing databases as spreadsheets without code. Opening a link made with the URL() formula function from a shared view shows a warning page about leaving NocoDB. That page takes a redirect URL and a back URL as parameters without proper validation, so a javascript: URL could run script and send cookie or storage values to an attacker’s server: a reflected XSS. The proof of concept used the back button, where a script is less noticeable. The maintainers fixed it by accepting only HTTP(S) URLs for both parameters.
Key Points
- Separate directories: the cloned repository,
reportsfor AI-written reports and test code, andrunfor Docker Compose files and local Postgres data. - Narrow the scope: skim the frontend (
nc-gui), and when there are too many files, screenshot the directory tree and ask another AI such as Gemini or ChatGPT which parts look suspicious. - Past security advisories are hints, since fixes are often incomplete. A recent one on formula and rich text fields pointed to formula cells; a prompt with the Formula docs, relevant file paths and those advisories produced a report already containing this issue.
- Verify AI findings: reproduce them in a local Docker setup, ask for testable code, and check against the docs yourself.
- Keep reports concise, and share the PoC video in a private comment rather than in the description, which becomes public.
Chapters
- 0:00 Introduction
- 0:20 The reported vulnerability
- 7:37 How to find vulnerabilities with AI
- 8:00 Preparing working directories
- 9:20 The vulnerability research prompt
- 11:55 Using past vulnerability reports as hints
- 13:01 The research prompt and its results
- 15:04 Verifying the findings
- 16:45 Reporting the vulnerability
概要
この動画では、AIを活用して筆者が取得した3つ目のCVEについて紹介します。対象は、スプレッドシートのようにノーコードでデータベースを管理できる、Airtableに似たオープンソースのNocoDBです。数式関数のURL()で作ったリンクを共有ビューから開くと、NocoDBの外へ移動することを知らせる警告ページが表示されます。このページはリダイレクト先のURLと戻り先のURLをパラメーターとして受け取りますが、検証が不十分だったため、javascript:のURLでスクリプトを実行し、クッキーやストレージの値を攻撃者のサーバーへ送れてしまいました。いわゆる反射型XSSです。PoCでは、スクリプトが目立ちにくい戻るボタンの方を使いました。メンテナーは、両方のパラメーターでHTTP(S)のURLだけを受け付けるように修正しています。
ポイント
- ディレクトリを分けます。クローンしたリポジトリ、AIが書いたレポートやテストコードを置く
reports、Docker ComposeのファイルやローカルのPostgresのデータを置くrunです。 - 調査範囲を絞ります。フロントエンド（
nc-gui）のコードにざっと目を通し、ファイルが多すぎるときはディレクトリツリーのスクリーンショットをGeminiやChatGPTなど別のAIに渡して、怪しそうな箇所を挙げてもらいます。 - 修正が不十分なことも多いため、過去のセキュリティアドバイザリーはヒントになります。直前にあった数式フィールドとリッチテキストフィールドの報告から数式セルが怪しいと考え、数式機能のドキュメント、関連するファイルのパス、過去のアドバイザリーを含めたプロンプトを渡すと、今回の問題がすでに含まれたレポートが出てきました。
- AIの調査結果は必ず検証します。ローカルのDocker環境で再現し、テスト可能なコードを出してもらい、最後はドキュメントを見ながら自分の目で確認します。
- レポートは簡潔にまとめ、PoCの動画は公開される本文ではなく、非公開のコメントで共有します。