Співробітник використовував найгірші практики програмування

Я знаю, що це дивно сказати, але колега-програміст навмисно використовував пару шкідливих практик програмування спеціально! Я поясню. Спершу дозвольте мені сказати, що він розумний хлопець і здебільшого пише розбірливий код.

Його попросили реалізувати ліцензування на проекті веб-додатків, написаному на Java. Оскільки це Java, якби справді цього хотіли, можна було б, мабуть, зламати банки і прочитати назви класів та методів, записаних всередині. Його рішення цієї проблеми полягало в тому, щоб буквально незграбно називати змінні та методи менш очевидні імена та встановлювати їх всередині вже перевантажених класів, а не генерувати нові класи.

Його виправданням було те, що якби хакер захотів вимкнути певні класи, щоб обійти чекові ліцензії (і, отже, отримати безкоштовну копію продукту), йому було б набагато складніше, якби не було очевидно, які методи виконувати ці конкретні завдання. Лише після того, як він зробив це, я зіткнувся з ним щодо цього, припустивши, що ми можемо придбати якусь бібліотеку обфускаторів, щоб зробити це для нас, зберігаючи при цьому добрі практики програмування. Він стверджує, що не мав часу та ресурсів на пошук такого рішення.

..Що залишає мене перед дилемою. Я шукаю бібліотеку обфускаторів на Яві і виправляю його старий код (який може бути делікатним щодо реконструкції його коду), або залишаю його таким, наскільки це мене дратує, щоб не було кінця?

Безпека за допомогою притуплення ніколи не є доброю безпекою. Повинні бути кращі способи захисту вашої інтелектуальної власності. І саме це ви і ваш колега повинні виховувати як спільну турботу з вашим менеджером. Якщо керівництво вирішить, що вони не хочуть витрачати час або гроші на поліпшену безпеку, то вам обом доведеться жити з цим рішенням (це не ваш продукт, це продукт компанії) і краще не витрачати (витрачати?) більше не з цього питання.

Оригінал: Що каже ваш начальник? Дізнайся - зроби це.

Мене попросили розробити вищезазначене:

Перш за все, я думаю, що у вас є не одна дилема:

• Чи варто "виправити" код інших осіб?
• Чи достатньо поганим є реалізація (звідси A) інших осіб, що її слід замінити чимось іншим?
• Чи буде обфускатор (звідси B) кращим для цього "вбудовування ліцензій у нашу заявку"?

Перш за все, видно з ділового випадку проблема ІС вирішена. Це місце є і, швидше за все, є "досить хорошим" рішенням проблеми. Ваша компанія може бути задоволена цим, в основному просто захищеним, що для її розриву необхідно навмисні зусилля.

Це означає, що навіть якщо вам це не подобається (і, повірте, ви побачите набагато гірше, через вашу кар’єру ), це робить все, що потрібно. Отже, коли проблема вирішена, ви не повинні "просто робити це", а переконувати людину, яка відповідає за призначення вашої роботи, що довгостроковийціна цієї реалізації буде досить високою для того, щоб гарантувати відкат та вибір обкускувача запасів. Це вимагатиме від вас трохи підготовки, а також зауважте, що у обскураторів є і недоліки, які вам потрібно знати (інші відповіді це добре висвітлюють). Наприклад, сліди в стеках не можуть бути використані відразу і т. Д. Все залежить від того, наскільки важливо уникати піратства. Зауважте, що найскладніше зламати - це ті, що вимагають запуску апаратних ключів і, швидше за все, дорожчі, ніж сподобаються ваші клієнти.

Таким чином, це рішення не приймати, оскільки ваша компанія повинна використовувати додаткові ресурси, щоб перейти до Б. Отже, вам потрібно донести свої занепокоєння до відповідальної особи, пояснити це та будь-яку іншу довгострокову проблему досить добре, щоб він зрозумів, чому ви вважаєте, що це поступається вашій пропозиції. Тоді нехай він приймає рішення, і незалежно від того, яким воно виявилося, поважай його та поводийся відповідно до нього професійно. Зауважте, що, швидше за все, оригінальному автору доведеться підтримувати його так, як він його написав, і якщо він покине або не захоче більше, то ви можете знову зайнятися питанням.

Іншими словами: Що говорить ваш начальник? Дізнайся - зроби це.

Зауважте також, що це було б інакше, якби ви піднімали цю проблему раніше, щоб витрачені гроші на витрачений час на реалізацію А були меншими. Іншими словами, коли вибір між A і B мав бути зроблений.

Нарешті, я хотів би прокоментувати ваше запитання щодо "просто виправлення коду інших народів". Це не маленьке виправлення існуючого коду (який я вважаю прекрасним та заохочуваним, особливо з тестами на місці). Це руйнівний відкат та повторне виконання, і навіть у командах із загальним кодовим володінням це не було б прийнятною справою - принаймні для мене - без попереднього затвердження.

Сподіваюсь, це пояснює мою точку зору.

Я шукаю бібліотеку обфускаторів на Яві і виправляю його старий код (який може бути делікатним щодо реконструкції його коду), або залишаю його таким, наскільки це мене дратує, щоб не було кінця?

Ні , повернення позаду когось і зміна коду, за який вони відповідають, було б гіршим правопорушенням, ніж почати писати сумнівний код.

Ви виховували це з програмістом, ваш наступний крок - це утримати ніс від нього або виховувати його з управлінням, а потім утримувати ніс від нього.

Чи був офіційний огляд коду будь-якого виду - чи протистояння у вас було неофіційне "перегляд коду"? Я б сказав, що оскільки це делікатний та важливий предмет, такий як безпека та ліцензування, вам потрібно підняти цю ланцюжок. Ви виконали першу частину - зіткнувшись з програмістом. Однак тепер, коли він не слухає, ви можете / повинні прийняти це. Якщо ви цього не зробите, ви можете бути частиною проблеми.

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

Завжди зустрічайтеся з цими речами вперед - але політично і по-доброму.

Якщо ви можете знайти обфускатора, який може приховати підпис класів (назви методів тощо), запропонуйте його придбати та використовувати.

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

Чи може він продемонструвати, що такий злом здійсненний, чи це просто гіпотетичний сценарій, який його хвилює? Чи може він дати демонстрацію цього робочого? Він повинен спробувати. Серйозно. Якщо це працює, його слід представити керівництву, а потім запропонувати отримати обфускатора.

Якщо обфускатор недостатньо захищений, чи розглядали ви інші способи закріплення JAR, можливо, щось на кшталт шифрування або компіляції його до рідного коду?

RE: переробка його коду: це лише питання перейменування? У багатьох ІДЕ є інструменти рефакторингу, які дозволяють це зробити досить легко.

Незалежно від того, наскільки цінним є ваш IP, розумна річ не маніпулювати кодом, сподіваючись заплутати хакерів. Крім того, що це буде кошмаром, щоб продовжувати йти вперед, це насправді не вирішує жодної проблеми. Це просто ускладнює, але не неможливо. Тож насправді це не рішення, а побічні ефекти погані. Це як приймати ліки, які не діють і мають погані побічні ефекти.

Ваша проблема полягає в тому, як захистити свій IP. Знайдіть рішення для цього: обфускатори, сервер ліцензій тощо.

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

Моя перша думка - підтримка цього коду. Якщо код уже затуманений, і він рухається далі, удача спробує отримати ручку з цим кодом. Тоді ви будете хакером, який намагатиметься розшифрувати код.

Натомість я б рекомендував очистити код і за допомогою обфускатора виконати всю важку роботу. Довгостроково у вас буде багато керованого коду, і ви залишаєте всю шалену складність тому, хто хоче зламати вашу ліцензію.

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

Я дуже погоджуюсь з відповідями, що вам слід запитати свого начальника щодо питання і робити те, що він каже.

Однак дуже важливим доповненням до цих відповідей є те, що ви повинні задокументувати свої занепокоєння щодо безпеки та ремонту. Незалежно від того, змінили ви код чи ні, важливо, щоб люди знали, що вас хвилює і чому. Це важливо як активно (ваш начальник не може приймати рішення, яке навіть не знає, що його потрібно приймати), так і захисно (якщо / коли хакер пробиває дірки в погано захищеній системі ліцензування, вони не можуть звинувачувати вас у своїх помилка.)

"Не будьте найвищим професіоналом, який знає про проблему".

Іншими словами, скажіть своєму начальнику та йдіть звідти. Якщо ти мовчиш, і ти є вершиною тотумного полюса на цьому секреті, коли наштовхнешся наштовхнешся, ти несеш відповідальність. Скажіть своєму начальнику мимоволі і нехай він вирішить, як підійти до цього. Таким чином ви звільняєтесь від тягаря вибору.

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

Проста правда полягає в тому, що, маючи достатньо часу та ресурсів, все можна зламати. Це проста функція того, наскільки популярним є ваш додаток. Чим популярніший, тим більш кваліфікованими хакерами це приваблює, і більше часу приділяється його злому. Обфускація коду передбачає саме це - засіб для збільшення часу, необхідного для його розбиття, аналогічно криптографії. Отже, якщо ваш код затуманений, він вимагає від зловмисника кваліфікованої роботи і приділяє йому час, інакше він відчайдується і здасться. Ви повинні запитати себе, чи варто вашій програмі неприємностей на обох кінцях.

Насправді дивовижно, як важко може зламати затхлий код. Ви можете легко перетворити просту програму на 10 ліній С у складі 100 ліній через обфускування. Якщо ви спробуєте налагодити його, ви безглуздо перестрибнете в коді і перешкодити це може бути дуже неприємно. Врешті-решт вона зламається, але стає дуже важко, і оскільки нічого насправді неможливо, в цьому справа. Обфузація коду зменшує кількість людей, які здатні його зламати.

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

У вас є щось, чого зловмисник не робить. Оригінальний вихідний код. Знайдіть спосіб краще організувати для себе.