Podatności SQLBot

SQLBot przed wersją 1.8.0 zawiera podatność typu Cross-Workspace IDOR oraz obejście autoryzacji w punktach końcowych /api/v1/datasource/exportDsSchema oraz /api/v1/datasource/uploadDsSchema. Atakujący może uzyskać dostęp do schematów baz danych i źródeł danych należących do innych najemców/obszarów roboczych.

SQLBot do wersji 1.10.1 nie weryfikuje własności dashboardów w punktach końcowych update_resource i update_canvas, co pozwala uwierzytelnionym członkom obszaru roboczego modyfikować prywatne dashboardy innych użytkowników. Atakujący mogą podać dowolne identyfikatory dashboardów, aby zmienić ich nazwy oraz nadpisać dane komponentów, style kanwy i informacje o widokach należące do innych członków obszaru roboczego.

W SQLBot przed wersją 1.9.0 uwierzytelniony użytkownik może podać spreparowaną wartość sheet["tableName"] w konfiguracji źródła danych Excel, która jest przechowywana bez bezpiecznego przetwarzania identyfikatora. Przy usuwaniu źródła danych wartość ta jest wstawiana do SQL i wykonywana przez PostgreSQL, co umożliwia second-order SQL injection.

SQLBot przed wersją 1.9.0 zawiera podatność w punkcie końcowym POST /api/v1/datasource/previewData, gdzie wartość table_name kontrolowana przez klienta jest wstawiana do generowanego SQL bez bezpiecznego obsługiwania identyfikatorów. Uwierzytelniony użytkownik może skonfigurować źródło danych dla wewnętrznego PostgreSQL i wysłać spreparowaną nazwę tabeli, która pozostaje operacją SELECT, ale wywołuje funkcje pg_read_file(), pg_read_binary_file() lub pg_ls_dir(). W domyślnej konfiguracji zaufanego uwierzytelniania loopback, wewnętrzne połączenie akceptuje nieprawidłowe poświadczenia i wykonuje się z uprawnieniami superużytkownika PostgreSQL, co pozwala na odczyt plików systemowych, takich jak /etc/hosts i /etc/passwd, w odpowiedzi API previewData, potencjalnie ujawniając konfigurację, poświadczenia, sekrety uwierzytelniania i kod źródłowy. Problem naprawiono w wersji 1.9.0.

SQLBot przed wersją 1.9.0 umożliwia uwierzytelnionemu użytkownikowi przesłanie logo asystenta w formacie image/svg+xml przez PATCH /api/v1/system/assistant/ui, a SQLBot przechowuje SVG bez sanityzacji lub walidacji osadzonych aktywnych treści. SQLBot następnie serwuje plik inline z tego samego pochodzenia aplikacji przez GET /api/v1/system/assistant/picture/{filename}. Gdy inny użytkownik załaduje ten zasób, JavaScript osadzony w SVG wykonuje się w kontekście aplikacji webowej SQLBot, co prowadzi do trwałego cross-site scripting z dostępem do danych i akcji dostępnych w sesji ofiary. Problem naprawiono w wersji 1.9.0.

W SQLBot przed wersją 1.9.0 endpoint POST /api/v1/datasource/parseExcel używa kontrolowanej przez atakującego nazwy pliku z multipart do wyboru miejsca zapisu, zapisuje treść przed zakończeniem walidacji i może przekształcić podwójne rozszerzenie w plik źródłowy Pythona. Plik trafia do katalogu alembic/versions/ i jest importowany przy starcie SQLBot.

SQLBot do wersji 1.10.0 zawiera podatność na trwały skrypt XSS w komponencie SQText, który renderuje dane TinyMCE przez v-html bez sanityzacji. Atakujący, którzy mogą modyfikować treść widżetu tekstowego, mogą wstrzyknąć dowolny HTML i JavaScript, który wykona się dla wszystkich użytkowników przeglądających dashboard.

SQLBot w wersji 1.7.0 i wcześniejszych jest podatny na wstrzykiwanie promptu w interfejsie Text2SQL, gdzie parametr pytania użytkownika jest bezpośrednio konkatenowany do promptu LLM, a wyodrębnione SQL jest wykonywane bez walidacji, co może prowadzić do zdalnego wykonania kodu przez COPY FROM PROGRAM w PostgreSQL.