Datasette 1.0a38: закрыта SQL-инъекция в базах со смешанными правами доступа
В Datasette обнаружена и исправлена уязвимость SQL-инъекции, позволявшая читать приватные таблицы через публичные в одной базе данных. Патч выпущен в версиях 1.0a38 и 0.65.3. Риск реальный, но затронута редкая конфигурация: когда публичные и закрытые таблицы живут в одной БД.
Если вы используете Datasette для работы с данными — это прямой повод проверить конфигурацию безопасности. Для всех остальных — напоминание, что SQL-инъекции не ушли в прошлое и изоляция данных критична даже для внутренних инструментов.
Создатель Datasette Саймон Уиллисон выпустил срочный патч для версий 1.0a38 и 0.65.3, закрывающий SQL-инъекцию. Уязвимость позволяла пользователям с доступом к любой публичной таблице выполнять инъекции и читать данные из приватных таблиц в той же базе данных — даже если права на прямое выполнение SQL были ограничены.
Проблема критична для тех, кто использует систему разграничения доступа Datasette и хранит в одной БД и открытые, и закрытые данные. Уиллисон отмечает, что такая конфигурация встречается редко — он сам не сталкивался с такими инсталляциями в продакшене.
Рекомендация: если у вас есть приватные таблицы в БД с публичными — немедленно обновитесь и отключите разрешение execute-sql на уровне базы данных. Это временная мера до полного аудита настроек безопасности.
Автор: Елена Верещагина · Источник: simonwillison.net
Разработчикам. Если деплоите Datasette с приватными данными — проверьте, не смешаны ли публичные и закрытые таблицы в одной БД. Обновитесь до 1.0a38 / 0.65.3 и отключите execute-sql на таких базах. SQL-инъекции через параметры запросов — классика, но здесь она обходила встроенную систему прав.
Бизнесу. Если используете Datasette для внутренних дашбордов или API с ограниченным доступом — срочно аудит конфигурации. Утечка приватных данных через такую уязвимость может привести к нарушениям compliance и репутационным потерям. Редкость конфигурации не означает отсутствие риска.
Инвесторам. Инцидент показывает зрелость экосистемы открытых инструментов для работы с данными: быстрый патч, прозрачное раскрытие. Datasette популярен в дата-журналистике и внутренних инструментах. Безопасность остаётся ключевым фактором для корпоративного adoption таких решений.
- Аудит безопасности для Datasette-инсталляций: предложить услугу проверки конфигураций и настройки изоляции данных для компаний
- Форк Datasette с встроенной row-level security из коробки — нишевой продукт для корпоративного сегмента
- Плагин для автоматического детекта смешанных публичных/приватных таблиц в одной БД с алертами
- Обучающий курс по безопасной настройке Datasette для дата-инженеров и аналитиков
- SaaS-обёртка над Datasette с enterprise-фичами безопасности (RBAC, аудит логов, изоляция на уровне схем)
- Уязвимость затрагивает редкую конфигурацию — большинство пользователей вне зоны риска, но те, кто попали, могли уже утечь данные
- Отсутствие автоматической миграции или встроенных предупреждений при обновлении — администраторы могут пропустить патч
- SQL-инъекции в 2025 году — сигнал о недостаточном покрытии тестами безопасности в нишевых open-source проектах
- Прозрачность Уиллисона хороша, но публичное раскрытие без grace period могло дать время атакующим до массового обновления
Саймон Уиллисон поступил как положено: нашли баг — быстро пофиксили, прозрачно рассказали. Но сама проблема показывает, что архитектура с публичными и приватными таблицами в одной БД — это как держать золото и мусор в одном сейфе с разными замками. Рано или поздно кто-то найдёт отмычку.
Хорошая новость: конфигурация редкая, так что массовых утечек скорее всего не будет. Плохая: если вы попали в эти редкие случаи и не обновились — ваши приватные данные уже могли утечь. Вывод простой: изолируйте чувствительные данные на уровне отдельных БД или хотя бы схем, а не полагайтесь только на permissions поверх одной базы. И да, SQL-инъекции в 2025 году всё ещё в топе OWASP — классика не стареет.
Комментарии