Извлечение списка таблиц и колонок: Глазами хакера

Кульминация разведки — это получение полной схемы данных вашего проекта. Используя уже знакомый нам UNION SELECT в связке с системными таблицами, хакер шаг за шагом «отрисовывает» структуру базы: от имен администраторов до названий секретных конфигурационных полей.

Для Go-разработчика это упражнение особенно важно, потому что миграции (golang-migrate, goose, встроенные в gorm) пишутся как удобочитаемые SQL-файлы — CREATE TABLE users (id SERIAL, email TEXT, password_hash TEXT). Эти же имена попадают в information_schema.columns один-в-один. Атакующий, который зашёл через blind-инъекцию на эндпоинте /api/products?cat=..., через несколько минут будет знать имена всех таблиц, всех колонок, типы данных и даже nullable-статус. Бэкенд-команда узнаёт, что произошёл pen-test, только из firewall-логов через несколько часов.

Пройдем этот путь от лица атакующего: от первого запроса к списку таблиц до детального анализа структуры таблицы users. Аналогия — взлом сейфа: первые 10 минут уходят не на сам сейф, а на изучение чертежей здания, расположения охраны, типа замка. Так же атакующий тратит первые часы атаки на разведку схемы, а не на эксфильтрацию данных.

---

1. Шаг 1: Получение списка всех пользовательских таблиц

Хакер знает, что в information_schema.tables есть всё. Его задача — отфильтровать системные таблицы (pg_catalog.*, information_schema.*) и оставить только ваши прикладные. Фильтр WHERE table_schema='public' для PostgreSQL отсекает шум — остаётся только то, что вы сами создавали миграциями.

' UNION SELECT table_name, NULL, NULL FROM information_schema.tables WHERE table_schema='public'--

Результат на странице Go-приложения: products, categories, users, invoices, site_settings. Хакер видит: "Ага, таблица users — самая интересная!". Особо приоритетные для атакующего таблицы — те, чьи имена содержат auth, token, secret, payment, credit, key, admin. Если ваш проект использует sane-naming через миграции, эти слова часто попадают в имена напрямую (oauth_refresh_tokens, payment_methods, api_keys). Это удобно для разработчиков, но и для атакующих тоже.

---

2. Шаг 2: Извлечение колонок для таблицы "users"

Теперь хакер хочет знать, какие поля есть у пользователей. Здесь шаг разведки — это не «может быть полезно», а «обязательный preflight перед эксфильтрацией»: без знания имён колонок нельзя написать корректный SELECT username, password_hash FROM users. Атакующий не угадывает; он смотрит в information_schema.columns и получает гарантированно правильный список.

' UNION SELECT column_name, data_type, NULL FROM information_schema.columns WHERE table_name='users'--

Результат на странице Go-приложения:

• id (integer)
• username (text)
• password_hash (text)
• email (text)
• is_admin (boolean)

---

3. Шаг 3: Как это выглядит в логах SQL (PostgreSQL)

Если администратор смотрит логи postgresql.csv (включаемые через log_statement = 'all' или log_min_duration_statement = 100), он увидит этот гигантский и странный запрос. Это критический момент для defensive security: между моментом разведки и моментом эксфильтрации у вас есть от нескольких минут до нескольких часов. Если у вас есть log-aggregation (Loki, Elasticsearch) и alert на information_schema в SQL-логах — атаку можно остановить до утечки данных.

SELECT ... WHERE category = '' UNION SELECT table_name, NULL, NULL FROM information_schema.tables WHERE table_schema='public'--'

Это 100% доказательство того, что структура вашей базы была успешно извлечена.

---

4. Карта сокровищ: Что ищет хакер

Хакеры ищут следующие паттерны в именах таблиц:

Имя таблицы (паттерн)	Описание
users, accounts, clients	Личные данные, логины
pass, pwd, secret, hash	Колонки с паролями
config, settings, env	Настройки, ключи API
admin, is_admin, role	Данные для повышения привилегий

---

Прозрачность структуры делает данные беззащитными. Если злоумышленник составил карту вашей базы, полная утечка — это лишь вопрос времени. Compliance-стандарты (PCI-DSS 6.5.1, OWASP A03:2021 #3, CWE-89) требуют не «уметь обнаружить SQLi», а в принципе исключить такой класс уязвимости через параметризацию. Это формальное требование, проверяемое аудиторами, и невыполнение — основание для штрафов.

Но что, если мы ограничим возможности самого хакера на уровне настроек самой СУБД? Перейдем к изучению концепции «наименьших привилегий». Если ваш сервис-юзер app_user имеет только SELECT, INSERT, UPDATE на конкретные таблицы и REVOKE ALL ON information_schema.*, разведка через information_schema упрётся в permission denied — атакующий потратит часы на обход, а не минуты на эксфильтрацию.