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

37

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

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

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

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

Нил
источник
4
Если ваш вопрос касается того, как справиться с политикой этой ситуации, тогда многие ответы здесь указывают в правильном направлении, но если, как подсказывает ваш комментарий, вы действительно хотите предложить лучшую альтернативу, возможно, вы захотите проверить ответы на этот вопрос: stackoverflow.com/questions/6018215/…
Марк Бут
8
Если хакер, имеющий доступ к вашему чистому исходному коду, может взломать вашу аутентификацию, тогда это можно взломать, точка. Никакое запутывание не поможет. Если вы ищете решение, которое останавливает некоторых хакеров, то, помимо запутывания, вы также можете использовать некоторые из его методов неверного направления (скрывать вещи в маловероятных классах, которые нельзя легко заменить). Частые обновления, которые полностью изменяют вашу практику аутентификации, также помогают. Многие пользователи устают полагаться на хакеров и просто покупают их.
Билл К
2
Он переименовывал местных жителей? Если это так, он тратит свое время - они все равно не существуют как именованные переменные в скомпилированном коде.
Ник Джонсон
1
Это называется «запутывание», и хотя в наши дни его используют чаще, оно не является полным доказательством! .. хотя оно задержит взлом кода, его можно взломать! .. я хотел бы видеть компилятор это может зашифровать объектный код и выполняться только с правильным ключом, так что даже тот, у кого есть редактор диска, дизассемблер или любой другой инструмент для взлома, никогда не сможет сделать из него головы или хвосты!
Фрэнк Р.
6
«Его решение этой проблемы состояло в том, чтобы буквально неловко вызывать переменные и методы менее очевидными именами и помещать их в уже перегруженные классы, а не генерировать новые классы». и «сначала позвольте мне сказать, что он умный парень», не очень хорошо в том же пункте!
пожрала Элизиум

Ответы:

94

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

wolfgangsz
источник
31
+1 Запутывание - это НЕ безопасность, а просто одеяло комфорта.
uɐɪ
7
Если вы можете придумать лучшее решение, чем запутывание, я отмечу ваш ответ как правильный. Как вы можете гарантировать, что кто-то, имеющий доступ к файлу war, не сможет изменить его функциональность хотя бы для лицензий?
Нил
5
Вы не можете гарантировать это вообще, когда кто-то получил доступ к файлам. Но правда в том, что самый простой механизм предотвращает нанесение вреда вашему программному обеспечению 99,99% пользователей. Преданный и опытный хакер ВСЕГДА найдет способ обойти защиту приложений. Однако вы можете переключиться на удаленную проверку, поэтому ваша программа будет работать только при проверке подлинности на вашей службе. Для того, чтобы это было безопасно, вам нужно зашифровать всю программу и иметь какой-то загрузчик. НО: если у кого-то есть действительный ключ, он все равно может снова перепроектировать программное обеспечение.
Сокол
7
@Neil: реализовать основную бизнес-логику в микроконтроллере, подключенном как USB-ключ. Вы не сказали, что это должно быть дешево или просто для реализации;)
SF.
8
@SF:. Touche. Я думаю, что для одновременной связи должны быть задействованы три спутника, просто ради этого. ;)
Нейл
84

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


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

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

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

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

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

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

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

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

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

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


источник
8
Мой начальник не программист, и мне, вероятно, будет трудно объяснить, почему мы должны вкладывать время и деньги в то, что делает, что в конечном итоге никак не повлияет на поведение программы.
Нил
15
@Neil: ... так, может быть, пришло время познакомить вашего босса с понятием "расходы на обслуживание"?
SF.
21
Это станет ответом по умолчанию на каждый вопрос о коллегах или рабочей среде? Я знаю, что какой-то кусок должен был пойти и сказать вам, чтобы опубликовать это как ответ, но давай, это не ответ. На самом деле, это полу-приличный (хотя и неловко сформулированный) вопрос о проблемах с безопасностью из-за неясности; этот «ответ» обиден.
Ааронаут
8
@Aaronaught. Этот ответ доходит до мозга костей, когда он «реализация A плохая, я предлагаю сделать реализацию B», потому что необходимо выполнить дополнительную работу (приравнивая деньги). Если бы это был выбор между реализацией A или B, ответ был бы другим. Я предлагаю вам открыть вопрос по мета, если вы хотите более подробный ответ.
22
«Это станет ответом по умолчанию на каждый вопрос о коллегах или рабочей среде?» Почему бы нет? Если это было сформулировано как технический вопрос. Например, «Что лучше - Автоматическая запутывание против запутывания (= плохая практика)», то это совершенно другой вопрос, и он требует технического обсуждения. Все "Должен ли я исправить это за спиной моих коллег?" вопросы в конечном итоге сводятся к «Нет, довести это до сведения команды / высшей власти»
Binary Worrier
13

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

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

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

DKnight
источник
Потом, когда я буду ловить рыбу в будущем на этих уроках, думаю, я просто буду держать нос.
Нил
3
Если у вас есть прямая ответственность за этот код, тогда изменение его по своему вкусу - это хорошо, но если есть совместная ответственность, вам понадобится кто-то для арбитража. Легко повредить рабочие отношения и тратить время на подобные ситуации, лучше, если возможно, не ставить это под вопрос. Если нужно решить проблему, уберите ее как можно скорее.
DKnight
6

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

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

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

Catchops
источник
Конечно, похвальный подход. Я сам заметил изменение кода, обновляя мой код из SVN. Хотя, скорее всего, если он не согласен, то убедить моего босса принять эти меры безопасности, скорее всего, не приведет к каким-либо изменениям, поскольку программист может утверждать, что это уже «работает».
Нил
2

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

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

user281377
источник
1
Я не могу сказать вам, насколько это беспокоит меня, хотя вы, вероятно, правы, что мне придется с этим смириться.
Нейл
2

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

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

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

FrustratedWithFormsDesigner
источник
Он кажется мне немного параноиком, хотя я понимаю почему. Если бы продукт был взломан, это, вероятно, означало бы его работу. Я не скажу, что это возможно, но я знаю достаточно, чтобы знать, как вы можете искать имена методов, и если бы существовал очевидный метод с именем «isLicenseValid», было бы вопросом написания класса, который имеет этот метод и всегда возвращает true для взломать это. Я думаю, что эта программа достаточно сложна, не усложняя ее, хотя он, кажется, хочет быть в этом уверенным. Я думаю, я мог бы легко исправить его код, переименовав его, да.
Нейл
Тот факт, что у вас есть метод isLicenseValid, не означает, что его можно взломать, просто написав класс тем же методом. Если вы пометите свой класс как «запечатанный» (это синтаксис C #), то третьи стороны не смогут просто обойти ваши проверки безопасности, написав подклассы и переопределив ваш метод. В любом случае, если этот парень не является сотрудником службы безопасности компании, почему это означает его работу, если продукт взломан?
Tundey
2
@Tundey, это не вопрос подклассов (как они будут загружены?): Это вопрос написания того же класса и внесения взломанной версии ранее в список поиска пути к классам.
Питер Тейлор
1
Я помню радости загрузки классов в Java. Тем не менее, должен быть лучший способ смягчить это. На самом деле, если ваш загрузчик классов не скомпрометирован, как кто-то может написать класс, который совпадает с вашим классом? Особенно, если ваш JAR подписан? Разве подписание ваших JAR-файлов и закрытие ваших классов не решит проблему, когда кто-то напишет класс с тем же именем, что и у вас?
Tundey
1
@Tundey the Sun JVM (в основном) с открытым исходным кодом, вы можете изменить его.
Spudd86
2

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

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

Tundey
источник
Я согласен с тобой на 110%. Что касается защиты IP, то это гарантия для нашего клиента, поскольку веб-приложение выполняет его машина, а не наше, хотя вы делаете правильное замечание. Я был больше обеспокоен клиентом, который имеет прямой доступ к нашему продукту на своей машине и может выбрать его отдельно. Сервер лицензий так же хорош, как и безопасность клиента. Если вы можете обойти доступ к серверу лицензий, никакие уловки в книге не помешают вам использовать программу без лицензии.
Нил
1

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

Кристофер Биббс
источник
Ну, конечно, мы всегда можем изменить это позже, хотя я думаю, что изменение должно быть в голове больше, чем код.
Нил
1
@Neil Тогда я бы посоветовал, что тебе нужно изменить голову. Если код работает, проходит адекватное тестирование и хорошо прокомментирован, использование этого маршрута вместо использования obfuscator не лучший выбор, но и не конец света. Исправьте это позже, если это проблема, и просто двигайтесь дальше.
Кристофер Биббс
@Christopher_Bibbs: успокойся. Я почти наверняка могу заверить вас, что на самом деле это в конечном итоге создаст проблему.
Нил
1

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

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

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

Стеф
источник
0

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

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

jhocking
источник
0

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

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

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


источник
0

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

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

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

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

user66734
источник