2012-01-08 3 views
-1

Мое приложение написано с использованием: Embarcadero Delphi 2010
У меня есть форма с именем INCLUDEFORM, которую я включил во все другие формы, эта форма содержит TSQLQuery и TSQLConnection, которые содержат сведения о соединении с базой данных (db host, db name, db user, и db pass), которые определены во время разработки.Как защитить данные подключения к базе данных от хакера ресурсов?

Вчера я установил программное обеспечение с именем (Resource Hacker), я попытался открыть приложение с помощью этого программного обеспечения, и когда я искал ресурсы, я видел все формы в своем приложении, включая includeform, я нажал в include формы, чтобы увидеть источник кода, и я увидел все детали источника кода и детали соединения daabase.

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


Возможно, можно зашифровать мой исходный код из Resource Hacke или, по крайней мере, код в INCLUDE FORM, который содержит важные сведения о соединении с базой данных.

Thankyou

+3

Вы не должны хранить свою строку подключения в форме. по крайней мере, вы можете определить константу или переменную и назначить ее компонентам строки соединения DB во время выполнения (ее также можно зашифровать). – kobik

+1

Вы должны предполагать, что любой должным образом компетентный злоумышленник может извлечь из него соединение db и защитить сервер соответственно. Я бы просто использовал эфир, если вы используете незашифрованное соединение с сервером и используете функцию шифрования (вероятно, библиотеку SSL), если вы это сделаете. Никакая обфускация на стороне клиента не защитит вас от этого. – CodesInChaos

+0

Dont борьба, релиз под GPL. – OnTheFly

ответ

2

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

Простые механизмы обфускации включают выполнение XOR строки. Более сложные методы, такие как шифрование, требуют добавления библиотек для выполнения шифрования/дешифрования.

Если вы просто пытаетесь защитить строку соединения, эти методы просты в достижении. Если вы пытаетесь выполнить полное обфускацию/шифрование данных формы, то использование пакетов, таких как UPX, является самым простым механизмом, но опять же тривиально работать.

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

Если вы действительно хотите, чтобы защитить подключение к базе данных, то вам необходимо иметь комбинацию имени пользователя/пароль для каждого пользователя, и требуют этих данных для ввода во время выполнения

0

Самый простой и дешевый способ UPX, но это также легче взломать. Это, однако, сделает все ваши ресурсы невидимыми для случайного просмотра.

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

+0

Thankyou, еще один вопрос: я сжал приложение, используя UPX, могу ли я сделать приложение все больше и больше defficault для распаковки с использованием другого компрессора. (сжимать приложение 2 или 3 раза с помощью разных компрессоров?) –

+6

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

+3

Downvoted, потому что даже не-программисты могут разобрать что-то просто с помощью универсального экстрактора или Pe.explorer, а затем проблема все еще существует – az01

5

Вы никогда не должны хранить данные подключения внутри приложения, тем более что они могут (и пароль) меняться. Вы можете:

  • Если ваша база данных позволяет это использовать, используйте аутентификацию операционной системы, клиент базы данных будет использовать токен безопасности пользователя процесса для аутентификации с базой данных.Oracle, SQL Server и другие имеют такую ​​функциональность.
  • Запросить информацию, когда пользователь подключается. Если вы сохраняете свой пользователь/пароль внутри исполняемого файла, у него вообще нет пользователя/пароля. В связи с этим вы можете установить базу данных с известным пользователем и без пароля, а уровень безопасности будет таким же.
  • Храните эти данные где-нибудь в зашифрованном виде. Конечно, теперь вы должны безопасно хранить ключ шифрования. Вы можете использовать средства шифрования Windows (которые могут шифровать/дешифровать данные с использованием учетной записи пользователя или машины), или вам (или вашему пользователю) необходимо правильно сохранить этот ключ.
+0

+1 - в дополнение к этим комментариям вы также можете создать службу, которая проверяет подлинность клиентов с помощью стандартных механизмов авторизации (basic/ssl и т. Д.), А служба хранит информацию БД. – bryanmac

+0

@bryanmac: вы просто перемещаете проблему в другое место. Люди, имеющие доступ к машине, на которой запущена служба, могут не иметь доступа к базе данных, и вам может потребоваться также защитить формы внутренних угроз. Более того, каждый пользователь будет использовать учетные данные службы (и разрешения), и это не всегда то, что вам нужно, вы можете захотеть, чтобы каждый пользователь вошел в систему со своей учетной записью по причинам безопасности и аудита. Вы можете перекодировать безопасность и аудит внутри приложения, но IMHO является опасным подходом, особенно когда более чем одному приложению может потребоваться доступ к тем же данным. –

+0

@idsandon - no - это избавляет вас от необходимости создавать логины и управлять разрешениями на уровне сервера базы данных. Все веб-серверы имеют стандартные/проверенные механизмы для auth (basic + ssl, ntlm, oath и т. Д.), Который дает вам идентификационную информацию, которую вы можете реализовать в своем приложении. Это позволяет вам изменять хранилище и хранилище данных, сохраняя при этом публичный протокол для вашего приложения. Служба поддерживает учетные записи БД в качестве настройки конфигурации, которая не отображается. Стандартная арка SaaS. – bryanmac

Смежные вопросы