Pytanie:
Jak kiedykolwiek będę w stanie „zweryfikować” ponad 120 000 linii kodu PHP Composera, których nie napisałem?
Paranoid Android
2019-12-09 07:28:05 UTC
view on stackexchange narkive permalink

Opieram się na PHP CLI dla wszelkiego rodzaju osobistych i (miejmy nadzieję, wkrótce) profesjonalnych / krytycznych "logiki biznesowej". (Może to być dowolny inny język i dokładnie ten sam problem nadal istniałby; po prostu stwierdzam, czego osobiście używam ze względu na kontekst).

W największym możliwym stopniu zawsze koduję wszystko na mój własny. Tylko wtedy, gdy jest to absolutnie konieczne, niechętnie korzystam z biblioteki zewnętrznej. W niektórych przypadkach jest to po prostu konieczne. Na przykład parsowanie e-maili i inne bardzo skomplikowane rzeczy.

Do zarządzania takimi bibliotekami firm zewnętrznych używam PHP Composer. To menedżer biblioteki dla PHP. Jest w stanie pobierać biblioteki i ich zależności oraz aktualizować je za pomocą poleceń podobnych do innych „menedżerów pakietów”. W praktyce jest to dużo przyjemniejsze niż ręczne śledzenie tego i ręczne pobieranie plików ZIP, rozpakowywanie ich i rozwiązywanie wszelkiego rodzaju problemów. Oszczędza to przynajmniej wielu praktycznych problemów.

Jednak nadal występuje najbardziej podstawowy problem bezpieczeństwa: nie mam pojęcia, co to „zainstalowane” kod zawiera, ani nie wiem, co jest dodawane / zmieniane przy każdej aktualizacji. Jeden z autorów bibliotek mógł łatwo zostać przejęty pewnego dnia, gdy mój Composer pobierze aktualizacje, powodując, że moje skrypty PHP CLI nagle wysyłają mój portfel Bitcoin wallet.dat na jakiś zdalny serwer, instalują RAT / trojana na moim komputerze lub nawet gorzej. Właściwie to mogło się już wydarzyć, a ja nie byłbym mądrzejszy. Po prostu nie mam pojęcia. Logicznie nie mam pojęcia.

Moja własna baza kodu obejmuje łącznie około 15 000 wierszy. Skrupulatne przejrzenie tej bazy kodu zajmuje mi ponad rok. I to jest kod, który ja napisałem i który znam dobrze ...

Moje drzewo katalogów „Composer” ma obecnie ponad 120 000 linii kodu . I to dla minimalnej liczby kluczowych bibliotek PHP, których potrzebuję. Używam bardzo niewielu, ale mają różne zależności i ogólnie wydają się być bardzo rozdęte / napompowane w porównaniu z moim własnym kodem.

Jak mam kiedykolwiek „sprawdzić” to wszystko ?! To się po prostu nie wydarzy. Odwracam się bardzo krótko po próbie. Nie wiem nawet, jak przejdę przez kolejną „rundę weterynarza” mojego własnego kodu - nie mówiąc już o tym 10-krotnie większym, kodowanym przez innych ludzi.

Kiedy ludzie mówią, że „weryfikacja kodu firm trzecich” jest „obowiązkowa”, co dokładnie mają na myśli? Zgadzam się też, że to „konieczność”, ale jest też nieznośna rzeczywistość. Po prostu nigdy nie będę miał na to czasu i energii. Poza tym oczywiście nie mam pieniędzy, by zapłacić komuś innemu.

Spędziłem niezliczone godziny, próbując poznać Docker i sprawdzić, czy jest jakiś sposób, „hermetyzować” te niezaufane biblioteki innych firm, ale to przegrana bitwa. Okazało się, że to absolutnie niemożliwe, lub mam odpowiedź na którekolwiek z moich wielu pytań w tym zakresie. Nie wydaje mi się nawet, żeby było to możliwe w sposób, w jaki to sobie wyobrażam.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/102194/discussion-on-question-by-paranoid-android-how-am-i-ever-going-to-be-zdolny do życia).
Sześć odpowiedzi:
Lie Ryan
2019-12-09 09:28:21 UTC
view on stackexchange narkive permalink

Nie możesz sprawdzać pojedynczych linii kodu. Po prostu umrzesz, próbując to zrobić.

W pewnym momencie musisz zaufać komuś innemu. W 1984 roku Ken Thompson, jeden ze współtwórców większości systemów Unix, napisał krótki artykuł o ograniczeniach trustów. W pewnym momencie musisz ufać innym ludziom, musisz ufać, że ktokolwiek napisał twój edytor tekstu, nie ukrywa automatycznie kodu trojana, który wykona interpreter PHP w jakimś złośliwym oprogramowaniu kradnącym Bitcoiny.

musisz przeprowadzić analizę kosztów i korzyści, aby nadać priorytet temu, co sprawdzasz.

W większości przypadków powinieneś zrobić wszystko, co w Twojej mocy, aby zweryfikować autorów kodu, wewnętrzne praktyki bezpieczeństwa projektu i sposób kod dociera do Ciebie. W rzeczywistości przeglądanie kodu jest kosztowne i trudne, więc powinny być zarezerwowane dla części, które uważasz za najważniejsze dla swojego projektu.

Czy biblioteka jest popularną biblioteką, z której korzysta wiele osób z szanowanej firmy lub znany projekt, który za tym stoi? Czy projekt ma wdrożone odpowiednie procesy zarządzania projektem? Czy biblioteka ma dobrą historię problemów związanych z bezpieczeństwem i jak sobie z nimi radzili? Czy ma testy obejmujące wszystkie zachowania, z którymi musi sobie poradzić? Czy przechodzi własne testy? Wówczas ryzyko włamania do biblioteki bez zauważenia jest mniejsze.

Weź kilka przykładowych plików do dokładniejszej weryfikacji. Czy widzisz coś związanego z tym tematem? Jeśli kilka pobranych plików zawiera poważne problemy, prawdopodobnie można wywnioskować, że reszta bazy kodu ma podobne problemy; jeśli wyglądają dobrze, wtedy masz pewność, że reszta kodu jest podobnie dobrze napisana. Zwróć uwagę, że w bardzo dużych bazach kodu będą różne obszary o różnym poziomie jakości kodu.

Czy repozytorium menedżera pakietów sprawdza podpis pakietu? Czy istnieje system wstępnej weryfikacji wymagany do zarejestrowania pakietu w repozytorium, czy jest to otwarte repozytorium rejestracji? Czy otrzymujesz bibliotekę w postaci kodu źródłowego lub jako prekompilowany plik binarny? Mają one wpływ na to, jak bardzo możesz ufać bibliotece, czynniki ryzyka i sposób, w jaki możesz dalej zwiększyć zaufanie.

Musisz również wziąć pod uwagę aplikację i środowisko wykonawcze, w którym aplikacja będzie działać. Czy to dotyczy krajowego kodu bezpieczeństwa? Czy ten kod jest częścią eCommerce lub bankowości obsługującej numery kart kredytowych? Czy ten kod działa jako administrator? Czy ten kod jest krytyczny dla życia / bezpieczeństwa? Czy masz kontrole kompensujące, aby izolować i uruchamiać kod z różnymi uprawnieniami (np. Kontenery, maszyny wirtualne, uprawnienia użytkownika)? Czy to kod na weekendowy projekt poboczny? Sposób, w jaki odpowiesz na te pytania, powinien pozwolić Ci określić budżet na to, ile możesz zainwestować w weryfikację kodu, a zatem jak ustalić priorytety, które biblioteki wymagają weryfikacji, na jakim poziomie, a które są w porządku przy niższym zaufaniu.

Ten artykuł na temat zaufania nie jest tak naprawdę istotny w czasach, w których można użyć formalnie zweryfikowanego kompilatora do załadowania bardziej użytecznego łańcucha narzędzi bez martwienia się o backdoory wstawione przez kompilator.
@forest: jest nadal tak samo aktualny, jak jest teraz.Kto przeprowadza weryfikację formalną i jakich narzędzi używa do tej weryfikacji?Co się stanie, jeśli formalnie zweryfikowany kompilator i asystent dowodowy użyty do zweryfikowania tego kompilatora również podlegają archiwizacji?To żółwie w dół.
Jako minimum, możesz przeprowadzić weryfikację ręcznie, aby skompilować bardzo lekki kompilator, który rozumie podzbiór C. Możesz również ręcznie sprawdzić montaż bardzo małego kompilatora (lub napisać go samodzielnie).Montaż jest na tyle prosty, że można to zrobić ręcznie, bez konieczności ufania asemblerowi.
@forest:, skąd wiesz, że edytor tekstu / deasembler / narzędzie do zrzutu szesnastkowego, którego użyłeś, również nie są objęte wstecznym dostępem?
Przechowywać na nośniku wystarczająco prostym, aby używać czytnika SPI?W momencie, gdy martwisz się, że twój sprzęt do analizatora logicznego jest przesterowany, wkraczasz w sferę science fiction [Coding Machines] (https://www.teamten.com/lawrence/writings/coding-machines/).
@forest jest mało prawdopodobne, że czytelnik SPI z dostępem do wcześniejszych drzwi nie będzie czytelnika SPI, twoje argumenty nie zmieniają punktu odpowiedzi, który brzmi: * w pewnym momencie musisz zaufać komuś innemu *.Chodzi ci zasadniczo o to, że * powinieneś * zaufać komuś innemu.W każdym razie użycie czytnika SPI do zweryfikowania zestawu małego kompilatora, a następnie użycie go do skompilowania pełnego kompilatora, a następnie użycie tego do skompilowania pełnego zestawu narzędzi, jest mało prawdopodobne, aby było uważane za praktyczne rozwiązanie dla większości ludzi.
@forest Skąd wiesz, że twoja karta graficzna nie wydobywa bitcoinów?Skąd wiesz, że twoja karta sieciowa nie rejestruje wszystkich twoich pakietów i nie wysyła ich gdzie indziej?Zaufanie sięga aż do poziomu sprzętu. Nawet jeśli zbudujesz własną kartę sieciową, co tak naprawdę wiesz o prymitywnych komponentach, na których są zbudowane?Czy odkryjesz na nowo 50 lat postępu technologicznego?
Mikrokod procesora @JonBentley.Tranzystory fizyczne (Intel HRNG jest backdoored).
@Cruncher, nawet jeśli zbudowałeś własną kartę sieciową z krzemu, który sam wydobyłeś, skąd wiesz, że jakiś facet u twojego dostawcy Internetu nie węszy twoich pakietów?Poszedłbym dalej niż mówienie, że musisz zaufać komuś innemu.W pewnym sensie już ufasz komuś innemu.Jeśli w ogóle korzystasz z internetu, bezgranicznie ufasz, że jednak wiele miliardów ludzi również z niego korzysta.W końcu każdy z nich mógł cię pingować.
@Cruncher Mogę monitorować zużycie energii mojej karty graficznej (faktycznie to robię, ale z innych powodów).A moja karta sieciowa nie jest częścią mojego TCB.W każdym razie, moja ogólna uwaga jest taka, że nie musisz ściśle _musisz_ ufać kompilatorowi, a nie że możesz sprawdzić, czy nie istnieją żadne backdoory _ gdziekolwiek_.
@Ryan_L Jest jeszcze gorzej;Ethernet jest przeznaczony dla zaufanych sieci.Jeśli jesteś w sieci lokalnej z kimś innym, pośrednio ufasz wszystkim w sieci (technicznie rzecz biorąc, pierścienie tokenów były bliższe temu - w sieci Ethernet naprawdę ufasz przełącznikowi; ale przełączniki są zwykle bardzo „głupie”, więc ostatecznie musisz zaufać każdemu).Jeśli sieć jest połączona z inną siecią przez router, ufasz temu routerowi.Jest to szczególnie zabawne, gdy mamy do czynienia z prywatnymi pseudo-chmurami, w których pojedynczy złośliwy serwer może odmówić wszystkim usługi, nawet nie będąc łatwym do znalezienia.
Interesująca dla tej linii rozumowania może być walidacja montażu seL4 ARM.Zespół seL4 wykonał formalne dowody swojego kodu systemu operacyjnego * i * skompilowanego kodu asemblera (jeśli został skompilowany przez "rozsądny" kompilator ARM).Możesz zobaczyć, ile pracy wymagało, a następnie możesz spojrzeć na ich dokument opisujący [ich założenia] (https://sel4.systems/Info/FAQ/proof.pml) i porównać je z obawami, które mamy dzisiajbezpieczeństwo.Lubię na nie wskazywać, ponieważ ktoś INNY wykonał tę pracę i mogę wskazać i powiedzieć „Widzisz, nie chcemy tego robić!”.
@LieRyan jako doktorant metod formalnych, moja odpowiedź na pytanie „kto przeprowadza weryfikację…” brzmiałaby „prawie nikt”.Na świecie jest co najwyżej kilka tysięcy ludzi wykonujących FM.
Spudley
2019-12-09 20:04:26 UTC
view on stackexchange narkive permalink

Moje drzewo katalogów „Composer” ma obecnie ponad 120 000 linii kodu. I to ze względu na minimalną liczbę kluczowych bibliotek PHP, których potrzebuję.

Twoim błędem jest weryfikacja kodu firm trzecich tak, jakby był on Twój. Nie możesz i nie powinieneś próbować tego robić.

Nie wymieniłeś żadnej z bibliotek z nazwy, ale zamierzam założyć, że jest tam spora część, ponieważ używasz jednej większych frameworków, takich jak Laravel czy Symfony. Struktury takie jak te, podobnie jak inne duże biblioteki, mają własne zespoły ds. Bezpieczeństwa; problemy są naprawiane szybko, a instalowanie aktualizacji jest trywialne (o ile korzystasz z obsługiwanej wersji).

Zamiast próbować samodzielnie zweryfikować cały kod, musisz odpuścić i zaufać, że dostawca skończone - i nadal to robię - ta weryfikacja dla Ciebie. W końcu to jest jeden z powodów, dla których używasz kodu firm trzecich.

Realistycznie powinieneś traktować biblioteki PHP firm trzecich dokładnie tak samo, jak traktować biblioteki innych firm w skompilowanym środowisko, takie jak .NET lub Java. Na tych platformach biblioteki są dostępne jako pliki DLL lub podobne i możesz nigdy nie zobaczyć kodu źródłowego. Nie możesz ich zweryfikować i nie próbowałbyś. Jeśli Twoje podejście do biblioteki PHP różni się od tego, musisz zadać sobie pytanie, dlaczego. To, że potrafisz odczytać kod, nie oznacza, że ​​nic na tym nie zyskujesz.

Oczywiście, że wszystko to spada, jeśli biblioteki innych firm zawierają mniejsze, które są nieobsługiwane lub nie mają polityki bezpieczeństwa. Oto pytanie, które musisz zadać wszystkim bibliotekom, których używasz: czy są w pełni obsługiwane i czy mają politykę bezpieczeństwa, z którą czujesz się komfortowo. Jeśli tak nie jest, możesz rozważyć znalezienie alternatywy dla tych bibliotek. Ale to nadal nie znaczy, że powinieneś sam ich weryfikować, chyba że faktycznie masz zamiar przejąć dla nich wsparcie.

Jedną rzecz dodam jednak: jeśli chcesz przeprowadzić audyt bezpieczeństwa swojego kodu PHP, zdecydowanie polecam użycie skanera RIPS. To nie jest tanie, ale jeśli masz wysokie wymagania dotyczące bezpieczeństwa, jest to z łatwością najlepsze zautomatyzowane narzędzie do analizy bezpieczeństwa, jakie możesz uzyskać dla PHP. Zdecydowanie uruchom go na własnym kodzie; prawdopodobnie będziesz zaskoczony, ile problemów się podnosi. Możesz oczywiście uruchomić go również w bibliotekach innych firm, jeśli masz wystarczająco paranoję. Będzie cię to jednak kosztowało znacznie więcej, a moje powyższe punkty nadal są aktualne; naprawdę powinieneś ufać zewnętrznym dostawcom, że zrobią to dla siebie.

+1, również jeśli nie chcesz ufać dużej znanej platformie, masz większe problemy, ponieważ nie powinieneś ufać swojemu systemowi operacyjnemu, oprogramowaniu, oprogramowaniu układowemu, sprzętowi itp.
@FrankHopkins Niekoniecznie.Jeśli ponownie wymyślisz koło dla tych zależności, które są jedynie „wygodne w użyciu”, ryzykujesz wprowadzeniem luk w zabezpieczeniach, których nie było w bibliotece innej firmy (która jest potencjalnie rozwijana przez bardziej doświadczonych programistów i była dokładniej zbadana).
@JonBentley dlatego mówię zminimalizuj zależności do tego, czego potrzebujesz.Jeśli korzystasz z kryptowalut, zdecydowanie potrzebujesz tych bibliotek kryptograficznych.Ale prawdopodobnie nie potrzebujesz dużego środowiska, które - oprócz wielu innych rzeczy - zapewnia wygodny dostęp do bazy danych.Być może istnieje biblioteka, która już zapewnia prawie tak wygodne narzędzia do obsługi baz danych, wtedy prawdopodobnie jest to lepszy wybór.Chyba że jest to tak nieznane, że jesteś jedyną osobą, która go używa.Itd. Zawsze jest to ważenie jednego z drugim problemem, ale duże frameworki „zawsze” mają jakiś przeoczony problem, który gdzieś będzie możliwy do wykorzystania.
Machavity
2019-12-09 21:29:17 UTC
view on stackexchange narkive permalink

Witamy w nowym paradygmacie kodowania: używasz bibliotek ponad bibliotekami. Prawie nie jesteś sam, ale musisz też zrozumieć, że za każdym razem, gdy wprowadzasz kod, którego nie napisałeś, ryzykujesz.

Twoje rzeczywiste pytanie brzmi: jak mogę zarządzać tym ryzykiem ?

Zrozum, co powinno robić Twoje oprogramowanie

Zbyt często menedżerowie bibliotek stają się wygodnym sposobem na policzkowanie kodu, który „po prostu działa”, bez zawracania sobie głowy aby zrozumieć na wysokim poziomie, co ma robić. Dlatego, gdy kod Twojej zaufanej biblioteki robi złe rzeczy, przyłapuje Cię na tym, że zastanawiasz się, co się stało. W tym przypadku testy jednostkowe mogą pomóc, ponieważ testuje to, co powinien robić kod.

Poznaj swoje źródła

Kompozytor (lub dowolny menedżer pakietów ) można zainstalować z dowolnego określonego źródła, w tym biblioteki utworzonej wczoraj przez zupełnie nieznane źródło. Chętnie instalowałem pakiety od dostawców, którzy mają zestawy SDK, ponieważ dostawca jest wysoce zaufanym źródłem. Korzystałem również z pakietów ze źródeł, które wykonują inną zaufaną pracę (np. Ktoś w projekcie PHP ma repozytorium bibliotek). Ślepe zaufanie do dowolnego źródła może wpędzić cię w kłopoty.

Zaakceptuj, że istnieje pewne ryzyko, którego nigdy nie możesz w pełni ograniczyć.

W 2016 roku jeden programista NodeJS sparaliżował tonę pakietów kiedy opuścili projekt i zażądali niepublikowania swoich bibliotek. Mieli jedną prostą bibliotekę, którą setki innych pakietów wymieniły jako zależność. A może infrastruktura nie została zbudowana do obsługi dystrybucji pakietów, więc losowo zawiedzie. Internet stał się tak dobry w „sprawianiu, że wszystko działa” w świecie rozproszonego oprogramowania, że ​​ludzie są zdenerwowani lub zdezorientowani, gdy przestaje działać.

Kiedy pojawił się PHP 7.0, musiałem wykonać mnóstwo pracy przy tworzeniu pakietu oprogramowania innej firmy o otwartym kodzie źródłowym, którego używamy w środowisku 7.0. Zajęło mi to trochę czasu, ale byłem w stanie pomóc autorowi tego pakietu rozwiązać pewne problemy i uczynić go użytecznym w środowisku 7.0. Alternatywą było zastąpienie go ... co zajęłoby jeszcze więcej czasu. Akceptujemy to ryzyko, ponieważ ten pakiet jest całkiem przydatny.

Zgoda, każdy fragment kodu wiąże się z ryzykiem, w tym systemy operacyjne i kompilatory.
user116960
2019-12-10 09:50:04 UTC
view on stackexchange narkive permalink

Jednak najbardziej podstawowy problem z bezpieczeństwem nadal występuje: nie mam pojęcia, co zawiera ten „zainstalowany” kod, ani nie wiem, co jest dodawane / zmieniane przy każdej aktualizacji. Jeden z autorów bibliotek mógł łatwo zostać przejęty pewnego dnia, kiedy mój Kompozytor pobierze aktualizacje, powodując, że moje skrypty PHP CLI nagle wysyłają mój portfel Bitcoin wallet.dat na jakiś zdalny serwer, instalują RAT / trojana na moim komputerze lub nawet gorzej. Właściwie to mogło się już wydarzyć, a ja nie byłbym mądrzejszy. Po prostu nie mam pojęcia. Logicznie nie mam pojęcia.

Sprawdź Heartbleed, ogromną lukę w bezpieczeństwie w OpenSSL. Heartbleed skutecznie osłabił SSL, najpierw zapisując ostatnie kilkaset lub tysiące (zaszyfrowanych przez sieć) transakcji jako zwykły tekst, a następnie pozostawiając łatwe i niezalogowane narzędzie dla każdego, kto o tym wiedział, aby połączyć się zdalnie i odzyskać wszystkie zapisane w pamięci transakcje, o których myśleli użytkownicy zostały bezpiecznie zaszyfrowane zwykłym tekstem. W tym czasie OpenSSL chronił większość samodzielnie hostowanych witryn internetowych i ogromną liczbę banków, a nawet rządowych służb wywiadowczych.

Następnie wyszukaj Meltdown i Spectre, ogromne błędy wbudowane bezpośrednio w nowoczesne procesory Intela. Meltdown i Spectre całkowicie przeciwdziałają uruchomieniu procesora w trybie chronionym i będąc niezależnymi od systemu operacyjnego, można je wykorzystać w każdym systemie operacyjnym.

Wiele lat temu kawałek złośliwego oprogramowania o nazwie MSBlaster wykorzystał (nie jestem nawet pewien, czy był to błąd - tylko wyjątkowo głupi) usługę Windows XP działającą w tle, która nawet nie działała domyślnie - byłby aktywnie używany tylko przez znaczną mniejszość użytkowników systemu Windows, a następnie byłby znany tylko działom IT. To ostatecznie zmusiło dostawców usług internetowych do uruchomienia zapór sprzętowych wbudowanych w ich urządzenia modemowe i skłoniło Microsoft do osadzenia wbudowanej zapory programowej w swoich systemach operacyjnych. Mniej więcej w tym samym czasie odkryto, że dystrybucja rzekomo „odpornej na wirusy” platformy Linux zawiera wbudowany rootkit w głównej wersji dystrybucji.

Jak powiedzieli inni: Musisz komuś zaufać punkt. Zarówno wypadki, jak i złośliwość powodują problemy. Jestem jak ty - wielkim fanem The X-Files i Uplink (TRUST NO ONE!) - ale rzeczywistość jest taka, że ​​twój silnik kryptograficzny SSL lub twoje fizyczne urządzenia sprzętowe są tak samo narażone na luki w zabezpieczeniach, a te z większym prawdopodobieństwem reprezentują krytyczne dla misji awarie, gdy się pojawią.

Jeśli poważnie myślisz o pójściu o krok dalej, aby na nowo odkryć koło Composer dla bezpieczeństwa swojego i swoich użytkowników, to poważnie myśl o tym: stwórz własny procesor, płytę główną, pamięć RAM, dysk twardy i napędy optyczne. Napisz własne sterowniki systemu operacyjnego i sprzętu. Twórz też własne kompilatory. I zapomnij o PHP, ponieważ mogą być problemy w interpreterach - w rzeczywistości zapomnij też o C i C ++, ponieważ mogą być problemy w kompilatorze i nawet nie myśl o języku asemblera z asemblerem, który napisał ktoś inny. Pisz całe swoje oprogramowanie od podstaw w instrukcjach maszynowych, korzystając z edytora szesnastkowego.

Możesz też zachowywać się jak członek branży. Zasubskrybuj biuletyny z aktualizacjami Composera / PHP / YourLinuxDistro i być może otrzymuj także niezależne biuletyny oparte na bezpieczeństwie i wykup subskrypcję Wired . Przejrzyj dzienniki systemowe. Okresowo testuj swoją sieć za pomocą PCAP, aby upewnić się, że nie ma żadnych nieautoryzowanych strumieni sieciowych ani przychodzących, ani wychodzących. Bądź proaktywny, jeśli chodzi o monitorowanie możliwych zagrożeń i nie paranoję na punkcie rzeczy, które jeszcze się nie wydarzyły.

Cóż, spora część twojego pierwszego akapitu jest poświęcona temu błędnemu zrozumieniu i tak naprawdę nie jest związana z tym pytaniem.Najważniejsze jest dobra rada, ale odpowiedź przydałaby się, gdyby była nieco zmniejszona.Ostatecznie nie ma znaczenia _ dlaczego_ istniały różne wspomniane luki;powodem, dla którego są one istotne, jest miejsce, w którym istniały, więc ograniczenie spekulacji na temat tylnych drzwi uczyniłoby to jaśniejszym.
To naprawdę nie odpowiada na pytanie.Twoje pierwsze 5 akapitów wydaje się być kompletnymi stycznymi.Ostatni akapit jest bliżej poruszenia tematu, ale jest też styczny.Nie chodzi o to, jak przeglądać kod (zapobieganie), ale o tym, jak wykryć bardzo specyficzny rodzaj działania określonego zagrożenia.
Nie wiem, jak pomogłaby subskrypcja przewodowego magazynu informacyjnego.
not a hacker trust me
2019-12-12 03:53:27 UTC
view on stackexchange narkive permalink

Jako programista na poziomie średnio zaawansowanym i zaawansowanym rozważałem ten sam problem. Kilka kwestii do rozważenia:

  • Ustal priorytety sprawdzania kodu, który jest krytyczny ze względów bezpieczeństwa. Oczywiście obejmowałoby to takie rzeczy, jak kod uwierzytelniania i logowania, weryfikacja uprawnień, integracja procesora płatności . Wszystko, co prosi o podanie poufnych informacji lub wywołuje połączenia sieciowe.
  • Przejrzyj wizualnie rzeczy, takie jak biblioteki stylów - powinieneś być w stanie szybko ustalić, że wykonują tylko stylizację - i rzeczy jak funkcje narzędziowe. Wielkie litery, zastępowanie białych znaków, zmiana kolejności tablic ... powinieneś być w stanie szybko przejrzeć kod i zobaczyć, że nie robią nic nieoczekiwanego.
  • Nawet jeśli nie wykonujesz w pełni kodu inżynierskiego wstecznego, był twój własny, powinieneś być w stanie zerknąć na źródło i określić, czy miał być przyjazny dla inżynierii wstecznej . Kod powinien być udokumentowany z pomocnymi komentarzami, nazwy zmiennych i metod powinny być odpowiednie i użyteczne, funkcje i implementacje nie powinny być zbyt długie ani zbyt złożone ani zawierać niepotrzebnych funkcjonalności. Bardzo przyjemny dla oka kod z pewnością nie jest preferowanym wektorem ataku dla złośliwych hakerów.
  • Upewnij się, że kod ma ugruntowaną i dojrzałą bazę użytkowników silny>. Chcesz dążyć do projektów, z których znane są dochodowe i znane firmy.
  • Potwierdź tożsamość głównych współpracowników w świecie rzeczywistym . W przypadku projektów na dużą skalę wiodący deweloper z przyjemnością odniesie uznanie za ich pracę. Powinieneś być w stanie znaleźć posty na blogu, konta w mediach społecznościowych i prawdopodobnie życiorys lub stronę marketingową do pracy doradczej. Skontaktuj się ze mną! itp.
  • Upewnij się, że kod open source jest aktywnie utrzymywany z ostatnimi poprawkami błędów. Spójrz na zaległe zgłoszenia błędów - na pewno będzie ich kilka - i nie ufaj twierdzeniom, że dane narzędzie lub biblioteka są wolne od błędów. To mylące twierdzenie.
  • Unikaj witryn typu „freeware” z nadmierną liczbą reklam. Unikaj projektów, które nie mają dostępnej strony demonstracyjnej lub w których wersja demonstracyjna jest „brzydka”, źle utrzymana lub często offline. Unikaj projektów, które są przesadzone, lub zbyt wiele modnych frazesów, które zawierają niesprawdzone twierdzenia o doskonałej wydajności. Unikaj pobierania z anonimowych blogów. Itd.
  • Myśl złośliwie . Gdybyś chciał zepsuć swoją witrynę, czego byś spróbował? Gdybyś chciał przemycić niebezpieczny kod do powszechnie używanej biblioteki, jak byś to zrobił? (Oczywiście nie próbuj tego).
  • Rozwidlaj projekty open-source lub pobieraj kopie zapasowe. Nigdy nie ufaj, że oficjalne repozytorium projektu open source, który lubisz, pozostanie online na czas nieokreślony.

Więc zamiast próbować czytać i rozumieć każdy wiersz kodu z osobna, po prostu zorientuj się czym każda biblioteka i dlaczego Twoim zdaniem to robi. Naprawdę uważam, że jeśli twoja praca jest opłacalna, nie ma górnej granicy tego, jak duży może być projekt; możesz „zweryfikować” 1200 000+ linii kodu lub 120 000 000+ linii kodu!

knallfrosch
2019-12-10 04:42:52 UTC
view on stackexchange narkive permalink

Composer może pracować z plikiem composer.lock i domyślnie pobierać pakiety za pośrednictwem https://packagist.org/ (zwróć uwagę na HTTP S .) Masz więc ogromne repozytorium pakietów i bezpieczne pobieranie z towarzyszącą sumą kontrolną SHA1, aby upewnić się, że pobierasz dokładnie to, co zostało kiedyś określone. Samo to bardzo ci pomaga.

Jeśli pozostaniesz przy konserwatywnej stronie aktualizacji zależności, możesz również spodziewać się, że wersje pakietów były wykorzystywane w środowisku produkcyjnym.

Ostatecznie jednak , będziesz musiał komuś zaufać. Możesz albo zaufać sobie, że piszesz kod wolny od exploitów, albo, podobnie jak inni, zaufać projektom społeczności używanym przez tysiące i oglądanym przez jeszcze więcej użytkowników.

Ostatecznie jednak nie sądzę, że ty mieć wybór. Jeśli inni „latają na ślepo”, tj. Bez audytów bezpieczeństwa, które chcesz przeprowadzić, i zabierają „swoich” klientów z niższymi cenami i szybszymi wydaniami funkcji, i tak nikt nigdy nie odniesie korzyści z bezpiecznej, samodzielnie napisanej aplikacji.

Zaszyfrowane transfery i sumy kontrolne nie mówią nic o tym, co faktycznie robi kod ani kto go przeprowadził.Mogłem umieścić pakiet na Packagist w około 5 minut, oznaczyć go jako v2.5.9, aby wyglądał na konserwowany, ale wypełnić go kodem, który przesłał tyle danych, ile może uzyskać dostęp do wybranego przeze mnie serwera.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...