Ревизор приехал: pg_anon проверяет, всё ли скрыто
#psql #Postgresql #pg #dev

В современном мире, где данные становятся новой нефтью, разработчики часто сталкиваются с дилеммой: как тестировать приложения на реальных данных, не подвергая риску конфиденциальную информацию пользователей? Использование продакшн-данных в тестовых средах без должной анонимизации может привести к серьёзным утечкам и, как следствие, к многомиллионным штрафам и потере репутации компании.

Здесь на помощь приходит инструмент pg_anon — решение для анонимизации данных в PostgreSQL. С его помощью можно маскировать персональные данные, сохраняя при этом структуру и целостность информации. Это особенно важно для разработчиков и тестировщиков, которым нужны реалистичные данные для работы без риска нарушения конфиденциальности.

В статье подробно рассматриваются примеры конфигураций pg_anon и приводится пошаговое руководство по его внедрению в процессы разработки. Автор, опираясь на 15-летний опыт работы с данными в крупных проектах, подчёркивает, что безопасность данных — это не препятствие для работы, а залог спокойствия и стабильности бизнеса.

Для разработчиков, стремящихся обеспечить безопасность данных и соответствие современным стандартам защиты информации, внедрение таких инструментов, как pg_anon, становится не просто рекомендацией, а необходимостью.

➡️Читать далее

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

CVE-2025-13780 — критический RCE-баг pgAdmin 4
#CVE #RCE #pgAdmin #PostgreSQL #SQLi #PoC

Позволяет выполнять произвольные shell-команды на сервере через обход regex-валидации при восстановлении plain-text SQL-дампов.​

➡️Суть проблемы

Функция has_meta_commands() в pgAdmin использовала regex-паттерн (^|\\n)[ \\t]*\\ для блокировки опасных psql-метакоманд в загружаемых SQL-файлах:

\! — для shell-команд,
\copy ... PROGRAM — для запуска процессов,
\include — для включения файлов.

Проблема в том, что регулярное выражение ищет последовательность «начало строки или newline (\n) → опциональные пробелы/табы → backslash (\)», но не учитывает CR, carriage return (\r). Если поместить последовательность ‘\n\r\! команда’ в SQL-дамп, regex не сработает из-за символа \r между \n. А вот утилита psql проигнорирует CR и исполнит строку как валидную метакоманду.​

➡️Пример атаки

Атакующий создает вредоносный SQL-дамп, используя CRLF-последовательность для обхода валидации.

CREATE TABLE test (id int);
\n\r\! /bin/sh -c "команда"
INSERT INTO test VALUES (1);

Между \n (новая строка) и \ (начало команды) должен быть вставлен \r (carriage return), который делает паттерн невидимым для regex-фильтра pgAdmin.

Далее:
▪️Атакующий логинится в pgAdmin с низкими привилегиями.
▪️Через интерфейс pgAdmin загружает crafted SQL-файл в функцию Plain Text Restore.
▪️Функция has_meta_commands() проверяет файл regex-паттерном, не находит совпадений из-за CR-символа и пропускает файл как безопасный​.
▪️pgAdmin запускает psql для восстановления БД, передавая содержимое файла.
▪️psql интерпретирует \n\r\! как валидную метакоманду \!, игнорируя CR, и выполняет shell-команду с правами процесса pgAdmin на хосте.

По итогу атакующий получает RCE на сервере с правами, под которыми запущен pgAdmin, с возможностью чтения данных, изменения конфигурации и дальнейшего продвижения по сети.

В качестве решения в версии 9.11 валидация заменена на флаг --restrict при запуске psql. Он аппаратно блокирует метакоманды.

⚡️⚡️⚡️ Есть PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч