Zależy to od tego, co rozumie się pod pojęciem „bezpieczna analiza kodu źródłowego”. Można zrobić wszystko, co mu się podoba. Przypuszczam, że problem polega na tym, że ktoś inny poprosił o coś, co nazywa się „bezpieczną analizą kodu źródłowego” i można się zastanawiać, dlaczego nie można się do tego kwalifikować.

W wielu przypadkach taką analizę musi przeprowadzić ekspert merytoryczny (SME). W końcowym produkcie MŚP dostarczy oświadczenie zasadniczo mówiące „Deklaruję ten kod jako bezpieczny”, ze zrozumieniem, które jest głębsze niż stwierdzenie „Szukałem kilku znanych wzorców i nie znalazłem żadnych problemów”.

Gdybyś był zainteresowany autentycznym tłumaczeniem chińskiej filozofii, czy zaufałbyś osobie, która dużo znała filozofię i miała kilka ściągawek do jej rozszyfrowania, ale tak naprawdę nie znała chińskiego ?

Świetnym przykładem, który przychodzi na myśl, jest błąd, który uderzył w silnik SQL. Wybaczcie, że nie mam nazwy silnika, ani wersji, żebyście mogli zweryfikować, od tego czasu mam problemy ze znalezieniem. Jednak błąd był przejmujący. Błąd był w kodzie, który wyglądał tak:

  int storeDataInCircularBuffer (Buffer * dest, const char * src, size_t length) {if (dest->putPtr + length < dest->putPtr) return ERROR ; // zapobiegaj przepełnieniu bufora spowodowanemu przepełnieniem if (dest->putPtr + length > dest->endPtr) {... // zapisz dane w dwóch częściach return OK; } else {... // zapisz dane w jednej części return OK; }}  

Ten kod miał być częścią bufora cyklicznego. W buforze kołowym po osiągnięciu końca bufora zawijasz się. Czasami zmusza to do podzielenia przychodzącej wiadomości na dwie części, co jest w porządku. Jednak w tym programie SQL byli zaniepokojeni przypadkiem, w którym length może być wystarczająco duży, aby spowodować przepełnienie dest->putPtr + length , stwarzając okazję do przepełnienia bufora ponieważ następne sprawdzenie nie zadziała prawidłowo. Dlatego wprowadzili test: if (dest->putPtr + length < dest->putPtr) . Ich logika była taka, że ​​jedynym sposobem, w jaki to stwierdzenie może kiedykolwiek być prawdziwe, jest wystąpienie przepełnienia, a więc wyłapujemy przepełnienie.

Stworzyło to lukę w zabezpieczeniach, która faktycznie została wykorzystana i musiała zostać załatana. Czemu? Cóż, bez wiedzy oryginalnego autora, specyfikacja C ++ deklaruje, że przepełnienie wskaźnika jest niezdefiniowanym zachowaniem, co oznacza, że ​​kompilator może zrobić wszystko, co chce. Tak się złożyło, że kiedy oryginalny autor testował to, gcc faktycznie wyemitował poprawny kod. Jednak kilka wersji później, gcc miał optymalizacje, aby to wykorzystać. Okazało się, że nie ma zdefiniowanego zachowania, w którym instrukcja if mogłaby przejść test i zoptymalizowała go!

Zatem dla W kilku wersjach ludzie mieli serwery SQL, które miały exploita, mimo że kod miał jawne kontrole, aby zapobiec temu exploitowi!

Zasadniczo języki programowania są bardzo potężnymi narzędziami, które mogą z łatwością gryźć programistę. Analiza, czy tak się stanie, wymaga solidnych podstaw w danym języku.

(Edycja: Greg Bacon był na tyle świetny, aby wykopać ostrzeżenie CERT dotyczące tego: Uwaga o luce w zabezpieczeniach VU # 162289 kompilatory C może po cichu odrzucić niektóre kontrole otaczające., a także ten powiązany. Dzięki Greg!)

Myślę, że aby odnieść sukces, trzeba być dobrym programistą, więc polecam zostać nim. Może być wiele rzeczy, których brakuje w Twoim zestawie narzędzi / skanerze. Szczerze mówiąc, nie polecam polegać całkowicie na narzędziach skanujących twój kod, ponieważ exploity ciągle się zmieniają, a ktoś mógł zakodować w sposób, w którym skaner nie może wykryć luk.

Możliwość przechodzenia poprzez kod i zobaczenie, jak to działa, a jak nie powinno działać, jest fundamentem dla bezpiecznego tworzenia oprogramowania. Posiadanie wiedzy programisty o problemach z bezpieczeństwem jest dokładnie tym, czego chcesz, jeśli chodzi o stworzenie solidnego produktu, i dokładnie tym, czego potrzebujesz podczas przeglądu kodu.

Chociaż tak, możesz wskazać i kliknąć i sprawdzić luki w zabezpieczeniach z twoimi skanerami i zestawami narzędzi nie będzie to zbyt efektywne w ogólnym planie. Czy wiesz, o ile skuteczniejszy byłbyś, gdybyś sam mógł przyjrzeć się kodowi i określić, czy jest dobry, czy zły? Waaaay lepiej.

Nie próbuj przechodzić sprawdzania bezpiecznego kodu, jeśli nie wiesz, co robisz, ale nie rezygnuj od razu z pomysłu, jeśli uważasz, że nie znajdujesz się w punkcie, w którym możesz zrobić dobrą recenzję. Polecam spróbować się uczyć, tworząc własne makiety przeglądów bezpiecznego kodu i przeglądając go kilka razy, aby upewnić się, że wszystko jest w porządku.

Jednak zdecydowanie powinieneś nauczyć się nie tylko kodować, ale także dobrze kodować.

Wątpliwe jest, aby ekspert ds. bezpieczeństwa był skuteczny w przeprowadzaniu analizy kodu źródłowego, nie będąc jednocześnie wykwalifikowanym programistą. Wiele luk jest wynikiem technicznych lub składniowych praktyk kodowania, które są nadużywane w jakiś drobny sposób. Brakujący średnik, znak równości zamiast podwójnego równości, granica tablicy, która jest podwójnie zdefiniowana pierwszego dnia, ale jedna wersja jest zmieniana w kolejnym wydaniu, brakujące nawiasy, wycieki pamięci - wszystko to prowadziło do luk w zabezpieczeniach. Doświadczony programista może je zobaczyć, ale początkujący prawdopodobnie nie.

To, co powinien robić Twój ekspert ds. Bezpieczeństwa, to zachęcanie inżynierów do korzystania z narzędzi do automatycznego skanowania, takich jak statyczne analizatory kodu, testery Fuzz i dynamiczne weryfikatory aplikacji . Pomóż zespołom inżynierów zrozumieć walidację danych wejściowych, ataki iniekcyjne, granice zaufania. Zbuduj świadomość, że defekty zabezpieczeń wymagają odpowiedniego uszeregowania pod względem ważności i szybkiego usunięcia. Zaplanuj i przeprowadź testy piórkowe. A co najważniejsze, poproś inżynierów o dokonanie przeglądu kodu pracy innych.

Tak, ekspert ds. Bezpieczeństwa powinien umieć odczytać kod, ale to nie znaczy, że ma kwalifikacje do pełnienia funkcji arbitra bezpieczeństwo kodu.

To zależy od Twoich oczekiwań. Luki w zabezpieczeniach spowodowane problemami projektowymi (np. Brak ochrony CSRF, tylko podstawowa implementacja protokołu itp.) Można prawdopodobnie znaleźć, jeśli tester ma głęboką wiedzę na temat koncepcji bezpieczeństwa, nawet jeśli jest w stanie śledzić przepływ kodu tylko bez posiadanie głębszej znajomości konkretnego języka programowania.

Ale problemy z bezpieczeństwem specyficzne dla języka, takie jak przepełnienia bufora, błędy typu off-by-one, obsługa Unicode lub \ 0 , problemy spowodowane przez rozmiar typów danych oraz ze znakiem kontra bez znaku itp. nie zostanie znaleziony, jeśli tester nie ma głębszej wiedzy o języku, złych praktykach i typowych wzorcach braku bezpieczeństwa charakterystycznych dla tego języka. Weźmy na przykład historię luk w Javie, gdzie nawet programiści specjalizujący się w Javie nie zauważyli dziur, które wybili w piaskownicy języka, dodając refleksję do języka i tylko zewnętrzni eksperci z głębokim zrozumieniem język wewnętrzny wykrył wady.

Bezpieczne przeglądanie kodu wymaga nie tylko znajomości języka wysokiego poziomu, ale także opcji kompilatora i JAK KOD RZECZYWIŚĆ DZIAŁA NA PROCESORZE! Języki wysokiego poziomu są wydajne do pisania kodu, ponieważ ukrywają dużą złożoność. Ale wiele błędów i błędów kryje się w złożoności. Jak wskazano w innej odpowiedzi, kompilatory starają się postępować właściwie, ale naprawdę musisz zrozumieć, co się dzieje, demontując kod i rozwijając głębokie zrozumienie, jak to działa.

To zrozumienie jest również wymagane z językami skryptowymi, takimi jak JavaScript, które interpretują kod wysokiego poziomu na instrukcje procesora i alokację pamięci. Niestety ta recenzja byłaby zależna od platformy. Zobacz na przykład pod adresem https://en.m.wikipedia.org/wiki/Interpreted_language.

Czy trzeba być dobrym programistą, aby przeprowadzać bezpieczną analizę kodu źródłowego?

Nie.

Czy będzie w stanie wykonać przeglądanie bezpiecznego kodu bez znajomości wielu języków programowania i opanowania ich?

Nie.

Programowanie to coś więcej niż wiedza o szczegółach działania różnych języków. To jedna z rzeczy, których potrzebujesz, aby być dobrym programistą, a także jedna z rzeczy, których potrzebujesz, aby móc analizować kod źródłowy z punktu widzenia bezpieczeństwa (lub jakiejkolwiek innej jakości).

Więc podczas nie musisz być dobrym programistą, potrzebujesz biegłości w obsłudze języków.

Aby właściwie określić niebezpieczeństwo ataków typu side-channel, musisz znać sprzęt. Istnieją naprawdę brzydkie ataki kanału bocznego, takie jak uruchamianie nieuprzywilejowanego procesu na konfiguracji wieloprocesorowej równolegle z uprzywilejowanym wykonującym pewne zadanie szyfrowania / deszyfrowania i sondowanie, które współdzielone linie pamięci podręcznej są zabrudzone w jakim rodzaju czasowego wzorca lub przez czas dostarczenia poszczególnych sekwencji wzorców, które zostaną zaszyfrowane.

Ponieważ algorytmy szyfrowania są przedmiotem intensywnej analizy matematyków i innych teoretyków, ataki z kanału bocznego są coraz ważniejszym sposobem ponownego otwarcia gry. Wadą jest to, że muszą być przygotowane pod kątem określonej implementacji, kodu i sprzętu.