Сколько бы ты ни вешал замков на фронтенд, если MySQL открыт как сарай в деревне — утекут все. Пароли, имейлы, транзакции, даже твой admin123. И не обязательно быть хакером, чтобы это сделать. Достаточно открыть phpMyAdmin без пароля или забыть одну кавычку в запросе. Вот тебе список классики жанра — как ломают базы и как не дать им повода.
1. Пароли в открытом виде
Если ты хранишь пароли в plain text — ты не разработчик, ты поставщик утечек.
Пароли надо хэшировать. Не md5, не sha1, а нормальными алгоритмами: bcrypt, argon2, scrypt. Даже если базу сольют — взломать хэши будет не за 2 минуты. А если ты ещё добавляешь соль — вообще красавчик.
2. Базы на дефолтных логинах и паролях
Логин
root, парольroot, порт открыт — привет, взлом за 5 секунд.
Поменяй логин. Сделай сложный пароль. И не надо пускать в базу всех подряд. Один пользователь — одна задача. Не давай ALL PRIVILEGES, если не надо. Не надо делать базу общагой.
3. Один пользователь на все базы
Хуже, чем root на проде, только один и тот же пользователь на тесте, деве и проде. Нарушение изоляции, конфиденциальности и здравого смысла.
- Создай отдельного пользователя на каждую базу.
- Дай минимум прав.
- Не мешай стейдж с продом.
4. Удалённый доступ к базе — включён
Почему бы не открыть 3306 наружу, правда?
Если ты разворачиваешь прод и не отключаешь удалённый доступ — ты как минимум ленив, как максимум — безалаберен.
Работай через localhost или UNIX-сокет. Если уж нужен доступ снаружи — только по VPN, с фильтрацией IP и отдельным пользователем с минимальными правами.
5. Нет резервных копий
Нет бэкапа — нет данных. Всё просто.
Бэкапы — как страховка. Надо делать регулярно. Лучше — автоматизированно. Лучше — на отдельный сервер. Лучше — с проверкой, что они вообще восстанавливаются.
И нет, mysqldump раз в полгода на локальный ноутбук — не считается.
6. Бэкап с сюрпризом
Сделал бэкап, восстановил — а там уже троян.
Проверяй бэкапы на наличие лишнего. Особенно если база уже была взломана. Бывает, в дамп вставляют вредоносный SQL или загрузчики в виде "бессмысленных" строк.
7. SQL-инъекции
Ну это вообще классика. До сих пор живёт.
Если ты всё ещё лепишь запросы через конкатенацию и $_GET — тебя давно взломали. Используй PDO. Используй placeholder’ы. Не будь человеком, из-за которого 5000 пользователей потеряли доступ к аккаунтам.
$db->prepare('SELECT * FROM users WHERE email = :email')->execute(['email' => $email]);
Вот так — правильно. Конкатенация с кавычками — в мусор.
8. Код — на коленке
Говнокод приводит к дыркам. Всегда.
Чем хуже код — тем больше уязвимостей. Самописные админки, неэкранированные поля, уязвимые CMS, открытые endpoints. Не обязательно быть пентестером, чтобы понять: если код писался в пятницу вечером под пиво — ждать беды.
Используй инструменты статического анализа, чекай логи, запускай сканеры уязвимостей (тот же Nikto или что-то серьёзнее).
Что делать?
- Приведи пользователей и права в порядок.
- Отключи удалённый доступ.
- Делай бэкапы и храни их нормально.
- Хэшируй пароли.
- Используй PDO.
- И выключи уже phpMyAdmin с дефолтными настройками.
Вместо вывода
MySQL сам по себе не ломается. Его ломают. Точнее, ты его ломаешь — своей ленью и “на прод потом поправим”. Не надо так. Утечка — это не если, а когда.
И да, если ты читаешь это и думаешь: «У меня всё нормально», — просто зайди и проверь. Прямо сейчас.
Слишком широкии привелегии на учетные записи тоже часто могут быть причиной взлома. И не следует светить рута.
Через SQL-инъекцию взламывают, через js и html инъекции суют в код, подбор паролей, либо какие-то еще атаки. Способов очень много.
Взломать базу mysql могут через sql-иньекцию, либо часто самописные cms на php взламывают. Главное все входные параметры фильтровать и валидация обязательно должна быть.
Технологий и способов взлома базы данных уйма. А по защите все банально просто - нужно читать офф маны по настройке. Во всех современных доках есть разделы где объясняется как улучшить безопасность бд.