Например, если в приложении есть SQL Injection, то найдя ее, взломщик просто отдает запрос SELECT * FROM customers; и получает список всех клиентов с паролями. Он может это сделать, потому что язык SQL дает такую возможность. Хотя с точки зрения безопасности, фронтенду именно такая опасная операция никогда не нужна (но нужен доступ к табл. customers).
Есть куча решений:
1) СУБД дает такую возможность. Но совсем не обязательно, чтобы у пользователя SQL, используемого фронтендом был доступ к таблице customers, где хранятся пароли. К другим таблицам - пожалуйста. К этой - нет. Проверка паролей - только через отдельный сервер типа oAuth.
2) В СУБД есть куча тонких настроек ограничений доступа, даже если вам нужно дать доступ к таблице customers, где хранятся пароли.
https://www.postgresql.org/docs/10/ddl-rowsecurity.html
https://docs.microsoft.com/en-us/sql/relational-da...
3) Пароли хранить не нужно. Достаточно хранить "подсоленый хэш". Получение соленых хешей ничего не даст.
https://habr.com/en/post/145648/
https://habr.com/en/post/210760/
https://habr.com/en/post/145667/
https://habr.com/en/post/39079/
4) Есть специализированные БД, для хранения секретов.
Они, в отличие от обычных СУБД. невкрываемы, даже если злоумышленник утащит все файлы СУБД.
Также они позволяют вести аудит.
Также позволяют организовывать отзыв паролей и т.п.
Полностью задачу решить, понятно, нельзя, так как если злоумышленник проникнет внутрь и получит токен для доступа к данным, то до самих данных он доберется и тут.
Но хотя бы этот доступ будет ограниченным во времени.
https://habr.com/en/company/oleg-bunin/blog/438740/
https://habr.com/en/post/306812/
5) Можно вообще не хранить пароли в обычном виде в СУБД, а передавать их в приложение при старте через переменные среды окружение.
И пр.
И т.п.
6) Ограничение простого перебора. Исключить использование идентификаторов вида 1, 2, 3, 4, 5. А использовать что то вроде 0xF6C0F6C5430DC8904F60ABE822345200 и добавить throttling, чтобы ограничить скорость перебора. Уже не говоря о жесткой блокировке по IP при слишком большом количестве попыток перебора.
7) А с чего это ему хоть что то отдастся при таком запросе?
взломщик просто отдает запрос SELECT * FROM customers; и получает список всех клиентов с паролями
А зачем ваш бэкенд вообще по чьей либо указке выполняет непредусмотренный запрос? У меня вон в коде и предусмотренные запросы не так просто заставить выполнить. Выполняются только в строгих рамках разрешенного и предусмотренного при разработке.
SQL Injection вообще невозможен при современном подходе, кода выполняется только то, что предусмотрено; когда используются современные фреймворки и современные библиотеки, где всё фильтруется на несколько раз.
Ваш пример - это что-то из 2000-2010-х годов. Давно уже подобный код, разрешающий всё не практикуется.
Хотя, программисты конечно разные бывают....
Короче, методов защиты очень и очень много.
Тут дело вовсе не в специальной СУБД.
Так как и к ней можно получить доступ.
Дело в принципе - разделяй и властвуй.
Чтобы даже где-то что то получив, злоумышленник не смог сделать много вредного.
Средний
Средний
Средний
