Действительно ли стоит для запутывания веб-приложения Java? [закрытый]

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

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

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

Вы можете найти ответы на Вы скрываете свой коммерческий код Java? актуальными.

IMO, №

Существует два основных варианта использования обфускации:

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

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

Для описанных выше вариантов использования лучшими альтернативами обфускации являются:

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

Стоит ли обфускировать веб-приложение Java?

Это зависит от

и почему?

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

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

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

Абсолютно да.

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

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

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

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

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

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

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

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

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