 |
Ты высказали свою позицию чрезвычайно хорошо!
Сегодня хочется затронуть тему Хакеры профессионалы!
Как могут взломать базу данных MySQL?
Здравствуйте. Как могут взломать базу данных? Вот, к примеру, ее взломали, некоторые пишут, что надо хэшировать пароли, чтобы не было доступа к аккаунтам. Но есть-ли смысл? Ведь если БД взломана - можно накрутить себе что душе угодно, или же, удалить все и сразу.
Вопрос задан более трёх лет назад 6930 просмотров.
Средний 4 комментария.
Разработчиков, которые хранят пароли в открытом виде или в виде md5 хэша на продакшене кроме КРАЙНЕ-ОЧЕНЬ-КРАЙНЕ особенных ситуаций, нужно предавать анафеме.
Roman Kitaev, расскажите про md5 хеш чем он плох? я его использую, подмешивая конечно соль из конфига. что-то нужно по-другому делать?
Максим Федоров, в гугле можно много статей найти про взлом md5: радужные таблицы, коллизии и прочие забавные штуки. Сейчас взлом md5, в общем, не составляет большого труда. Солёный тоже. ??спользовать стоит PBKDF2, scrypt или новомодный Argon2.
P.S. ??х также солят и итерируют десятки-сотни тысяч раз.
Roman Kitaev, про радужные таблицы верно подмечено. но это если просто md5 а вот md5(md5 + динамическая соль вполне защищённо даже в данный момент актуально.
Здравствуйте. Технологий взлома уйма. В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много. Если он получил доступ только на чтение, то захешированные в 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. Пример:
?? т.п. По принципу "Разделяй и властвуй." 4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций. Пример:
5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты. 6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).
Можете пояснить про разделение прав подробнее? То есть мне в коде придется делать несколько подключений к БД?
Удаление негатива в сети
Контакты:
XRoom@protonmail.com
Я люблю перечитываю ваш веб-сайт. Огромное спасибо!
|
