Как безопасные соединения с базой данных обычно реализуются в файлах JAR?

Question

Я не Java-разработчик, но мой клиент нанял один для обновления некоторых JAR-файлов на своем сайте.Перед этим мы провели аудит существующего кода и обнаружили ряд уязвимостей в безопасности.Одним из решений, которое мы использовали для повышения безопасности файлов, является создание нового пользователя базы данных с доступом только для чтения к базе данных и только для тех таблиц, для работы которых необходимы файлы JAR.Затем я обнаружил, что они хранят эти учетные данные в виде простых текстовых файлов вместе с файлами JAR, только в догадках от широкой публики.И, наконец, сегодня они требуют гораздо более слабых привилегий базы данных, но я не думаю, что она понимает, что им действительно не нужны они для правильно написанного файла JAR.

В любом случае, я почти уверен, что этот разработчикне знал бы уязвимости безопасности, если бы она укусила ее сзади.И я не знаю достаточно о файлах Java / JAR, чтобы правильно посоветовать ей, что она должна делать, достаточно только о infosec, чтобы сказать ей, что она не должна делать.

Итак, каковы типичные соображения безопасности при записи распределенного файла JAR, который подключается к удаленной базе данных MySQL?Существует ли стандартный способ шифрования информации о соединении (имя пользователя и / или пароль)?IIRC, разве файлы .jar не прославляют ZIP-архивы, и не может ли кто-нибудь для этого распаковать файл и просмотреть сведения о соединении в исходном коде?Есть ли способ зашифровать содержимое файла JAR?

---

ОБНОВЛЕНИЕ: Я получил следующее разъяснение от разработчика.Это звучит правильно?

Все классы в файле jar зашифрованы.Я всегда шифровал все файлы классов, прежде чем архивировать их в файл JAR.если вы откроете любой [отредактированный] флягу, вы увидите только зашифрованный код.так что у пользователя нет шансов увидеть исходный код, декомпилировав классифицированный.классы используют jdbc для подключения к БД, поисковому серверу нужно подключиться к БД для запуска sqls.Эти sqls находятся в зашифрованном виде в файле jar.

Когда я спросил вас о шифровании пароля БД, я имел в виду то, что вы говорите ниже.мы напишем код шифрования / дешифрования в java и будем его использовать.Скомпилированный класс из этого исходного кода снова будет зашифрован как часть процедуры шифрования класса процедуры.Мы используем инструмент обфускации Java Retroguard для шифрования всех классов.мы также встраиваем ключ в html-страницу, чтобы убедиться, что приложение будет работать, только если оно было загружено с [отредактированного] веб-сайта.если пользователь скопирует jar на свой локальный компьютер и попытается запустить его, произойдет сбой.

Answer 1

Да, JAR - это просто ZIP-файлы, поэтому можно полностью открыть один из них с помощью WinZip и просмотреть его содержимое. Если вы знаете, что делаете, вы можете найти простой текстовый пароль внутри.

Похоже, ваш JAR содержит клиент, который подключается напрямую к базе данных. Вы не говорите, делается ли это через Интернет, VPN или локальную сеть. База данных развернута удаленно с клиента?

Это одна из причин, по которой клиент-серверные приложения исчезли: их трудно защитить через Интернет.

Ваше приложение для меня звучит как классический клиент-сервер. Имею ли я это право?

Средний уровень обычно вводится между клиентом и базой данных для проверки безопасности, проверки и привязки входных данных и передачи запросов соответствующему обработчику для выполнения. Попросите пользователей представить учетные данные, которые ваш средний уровень должен проверить, прежде чем передавать их в базу данных.

Он также может дать вам шанс противостоять атакам SQL-инъекций.

Если вы зашифруете содержимое JAR, вам придется написать собственный загрузчик классов, чтобы расшифровать их при загрузке. Не для слабонервных.

Если ваш клиент - приложение Swing, со всей логикой и базами данных, встроенными в слушатели и обработчики событий, зарегистрированные для каждого компонента, у вас будет серьезная перезапись. Вы перейдете к более сервисно-ориентированной архитектуре, где вся работа выполняется службами на стороне сервера. Клиент делает только то, что он должен в классическом MVC: передавать события на сервер и отображать результаты. Ваш клиент будет намного легче.

Это станет самым большим шоком для вашей команды разработчиков и бизнеса.

Answer 2

Я начну свой ответ с того, что часто заявляю: «любой человек может создать схему безопасности, которую он / она не может нарушить».

Теперь, принимая к сведению обновление, в котором упоминается шифрование иОбфускация производится в том же обновлении, было бы целесообразно отметить, что шифрование не то же самое, что обфускация.Технически, шифрование предполагает использование ключа для преобразования некоторого открытого текста в зашифрованный, причем открытый текст можно восстановить только при знании исходного ключа.Обфускация по определению нигде не близка к шифрованию - она ​​включает в себя удаление информации из исполняемого исходного кода, что делает исполняемый файл предположительно «трудным» для обратного инжиниринга.Обычно запутывание включает в себя замену символов более мелкими, а иногда и переупорядочение исходного кода, что затрудняет чтение исходного кода с обратной инженерией, сохраняя при этом профиль выполнения оригинала (обфусцированный исходный код имеет тот же код и пути потока данныхкак оригинал).

Важным здесь является тот факт, что пароль закодирован в исходном коде.Разумно предположить, что обфусцированный исходный код также будет содержать жестко закодированный пароль.Это предположение является разумным, поскольку большинство обфускаторов никогда не пытались изменить пул констант в файле класса - мутирование пулов констант опасно, поскольку может привести к изменениям в поведении во время выполнения.Если пароль был жестко запрограммирован в исходном коде в виде строки, то файл класса (обфусцированный или нет) будет иметь пароль в строковом пуле констант , который будет загружен в память JVM(без процесса дешифрования или декодирования между ними). ​​

Лучшая практика в этом случае - заставить конечных пользователей указывать идентификатор пользователя базы данных и пароль (если они управляют настройкой приложения), чтобынадежно храните предоставленные пользователем учетные данные (это зависит от характера приложения; приложения Java EE должны пытаться заставить контейнер управлять этими учетными данными) и надежно управляйте этими учетными данными, когда они извлекаются из безопасного хранилища.Возможно, вы захотите взглянуть на статью OWASP по Небезопасное хранилище для получения дополнительных указателей.

Учитывая использование апплета, не рекомендуется иметь идентификатор пользователя базы данных и пароль вапплет.Это необходимо сделать по разным причинам - хорошие приложения позволяют изменять идентификатор пользователя базы данных и пароль с помощью простых изменений конфигурации приложения.Жесткое кодирование пароля в исходном коде связано с увеличением накладных расходов на управление;вам может потребоваться, чтобы конечные пользователи очищали свой кэш Java-апплета каждый раз, когда администратор БД решает сменить пароль (и это должно происходить иногда в нормальном дата-центре).Кроме того, вам также может потребоваться защита от блокировки учетной записи базы данных при развертывании изменений в апплете.Как и другие опубликованные рекомендации, было бы целесообразно управлять соединениями с базой данных из среднего уровня.

Answer 3

Я думаю, для большинства разработчиков условием является сохранение файла конфигурации вне корневого каталога.Конечно, если это настольное приложение, а не веб, это невозможно.Что-то, что я делал раньше в основанном на SWING приложении MySQL с ограниченным числом пользователей, вместо того, чтобы использовать средний уровень для аутентификации и представления данных в качестве службы, используя встроенную аутентификацию MySQL, чтобы вся безопасность была определена всхема, а затем дублирование настроек разрешений для каждого пользователя.Вид хакерского, но надежного подхода.

Answer 4

Проще говоря, это (я думаю) серьезно уязвимо. Действительно, можно извлечь банку и прочитать то, что написано в этом простом тексте.

Если использование jar является обязательным, я рекомендую создать класс (просто простой класс), который содержит имя пользователя, пароль, URL и т. Д. С ключевым словом final. Хотя этот метод не очень безопасен, по крайней мере, скомпилированный класс не может быть легко прочитан. Другое преимущество (или, возможно, недостаток) заключается в том, что «жестко запрограммированные» свойства соединения не могут быть легко изменены. Даже если у вас есть исходный код, вам все равно придется его перекомпилировать и повторно собрать.