Задать вопрос

Как могут взломать базу данных MySQL?

Здравствуйте.
Как могут взломать базу данных?
Вот, к примеру, ее взломали, некоторые пишут, что надо хэшировать пароли, чтобы не было доступа к аккаунтам. Но есть-ли смысл? Ведь если БД взломана - можно накрутить себе что душе угодно, или же, удалить все и сразу.
  • Вопрос задан
  • 8392 просмотра
Подписаться 21 Средний 4 комментария
Решения вопроса 2
@Z1odeypnd
Здравствуйте.
Технологий взлома уйма.
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCTS.
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:
GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';

И т.п. По принципу "Разделяй и властвуй."
4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций.
Пример:
$DB->select('SELECT * FROM tbl WHERE a=? AND b=?', $a, $b);

5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты.
6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).
Ответ написан
@BorisKorobkov Куратор тега MySQL
Web developer
  1. Через SQL-инъекцию (выполнить любой SQL). Если посмотреть в вопросах Тостера выложенный код, то в половине случаев там полно уязвимостей. Для защиты надо как минимум использовать PDO.
  2. Другой вариант - через JS/HTML-инъекцию (засунуть на страницу зловред и украсть пароль админа).
  3. Подобрать пароль админа.
  4. Есть еще много других способов.

Что делать? Писать не-говнокод. Изучать все эти методы. Использовать тестирование, сканеры уязвимостей.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@mirzok
Information Security
Взломать могут через web-приложение, найдя SQL-инъекцию в коде. Это часто бывает в самописных CMS на PHP, где пренебрегают использованием синтаксиса параметров для запроса и делают простое сложение строк.

Есть подозрение, что взломали? Проверьте свой код, проверьте своё приложение. Для этого каждый URL, где есть какие-либо параметры, прогоните через sqlmap - специальная программа для поиска таких уязвимостей. Если не поможет или слишком долго, то попробуйте онлайн сканерами вроде metascan.ru и detectify.com.

И самое банальное - меняйте пароли доступа и делайте ограничение на вход по порту 3306 (mysql), если есть такая возможность.
Ответ написан
Комментировать
@mickvav
Programmer, system and network administrator
Смотрите ответы выше - всё правду говорят, мудрые.
Добавлю ещё из опыта - мне тут попалась конфигурация с смотрящим в 0.0.0.0/0 бэкендом. Не делайте так. Лучше к базе (как таковой) из инета вообще никого не пускать. Фаерволом.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы