Audyt kodu - Code audit

Audyt kodu oprogramowania to kompleksowa analiza kodu źródłowego w projekcie programistycznym w celu wykrycia błędów, naruszeń bezpieczeństwa lub naruszeń konwencji programistycznych. Stanowi integralną część defensywnego paradygmatu programowania , który stara się zmniejszyć liczbę błędów przed wydaniem oprogramowania. Kod źródłowy w językach C i C ++ to najczęściej poddawany audytowi kod, ponieważ wiele języków wyższego poziomu, takich jak Python, ma mniej funkcji potencjalnie podatnych na ataki (np. Funkcje, które nie sprawdzają granic).

Wytyczne

Podczas audytu oprogramowania każdy krytyczny komponent powinien być audytowany oddzielnie i razem z całym programem. Dobrym pomysłem jest najpierw wyszukanie luk wysokiego ryzyka, a następnie przejście do luk niskiego ryzyka. Luki między wysokim a niskim ryzykiem generalnie istnieją w zależności od sytuacji i sposobu wykorzystania danego kodu źródłowego. Testy penetracyjne aplikacji mają na celu zidentyfikowanie luk w oprogramowaniu poprzez uruchomienie jak największej liczby znanych technik ataku na prawdopodobne punkty dostępu w celu wyłączenia aplikacji. Jest to powszechna metoda inspekcji i może być używana do sprawdzania, czy istnieją jakieś określone luki w zabezpieczeniach, ale nie w miejscu ich występowania w kodzie źródłowym. Niektórzy twierdzą, że metody audytu na koniec cyklu mają tendencję do przytłaczania programistów, ostatecznie pozostawiając zespołowi długą listę znanych problemów, ale niewielką rzeczywistą poprawę; w takich przypadkach jako alternatywa zalecane jest podejście kontrolne na bieżąco.

Luki wysokiego ryzyka

Niektóre typowe luki w zabezpieczeniach wysokiego ryzyka mogą występować w wyniku użycia:

  • Funkcje sprawdzające ograniczenia (np. Strcpy , sprintf , vsprintf i sscanf ), które mogą prowadzić do luki w przepełnieniu bufora
  • Manipulowanie wskaźnikami buforów, które mogą kolidować z późniejszym sprawdzaniem granic, np .: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;
  • Wywołania takie jak execve (), potoki wykonania, system () i podobne rzeczy, zwłaszcza gdy są wywoływane z argumentami niestatycznymi
  • Walidacja danych wejściowych, np. (W SQL): statement := "SELECT * FROM users WHERE name = '" + userName + "';" jest przykładem luki w zabezpieczeniach typu SQL injection
  • Funkcje dołączania plików, np. (W PHP): include($page . '.php'); to przykład luki w zabezpieczeniach Remote File Inclusion
  • W przypadku bibliotek, które mogą być powiązane ze złośliwym kodem, zwracanie odniesienia do wewnętrznej struktury danych podlegających zmianom (rekord, tablica). Złośliwy kod może próbować zmodyfikować strukturę lub zachować odniesienie, aby obserwować przyszłe zmiany.

Luki niskiego ryzyka

Poniżej znajduje się lista luk niskiego ryzyka, które należy znaleźć podczas inspekcji kodu, ale które nie powodują sytuacji wysokiego ryzyka.

  • Luki w zabezpieczeniach kodu po stronie klienta, które nie wpływają na serwer (np. Cross-site scripting )
  • Wyliczenie nazwy użytkownika
  • Przechodzenie do katalogu
  • Wrażliwe klucze API

Przybory

Narzędzia do audytu kodu źródłowego zazwyczaj wyszukują typowe luki w zabezpieczeniach i działają tylko w określonych językach programowania . Takie zautomatyzowane narzędzia można wykorzystać w celu zaoszczędzenia czasu, ale nie należy na nich polegać w przypadku dogłębnego audytu. Zaleca się stosowanie takich narzędzi w ramach podejścia opartego na polityce.

Zależność od wymagań

Jeśli ustawiony jest na niski próg, większość narzędzi do audytu oprogramowania wykrywa wiele luk w zabezpieczeniach, zwłaszcza jeśli kod nie był wcześniej audytowany. Jednak rzeczywiste znaczenie tych alertów zależy również od sposobu korzystania z aplikacji. Biblioteka, która może być powiązana ze złośliwym kodem (i musi być przed nim odporna) ma bardzo surowe wymagania, takie jak klonowanie wszystkich zwracanych struktur danych, ponieważ oczekuje się zamierzonych prób złamania systemu. Program, który może być narażony tylko na złośliwe dane wejściowe (np. Zaplecze serwera WWW), musi najpierw zająć się tym wejściem (przepełnieniem bufora, wstrzyknięciem SQL itp.). Takie ataki mogą nigdy nie mieć miejsca na program, który jest używany wewnętrznie tylko przez upoważnionych użytkowników w chronionej infrastrukturze.

Zobacz też

Bibliografia