Стоит ли запутывать веб-приложение java?

Question

Стоит ли запутывать веб-приложение java? и почему?

Answer 1

№ Код хранится на сервере, где внешние пользователи (надеюсь) не имеют к нему доступа. Возможно, вам захочется запутать JavaScript, если вы считаете, что это стоит (минимальной) защиты IP.

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

Answer 2

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

Answer 3

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

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

Answer 4

IMO, no.

Есть два основные сценарии использования для запутывания:

1. для защиты контроля доступа «секретов» (например, пароли), встроенные в коде, и
2. для защиты от кого-то кражи вашей «интеллектуальной собственности» ,

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

Для сценариев использования выше, лучше альтернатив запутываний являются:

1. просто не встраивать секреты в коде, и
2. один или оба из следующих действий:
   • безопасные ваши веб-серверы, чтобы хакеры не могли получить код, и
   • не отправляйте код, который вы считаете ценным IP-адресом, или если вы это делаете, тогда отправляйте только код для людей, подписавших юридически обязывающий договор/лицензионное соглашение го при защите ваших прав на IP.

Answer 5

Вы можете найти ответы на Do you obfuscate your commercial Java code? актуальны.

Answer 6

Стоит ли запутывать веб-приложение java?

Это зависит

и почему?

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

Если вы подаете заявку на свое веб-приложение, и установка доступна только от вас, я бы сказал, что не стоит. Лучше было бы увеличить чистую безопасность.

^{* см Стивен C комментарий}

Answer 7

Это хорошая идея, чтобы скрыть ваш сервер кода на стороне? Я бы дал безоговорочное ДА.

Реальность такова, что end user - это только одна группа, которая может иметь гнусные планы. Слишком часто internal сотрудники, независимо от того, являются ли они business users, support staff и т. Д., Также могут иметь свои собственные планы .. или сделаны unwittingaccomplices.

Если вы имеете дело с ЛЮБОЙ информацией, которая требует доступа к паролю, то у вас есть долг, чтобы использовать все имеющиеся в вашем распоряжении инструменты, чтобы защитить эту информацию.

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

Итак, опять-таки, один шаг состоит в том, чтобы запутывать в надежде, что тот, кто приобретет бинарные файлы, усложнит процесс работы вашего приложения. Конечно, вы должны пойти намного дальше, защищая серверы, на которых он живет; и не только production, но и обратно до source control.

Answer 8

Абсолютно верно.

Если ваш процесс разработки верен, на сервере должны быть только двоичные файлы и некоторые файлы поддержки (например, разметка и таблицы стилей). Нет веской причины для не obfuscate двоичные файлы в любой производственной среде.

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

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

Я еще не слышал каких-либо практических примеров обфускации на стороне сервера, вызывающих проблемы с развитием или административными проблемами.