Inny programista zastosował najgorsze praktyki programistyczne


37

Wiem, że to dziwne, ale inny programista celowo zastosował kilka złych praktyk programistycznych! Wytłumaczę. Po pierwsze pozwól mi powiedzieć, że jest inteligentnym facetem i w większości pisze zrozumiały kod.

Został poproszony o wdrożenie licencji na projekt aplikacji internetowej napisany w Javie. Ponieważ jest to Java, jeśli ktoś naprawdę tego chce, prawdopodobnie mógłby włamać się do słoików i odczytać nazwy klas i metod zapisanych w środku. Jego rozwiązaniem tego problemu było dosłownie niezręczne wywoływanie zmiennych i metod o mniej oczywistych nazwach i umieszczanie ich w już przeciążonych klasach zamiast generowania nowych klas.

Uzasadniał to tym, że jeśli haker chciałby zmienić niektóre klasy w celu ominięcia kontroli licencyjnych (a tym samym uzyskać bezpłatną kopię produktu), miałby o wiele trudniejszy czas, gdyby nie było oczywiste, które metody wykonać te konkretne zadania. Dopiero po tym, jak to zrobił, zapytałem go o to, sugerując, że być może moglibyśmy kupić jakąś bibliotekę zaciemniającą, aby zrobić to za nas, zachowując dobre praktyki programistyczne. Twierdzi, że nie miał czasu ani zasobów na poszukiwanie tego rodzaju rozwiązania.

.. Co stawia mnie przed dylematem. Czy szukam biblioteki zaciemniającej w Javie i naprawiam jego stary kod (który może być nieco drażliwy przy przebudowie jego kodu), czy też zostawiam go w takim stanie, o ile denerwuje mnie to bez końca?


4
Jeśli twoje pytanie dotyczy tego, jak poradzić sobie z polityką tej sytuacji, to wiele odpowiedzi tutaj wskazuje właściwy kierunek, ale jeśli sugeruje to twój komentarz, naprawdę chcesz lepszej alternatywy do zaproponowania, możesz sprawdzić odpowiedzi na to pytanie: stackoverflow.com/questions/6018215/…
Mark Booth,

8
Jeśli haker z dostępem do czystego kodu źródłowego może zhakować twoje uwierzytelnienie, można je zhakować, kropka. Żadne zaciemnienie nie pomoże. Jeśli szukasz rozwiązania, które powstrzyma niektórych hakerów, to oprócz zaciemnienia możesz również chcieć skorzystać z niektórych jego praktyk w zakresie przekierowywania (ukryj rzeczy w mało prawdopodobnych klasach, których nie można łatwo zastąpić). Pomagają również częste aktualizacje, które całkowicie zmieniają Twoją praktykę uwierzytelniania. Wielu użytkowników zmęczyło się poleganiem na hakerach i po prostu kupuje.
Bill K

2
Czy zmieniał nazwy miejscowych? Jeśli tak, to marnuje czas - i tak nie istnieją jako zmienne nazwane w skompilowanym kodzie.
Nick Johnson,

1
Nazywa się to „zaciemnianiem” i chociaż jest obecnie częściej używany, nie jest w pełni odporny! .. chociaż opóźni kogoś od złamania kodu, można go złamać! .. co chciałbym zobaczyć to kompilator które mogą szyfrować kod obiektowy i mogą być wykonywane tylko za pomocą poprawnego klucza, dzięki czemu nawet ktoś z edytorem dysku, deasemblerem lub innym narzędziem do łamania zabezpieczeń nigdy nie będzie w stanie zrobić z niego głów ani ogonów!
Frank R.

6
„Jego rozwiązaniem tego problemu było dosłownie niezręczne nazywanie zmiennych i metod mniej oczywistymi nazwami i umieszczanie ich w już przeciążonych klasach zamiast generowania nowych”. i „Po pierwsze pozwól mi powiedzieć, że jest inteligentny” nie pasują do tego samego akapitu!
pożarł elysium

Odpowiedzi:


94

Bezpieczeństwo poprzez zaciemnianie nigdy nie jest dobrym zabezpieczeniem. Muszą istnieć lepsze sposoby ochrony własności intelektualnej. I to właśnie ty i twój kolega powinniście poruszyć wspólnie ze swoim przełożonym. Jeśli kierownictwo zdecyduje, że nie chce tracić czasu ani pieniędzy na poprawę bezpieczeństwa, to oboje będziecie musieli żyć z tą decyzją (to nie jest twój produkt, to produkt firmy) i lepiej nie wydawać (marnować?) więcej czasu na ten temat.


31
+1 zaciemnianie nie jest bezpieczeństwem, tylko kocem komfortu.
uɐɪ

7
Jeśli możesz znaleźć lepsze rozwiązanie niż zaciemnianie, oznaczę twoją odpowiedź jako prawidłową. Jak możesz zagwarantować, że osoba mająca dostęp do pliku wojny nie będzie mogła modyfikować jego funkcjonalności przynajmniej w odniesieniu do licencji?
Neil,

5
Nie możesz zagwarantować, że ktoś ma dostęp do plików. Ale prawda jest taka: najprostszy mechanizm chroni 99,99% użytkowników przed szkodliwym oprogramowaniem. Dedykowany i wykwalifikowany haker ZAWSZE znajdzie sposób na ominięcie bezpieczeństwa aplikacji. Możesz jednak przejść na zdalną weryfikację, aby Twój program działał tylko po uwierzytelnieniu w Twojej usłudze. Aby to było bezpieczne, musisz zaszyfrować cały program i mieć jakiś program ładujący. ALE: jeśli ktoś ma ważny klucz, i tak może ponownie zaprojektować oprogramowanie.
Falcon

7
@ Neil: Zaimplementuj podstawową logikę biznesową w mikrokontrolerze podłączonym jako klucz USB. Nie powiedziałeś, że musi być tani lub łatwy do wdrożenia;)
SF.

8
@SF.: Touche. Myślę, że powinno to wymagać trzech satelitów do jednoczesnego połączenia, na wszelki wypadek. ;)
Neil

84

Oryginał: Co mówi twój szef? Dowiedz się - zrób to.


Poproszono mnie o rozwinięcie powyższego:

Po pierwsze, myślę, że masz więcej niż jeden dylemat:

  • Czy należy „naprawić” kod innej osoby?
  • Czy wdrożenie (od A) innych osób jest na tyle złe, że należy je zastąpić czymś innym?
  • Czy obfuscator (tutaj B) będzie lepszy do tego „osadzania licencji w naszej aplikacji”?

Po pierwsze, patrząc z przypadku biznesowego, problem JEST rozwiązany. A jest na miejscu i - najprawdopodobniej - „wystarczająco dobre” rozwiązanie problemu. Twoja firma może być z tego zadowolona w zasadzie tylko wystarczająco chroniona, że ​​do jej przełamania potrzebny jest celowy wysiłek.

Oznacza to, że nawet jeśli ci się nie spodoba (i zaufaj mi, zobaczysz o wiele gorzej w swojej karierze ) robi to, co jest potrzebne. Dlatego, gdy problem JEST rozwiązany, nie powinieneś „po prostu to robić”, ale raczej przekonać osobę odpowiedzialną za powierzenie swojej pracy długoterminowejcena tego wdrożenia będzie wystarczająco wysoka, aby uzasadnić wycofanie i wybór zapasowego zaciemniacza. Będzie to wymagało od ciebie sporo przygotowania, a także zauważ, że zaciemniacze mają również wady, które musisz znać (inne odpowiedzi obejmują to dobrze). Np. Ślady na stosie nie nadają się do natychmiastowego użycia itp. Wszystko zależy od tego, jak ważne jest unikanie piractwa. Pamiętaj, że najtrudniejsze do złamania są te, które wymagają klucza sprzętowego do uruchomienia i najprawdopodobniej są droższe, niż klienci tego lubią.

Dlatego decyzja nie należy do Ciebie, ponieważ Twoja firma musi wykorzystać dodatkowe zasoby, aby przejść do B. Dlatego musisz przedstawić swoje obawy osobie odpowiedzialnej, wyjaśnić tę i wszelkie inne długoterminowe obawy wystarczająco dobrze, aby mógł zrozumieć, dlaczego uważasz to za gorsze od twojej sugestii. Następnie pozwól mu podjąć decyzję i bez względu na to, co się okaże, uszanuj ją i postępuj zgodnie z nią w sposób profesjonalny. Zauważ, że pierwotny autor najprawdopodobniej i tak będzie musiał go zachować, gdy go napisał, a jeśli odejdzie lub nie będzie tego chciał, możesz ponownie poruszyć tę sprawę.

Innymi słowy: co mówi twój szef? Dowiedz się - zrób to.

Zauważ też, że byłoby inaczej, gdybyś poruszył ten problem wcześniej, tak że zmarnowane pieniądze za czas poświęcony na wdrożenie A były mniejsze. Innymi słowy, kiedy miał zostać dokonany wybór między A i B.

Na koniec chciałbym skomentować twoje pytanie dotyczące „naprawiania kodu innego narodu”. To nie jest mała poprawka do istniejącego kodu (co uważam za dobre i zachęcane, szczególnie po przeprowadzeniu testów). Jest to destrukcyjne wycofywanie i ponowna implementacja, a nawet w zespołach posiadających wspólne prawa własności do kodu nie byłoby to do zrobienia - przynajmniej dla mnie - bez uprzedniej zgody.

Mam nadzieję, że to wyjaśnia mój punkt widzenia.


8
Mój szef nie jest programistą i prawdopodobnie miałbym trudności z wytłumaczeniem, dlaczego powinniśmy inwestować czas i pieniądze w robienie czegoś, co ostatecznie nie zmieni w żaden sposób zachowania programu.
Neil,

15
@ Neil: ... więc może nadszedł czas, aby przedstawić swojemu szefowi koncepcję „kosztów utrzymania”?
SF.

21
Czy stanie się to domyślną odpowiedzią na każde pytanie dotyczące współpracowników lub środowiska pracy? Wiem, że jakiś nub musiał iść i powiedzieć ci, żebyś opublikował to jako odpowiedź, ale daj spokój, to nie jest odpowiedź. To właściwie na wpół przyzwoite (choć niezręcznie sformułowane) pytanie dotyczące problemów z bezpieczeństwem spowodowanym przez niejasność; ta „odpowiedź” jest obraźliwa.
Aaronaught

8
@Aaronaught. Ta odpowiedź trafia do szpiku kości, gdy jest to „wdrożenie A jest złe, sugeruję, abyśmy zrobili wdrożenie B”, ponieważ należy wykonać dodatkową pracę (wyrównywanie pieniędzy). Gdyby to był wybór między wdrożeniem A lub B, odpowiedź byłaby inna. Sugeruję otwarcie pytania na temat meta, jeśli chcesz uzyskać bardziej szczegółową odpowiedź.

22
„Czy stanie się to domyślną odpowiedzią na każde pytanie dotyczące współpracowników lub środowiska pracy?” Dlaczego nie? Jeśli zostało to sformułowane jako pytanie techniczne. Wszystko „Czy powinienem to naprawić za moimi współpracownikami?” pytania ostatecznie sprowadzają się do: „Nie, zwróć uwagę zespołu / wyższej mocy”
Binary Worrier,

13

Czy szukam biblioteki zaciemniającej w Javie i naprawiam jego stary kod (który może być nieco drażliwy przy przebudowie jego kodu), czy też zostawiam go w takim stanie, o ile denerwuje mnie to bez końca?

Nie , cofanie się za kimś i zmienianie kodu, za który są odpowiedzialni, byłoby gorszym wykroczeniem niż pisanie wątpliwego kodu na początek.

Wychowałeś to z programistą, następnym krokiem jest trzymanie nosa z dala od niego lub zarządzanie nim, a następnie trzymanie nosa z daleka.


Potem, kiedy będę łowić w przyszłości na tych zajęciach, chyba po prostu trzymam się za nos.
Neil,

3
Jeśli ponosisz bezpośrednią odpowiedzialność za ten kod, możesz go zmienić zgodnie z własnymi upodobaniami, ale jeśli istnieje wspólna odpowiedzialność, będziesz potrzebować kogoś do arbitrażu. Łatwo jest zranić relacje robocze i marnować czas na takie sytuacje, lepiej nie robić z tego problemu, jeśli to możliwe. Jeśli trzeba rozwiązać problem, usuń go z drogi jak najszybciej.
DKnight

6

Czy miała miejsce jakakolwiek oficjalna weryfikacja kodu - czy może była to konfrontacja, którą przeprowadziłeś nieoficjalną „weryfikacją kodu”? Powiedziałbym, że ponieważ jest to delikatny i ważny temat, taki jak bezpieczeństwo i licencjonowanie, musisz podnieść ten poziom. Zrobiłeś pierwszą część - konfrontację z programistą. Jednak teraz, gdy on nie słucha, możesz / powinieneś to podjąć. Jeśli nie, możesz być częścią problemu.

Powiedziałbym mu, że zamierzasz to zrobić - to MOŻE zmienić zdanie. Jeśli nie, napisz do swojego szefa bardzo poprawny politycznie, a zarazem dokładny i zwięzły e-mail, a następnie poinformuj programistę. W wiadomości e-mail poproś o spotkanie między tobą i / lub dowolną inną stroną uczestniczącą.

Zawsze spotykaj się z tymi sprawami - ale w sposób polityczny i przyjazny.


Z pewnością godne pochwały podejście. Sam zauważyłem modyfikację kodu, aktualizując mój kod z SVN. Chociaż są szanse, że jeśli się nie zgodzi, przekonanie mojego szefa do podjęcia tych środków bezpieczeństwa prawdopodobnie nie spowoduje żadnych zmian, ponieważ programista może argumentować, że już „działa”.
Neil,

2

Jeśli możesz znaleźć zaciemniacz, który może zaciemnić podpis klas (nazwy metod itp.), Cóż, zaproponuj jego zakup i użycie.

Do tego czasu być może będziesz musiał z tym żyć. Przyznaję, że robię coś podobnego w ostatnim projekcie Grails - kontrole licencji są celowo osadzone w już dużej metodzie logowania, więc zastąpienie tej metody byłoby dość trudne.


1
Nie mogę ci powiedzieć, jak bardzo mi to przeszkadza, choć prawdopodobnie masz rację, że będę musiał z tym żyć.
Neil

2

Czy może wykazać, że taki hack jest wykonalny, czy może to tylko hipotetyczny scenariusz, o który się martwi? Czy może dać prezentację na żywo tego działania? Powinien spróbować. Poważnie. Jeśli to działa, należy przedstawić je kierownictwu, a następnie zasugerować uzyskanie obfuscatora.

Jeśli obfuscator nie jest wystarczająco bezpieczny, czy zastanawiałeś się nad innymi sposobami zabezpieczenia pliku JAR, być może coś takiego jak szyfrowanie go lub kompilacja do kodu natywnego?

RE: przeróbka jego kodu: Czy to tylko kwestia zmiany nazwy? Wiele IDE ma narzędzia do refaktoryzacji, które mogą to zrobić dość łatwo.


Uderza mnie trochę paranoikiem, choć rozumiem dlaczego. Jeśli produkt został zhakowany, prawdopodobnie oznaczałoby to jego pracę. Nie powiem, że jest to możliwe, ale wiem wystarczająco dużo, aby wiedzieć, w jaki sposób można polować na nazwy metod, a gdyby istniała oczywista metoda o nazwie „isLicenseValid”, należałoby napisać klasę, która ma tę metodę i zawsze zwraca wartość true dla „zhakuj” to. Myślę, że ten program jest wystarczająco skomplikowany, nie komplikując go dalej, choć wydaje się, że chce być tego pewien. Myślę, że mógłbym łatwo naprawić jego kod, zmieniając jego nazwę, tak.
Neil,

To, że masz metodę o nazwie „isLicenseValid”, nie oznacza, że ​​można ją zhakować, po prostu pisząc klasę za pomocą tej samej metody. Jeśli oznaczysz swoją klasę jako „zapieczętowaną” (taka jest składnia C #), firmy zewnętrzne nie będą mogły po prostu ominąć twoich kontroli bezpieczeństwa, pisząc podklasy i zastępując twoją metodę. W każdym razie, chyba że ten facet jest oficerem bezpieczeństwa firmy, dlaczego miałoby to oznaczać jego pracę, gdyby produkt został zhakowany?
Tundey,

2
@Tundey, to nie jest kwestia podklas (jak by się załadowały?): Chodzi o napisanie tej samej klasy i umieszczenie wcześniej zaatakowanej wersji na liście wyszukiwania ścieżki klas.
Peter Taylor,

1
ha. Pamiętam radość z ładowania klas w Javie. Nadal musi istnieć lepszy sposób na złagodzenie tego. W rzeczywistości, jeśli twój moduł ładujący klasy nie jest zagrożony, w jaki sposób ktoś może napisać klasę, która jest taka sama jak Twoja klasa? Zwłaszcza jeśli Twój plik JAR jest podpisany? Czy podpisywanie plików JAR i zamykanie zajęć nie rozwiązałoby problemu pisania przez kogoś zajęć o tej samej nazwie co twoje?
Tundey,

1
@Tundey the Sun JVM jest (głównie) oprogramowaniem typu open source, możesz je modyfikować.
Spudd86,

2

Niezależnie od tego, jak cenny jest twój adres IP, inteligentną rzeczą jest nie zmieniać kodu w nadziei na zamieszanie hakerów. Pomijając fakt, że kontynuowanie tego będzie koszmarem, tak naprawdę nie rozwiązuje żadnego problemu. To tylko utrudnia, ale nie jest niemożliwe. Więc to nie jest tak naprawdę rozwiązanie, a skutki uboczne są złe. To jak przyjmowanie leku, który nie działa i ma złe skutki uboczne.

Twój problem polega na tym, jak zabezpieczyć swoje IP. Znajdź rozwiązanie: obfuscators, serwer licencji itp.


Zgadzam się z tobą 110%. Jeśli chodzi o zabezpieczanie adresu IP, jest to zabezpieczenie dla naszego klienta, ponieważ to na jego komputerze działa aplikacja internetowa, a nie nasza, choć słusznie to robisz. Bardziej martwiłem się klientem, który ma bezpośredni dostęp do naszego produktu na swojej maszynie i może go rozdzielić. Serwer licencji jest tak dobry, jak bezpieczeństwo po stronie klienta. Jeśli możesz ominąć dostęp do serwera licencji, żadne sztuczki w książce nie powstrzymają cię przed używaniem programu bez licencji.
Neil,

1

Wystąpił podobny problem, gdy inny programista nazwał nasze procedury szyfrowania / deszyfrowania str__copyi str__delete(zauważ drugi podkreślenie). To było kiepskie i można było to zrobić lepiej, więc czekaliśmy, aż pojawi się historia, w której konieczna będzie aktualizacja licencji. Zarząd nie miał problemu z dodatkowymi garściami godzin, ponieważ opisaliśmy to jako „posprzątanie, więc następnym razem, gdy zaczniemy licencjonowanie, zajmie to mniej czasu i będzie bardziej bezpieczne”. Problem rozwiązany, bez zranienia.


Oczywiście, że zawsze możemy to zmienić później, choć myślę, że zmiana musi być bardziej w głowie niż w kodzie.
Neil,

1
@ Neil Sugeruję, że jesteś tym, który potrzebuje zmiany w głowie. Jeśli kod działa, ma odpowiednie testy i jest dobrze skomentowany, przejście tą drogą zamiast użycia i obfuscator nie jest najlepszym wyborem, ale też nie jest końcem świata. Napraw to później, jeśli jest to problem i po prostu przejdź dalej.
Christopher Bibbs,

@Christopher_Bibbs: Spokojnie. Prawie na pewno mogę was zapewnić, że w rzeczywistości będzie to stanowić problem.
Neil,

1

Moją pierwszą myślą było utrzymanie tego kodu. Jeśli kod jest już zaciemniony i ruszył dalej, powodzenia w próbach opanowania tego kodu. Będziesz wtedy hakerem próbującym odszyfrować kod.

Zamiast tego poleciłbym oczyszczenie kodu i użycie ciężkiej pracy za pomocą obfuscatora. W dłuższej perspektywie będziesz miał dużo łatwiejszego do zarządzania kodu i całą szaloną złożoność pozostawisz każdemu, kto chce zhakować licencję.

Pamiętaj, że żaden obfuscater nie jest idealny, a bardzo zdeterminowany haker może odwrócić wszystko, ale przynajmniej będzie to tylko on. Plus obfuscaters dodają o wiele bardziej złożoności niż ten jeden facet prawdopodobnie może.


0

Bardzo zgadzam się z odpowiedziami, że powinieneś zapytać swojego szefa o problem i zrobić to, co on mówi.

Jednak bardzo ważnym dodatkiem do tych odpowiedzi jest to, że powinieneś udokumentować swoje obawy dotyczące zarówno bezpieczeństwa, jak i łatwości konserwacji. Niezależnie od tego, czy zmienisz kod, ważne jest, aby ludzie wiedzieli, co Cię niepokoi i dlaczego. Jest to ważne zarówno proaktywnie (twój szef nie może podjąć decyzji, o której nawet nie wie, że należy go podjąć), jak i defensywnie (jeśli / kiedy haker zagniedzi dziury w słabo zabezpieczonym systemie licencyjnym, nie może cię winić za swoje błąd.)


0

„Nie bądź najlepszym profesjonalistą, który zna problem”.

Innymi słowy, powiedz swojemu szefowi i stamtąd. Jeśli zachowujesz ciszę i jesteś na szczycie totumu w tym sekrecie, gdy będziesz atakować, będziesz odpowiedzialny. Powiedz swojemu szefowi, który przechodzi, i pozwól mu zdecydować, jak się do niego zbliżyć. W ten sposób uwolnisz się od ciężaru wyboru.

Nie mów po prostu swojemu szefowi, ponieważ wielu menedżerów może nie jest tak technicznych, ale rób to, co zawsze robimy: daj problem i możliwe rozwiązania z zaletami / wadami każdego z tych rozwiązań. Następnie pozwól im zdecydować i niech to minie. Właśnie dlatego menedżerom / liderom zarabia się duże pieniądze!


0

Prawda jest taka, że ​​przy wystarczającej ilości czasu i zasobów wszystko można złamać. Jest to prosta funkcja określająca popularność Twojej aplikacji. Im bardziej popularny, tym bardziej wykwalifikowani hakerzy przyciągają i więcej czasu poświęcają na jego złamanie. Ukrywanie kodu zapewnia właśnie to - sposób na zwiększenie czasu potrzebnego do jego złamania, podobny do kryptografii. Więc jeśli twój kod jest zaciemniony, atakujący musi być wprawny i poświęcić mu trochę czasu, w przeciwnym razie rozpaczy i zrezygnuje. Musisz zadać sobie pytanie, czy Twoja aplikacja jest warta problemów na obu końcach.

To naprawdę niesamowite, jak trudno może złamać zaciemniony kod. Możesz łatwo włączyć prosty program 10 linii C w zespole 100 linii poprzez zaciemnianie. Jeśli spróbujesz go debugować, przeskakujesz bez znaczenia w kodzie i możesz być naprawdę frustrujący, aby go przejść. W końcu pęknie, ale stanie się naprawdę trudne, a ponieważ nie ma rzeczy niemożliwych, o to właśnie chodzi. Zaciemnianie kodu zmniejsza liczbę osób, które są w stanie go złamać.

Jasne, że istnieją lepsze sposoby, takie jak próba dezorientacji debugera nie krakera, ale jest to tani i wydajny. Jednak nazywanie rzeczy niezręcznie nie do końca to ogranicza. Musisz zmienić funkcje wywołujące kontrolę przepływu, które tak naprawdę nie robią nic dla całego kodu, ale zwiększają jego rozmiar i złożoność: wywołuj fałszywe funkcje, których zwracana wartość nie jest nigdzie używana, z funkcji wewnętrznych, które naprawdę coś robią. Widać już, jak to może być naprawdę mylące.

Masz coś, czego atakujący nie ma. Oryginalny kod źródłowy. Znajdź sposób, aby lepiej to zorganizować dla siebie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.