Товарищ-программист использовал худшие практики программирования

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

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

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

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

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

Оригинал: Что говорит твой босс? Узнай - сделай это.

Меня попросили уточнить вышеизложенное:

Прежде всего, я думаю, что у вас более одной дилеммы:

• Стоит ли "исправлять" чужой код?
• Является ли реализация (далее А) других лиц достаточно плохой, чтобы ее можно было заменить чем-то другим?
• Будет ли лучше использовать обфускатор (от B) для этого «встраивания лицензирования в наше приложение»?

Прежде всего, видно из бизнес - кейса проблема IS решена. А на месте и, скорее всего, является «достаточно хорошим» решением проблемы. Ваша компания может быть довольна тем, что она в основном защищена настолько, что для ее разрушения необходимы преднамеренные усилия.

Это означает, что даже если вам это не нравится (и, поверьте мне, в вашей карьере вы увидите намного хуже ), оно делает то, что нужно. Следовательно, когда проблема решена, вы не должны «просто делать это», а скорее убедить человека, который отвечает за назначение вашей работы, в долгосрочной перспективеЦена этой реализации будет достаточно высокой, чтобы гарантировать откат и выбор обфускатора акций. Это потребует от вас небольшой подготовки, а также обратите внимание, что у обфускаторов есть и недостатки, о которых вам нужно знать (другие ответы хорошо освещают это). Например, трассировки стека не могут быть сразу использованы и т. Д. Все зависит от того, насколько важно избежать пиратства. Обратите внимание, что сложнее всего сломать те, которые требуют аппаратных ключей для работы и, скорее всего, дороже, чем вашим клиентам.

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

Другими словами: что говорит твой босс? Узнай - сделай это.

Также обратите внимание, что это было бы иначе, если бы вы подняли вопрос ранее, чтобы потраченные впустую деньги за время, потраченное на внедрение A, были меньше. Другими словами, когда должен был быть сделан выбор между А и В.

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

Надеюсь, это проясняет мою точку зрения.

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

Нет , возвращаться за кем-то и изменять код, за который он несет ответственность, было бы более серьезным нарушением, чем сначала писать сомнительный код.

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

Был ли какой-либо официальный обзор кода - или у вас было неофициальное «рассмотрение кода»? Я бы сказал, что, поскольку это деликатная и важная тема, такая как безопасность и лицензирование, вам необходимо поднять эту цепочку. Вы сделали первую часть - противостояние программисту. Тем не менее, теперь, когда он не слушает, вы можете / должны поднять его. Если вы этого не сделаете, вы можете быть частью проблемы.

Я бы сказал ему, что вы собираетесь это сделать - это МОЖЕТ изменить его мнение. Если этого не произойдет, напишите очень политически корректное, но в то же время точное и сжатое электронное письмо о ситуации своему боссу и CC программисту. В электронном письме попросите о встрече между вами и / или любой другой участвующей стороной.

Всегда встречайте эти вещи в прямом эфире - но политически и по-дружески.

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

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

Может ли он продемонстрировать, что такой взлом возможен, или это всего лишь гипотетический сценарий, который его как бы беспокоит? Может ли он дать живую демонстрацию этой работы? Он должен попробовать. Шутки в сторону. Если это работает, его следует представить руководству, а затем предложить приобрести обфускатор.

Если обфускатор недостаточно безопасен, вы рассматривали другие способы защиты JAR, возможно, что-то вроде шифрования или компиляции в нативный код?

RE: переделка своего кода: это просто вопрос переименования? Многие IDE имеют инструменты рефакторинга, которые могут сделать это довольно легко.

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

Ваша проблема в том, как защитить ваш IP. Найти решение для этого: обфускаторы, сервер лицензий и т. Д.

Я столкнулся с подобной проблемой, когда другой разработчик назвал наши процедуры шифрования / дешифрования str__copyи str__delete(обратите внимание на второе подчеркивание). Это было неубедительно и могло быть сделано лучше, поэтому мы подождали, пока не появится история, где необходимо обновить лицензирование. У менеджмента не было проблем с дополнительными часами, потому что мы описали это как «очистку, поэтому в следующий раз, когда мы перейдем к лицензированию, это займет меньше времени и будет более безопасным». Проблема решена, без обид чувства.

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

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

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

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

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

«Не будь самым лучшим профессионалом, чтобы знать о проблеме».

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

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

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

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

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

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