5 pułapek bezpieczeństwa Pythona, których należy unikać

Kobieta Technologia

W tym wpisie na blogu porozmawiamy o pisaniu bezpiecznego kodu. Czy udaję, że zawsze piszę bezpieczny kod?… O nie! Jestem leniwy, tak jak reszta z nas :-). Mimo to, jest kilka rzeczy, których należy być świadomym podczas pisania kodu (nawet jeśli jest to przykładowy kod). Uważam, że nadal można pisać proste próbki. Jeśli jednak wiesz przynajmniej, jakie podatności może mieć Twój kod, możesz to zapisać w README. Nawet słynny chiński filozof Konfucjusz wiedział o tym już około 530 roku p.n.e:

„Wiedzieć, co się wie, a czego się nie wie, to jest prawdziwa wiedza”. – Konfucjusz

Czy powinienem się martwić o mój skrypt hello_world.py?

Nie. Ponownie, nie twierdzę, że zawsze powinieneś robić wszystko, co w Twojej mocy, aby przetestować jakiś kod napisany w celu przetestowania API. Wymieniłem jednak 5 typowych błędów Pythona, które mogą powodować poważne luki w aplikacjach produkcyjnych. Należy o nich pamiętać i starać się ich unikać tak bardzo, jak to tylko możliwe! Ponadto, te błędy w kodowaniu mogą oczywiście wystąpić także w innych językach programowania, więc nie dotyczą one tylko Pythona.

Co to jest?

Arbitralne wykonanie kodu (Arbitrary Code Execution) to zdolność atakującego do uruchamiania dowolnych poleceń lub kodu na maszynie docelowej lub w docelowym procesie. Jest to najczęściej spotykane w Pythonie i występuje w wielu typach, takich jak wstrzykiwanie poleceń, wstrzykiwanie kodu SQL i inne. Wynika to z danych wejściowych użytkownika, które są bezpośrednio przekazywane w standardowej funkcji Pythona. Przyczyną jest zazwyczaj brak sanityzacji danych wejściowych.

Przykładowy wycinek kodu

Jak można temu zaradzić?

Zawsze najpierw oczyszczaj i waliduj dane wejściowe użytkownika, zanim przekażesz je do poleceń systemowych. Można to zrobić, używając modułu Pythona `ast`. Moduł Pythona `shlex` może również pomóc w automatycznym usuwaniu danych wejściowych użytkownika.

Możesz użyć shlex do poprawnego przetworzenia łańcucha poleceń na tablicę i do poprawnego oczyszczania danych wejściowych jako parametrów linii poleceń.

Moduł ast pomaga aplikacjom Pythona w przetwarzaniu drzew abstrakcyjnej gramatyki składni Pythona. Można go użyć do przetwarzania, a następnie sprawdzania poprawności danych wprowadzonych przez użytkownika. Poniżej znajduje się przykład, jak rozwiązać ten problem przy użyciu `ast`.

Co to jest?

Atak typu Directory Traversal Attack jest również spowodowany nieprawidłowym sprawdzaniem poprawności danych wprowadzanych przez użytkownika. Może to prowadzić do odsłonięcia wrażliwych plików, a nawet do zdalnego wykonania kodu. Powstaje, gdy ścieżka dostępu do pliku przez skrypt Pythona nie jest odpowiednio sprawdzana. Napastnik może manipulować ścieżką dostępu do pliku, na przykład do czegoś takiego jak /etc/passwd…

Przykładowy wycinek kodu

Jako przykładowa biblioteka Pythona, pakiet Requests (kto go nie używa?) sprzed wersji 2.20.0 dla Pythona wysyła nagłówek HTTP Authorization do URI http po otrzymaniu przekierowania https-to-http o tej samej nazwie hosta, co ułatwia zdalnym napastnikom odkrycie danych uwierzytelniających poprzez sniffowanie sieci.

Jak można temu zaradzić?

Można temu zaradzić poprzez sanityzację danych wprowadzanych przez użytkownika, na przykład za pomocą „shlex”. Można również utworzyć listę plików, do których użytkownik ma dostęp, lub ustawić statyczny bezpieczny katalog. Staraj się unikać używania bezpośrednich ścieżek. Można również użyć funkcji `os.path.realpath`, aby wyczyścić ścieżkę i zwrócić jej kanoniczną postać (ścieżkę bezwzględną):

https://github.com/chrivand/sample_python_vulns/blob/main/py_solv01.py

Pułapka bezpieczeństwa Pythona 3: przestarzałe biblioteki

Co to jest?

Mówiąc najprościej, biblioteka Pythona to kod napisany przez innych, który można łatwo zaimportować do skryptu. Kod jest pisany przez ludzi, ludzie popełniają błędy, a błędy są łatane (miejmy nadzieję). Niestety, często zapominamy o aktualizowaniu (i testowaniu!) naszego kodu za pomocą tych poprawek, przez co staje się on podatny na ataki.

Przykład

Jako przykład biblioteki Pythona, pakiet Requests (kto go nie używa?) sprzed wersji 2.20.0 dla Pythona wysyła nagłówek HTTP Authorization do URI http po otrzymaniu przekierowania https-to-http o tej samej nazwie hosta, co ułatwia zdalnym napastnikom odkrycie danych uwierzytelniających przez sniffowanie sieci.

Jak można temu zaradzić?

Ta luka może zostać naprawiona przez aktualizację (i przetestowanie!) wszystkich pakietów, dla których dostępne są aktualizacje. (DUH!)

Można również użyć narzędzi, które pomogą w tym po fakcie:

  • Statyczne testowanie bezpieczeństwa aplikacji (SAST) – test statyczny, który odbywa się bez wykonywania kodu.
  • Dynamiczne testowanie bezpieczeństwa aplikacji (DAST) – dynamiczne testy, które są przeprowadzane poprzez wykonywanie ścieżek kodu.
  • Interaktywne testowanie bezpieczeństwa aplikacji (IAST) – agenty i czujniki są uruchamiane w celu ciągłego analizowania działania aplikacji podczas testowania automatycznego.
  • RASP (Runtime application self-protection) – dużą zaletą RASP jest to, że jest w stanie wychwycić (i zablokować) wykorzystanie podatności, które pojawiły się po wdrożeniu aplikacji. Przykładem RASP jest Cisco AppDynamics with Secure Application (więcej szczegółów na ten temat znajduje się w ostatniej części tego wpisu).

Pułapka bezpieczeństwa Pythona 4: Niekompletne asercje

Co to jest?

Ta luka występuje, gdy asercje Pythona są używane do oceny warunków, takich jak wyrażenia booleańskie. Jeśli warunek jest prawdziwy, wykonanie przechodzi do następnej linii. W przeciwnym razie zostanie wyświetlony błąd. Słowo kluczowe `assert` powinno być zwykle używane podczas debugowania kodu.

Przykładowy snippet

Jak można to rozwiązać?

NIE używaj asercji Pythona dla logiki, używaj logiki if-else dla warunków logicznych. W produkcji asercje mogą być wyłączone, więc używaj asercji tylko w środowiskach testowych. Asercje Pythona nie są narzędziem do obsługi błędów, są narzędziem do debugowania, używaj ich w ten sposób.

Pułapka bezpieczeństwa Pythona 5: Złamana kontrola dostępu

Co to jest?

Broken access control opisuje wykorzystanie zarządzania kontrolą dostępu przez atakujących i złych aktorów. Ta luka została przesunięta na miejsce #1 z #5 w rankingu OWASP10. Oszałamiające 94% aplikacji zostało przetestowanych pod kątem jakiejś formy złamanej kontroli dostępu.

Kilka przykładów:

  • Ręczna modyfikacja stanu aplikacji: Modyfikacje te mogą polegać na modyfikacji adresów URL, plików cookie i sesji przeglądarki lub użyciu niestandardowych narzędzi do ataku na API.
  • Zmiana identyfikatora klucza: Pozwala to na zmianę identyfikatorów kluczy, takich jak klucz główny użytkownika, w taki sposób, że daje to niepożądany dostęp innemu użytkownikowi do wykonywania działań, które w innym przypadku byłyby nieuprawnione.
  • Eskalacja przywilejów: Jest to znana metoda ataku, w której osoba atakująca loguje się do firmowej bazy danych jako administrator. Atak ten może polegać na działaniu jako uwierzytelniony użytkownik bez uwierzytelniania.

Przykładowy wycinek

Jeśli przyjrzymy się następującemu adresowi URL uwierzytelniania, możemy zobaczyć, jakie parametry są przekazywane:

https://example.com/accounts/details?id=123&access_key=abcdefg&access_secret=opensecret

Osoba atakująca może zmienić

e parametry adresu URL, takie jak ID, ACCESS_KEY i ACCESS_SECRET, złośliwym podmiotom, co daje im dostęp do informacji o koncie. W wyniku tego ataku może dojść do wycieku lub zmiany poufnych informacji.

Jak można temu zaradzić?

Walidacja i weryfikacja żądań powinna być zawsze przeprowadzana. Należy również zaimplementować uprawnienia oparte na rolach oraz uprawnienia na poziomie obiektu, tak aby można było zweryfikować autoryzację między autoryzowanym użytkownikiem a żądanym zasobem obiektowym. Poniżej znajduje się prosty przykład takiej walidacji i weryfikacji, w którym sprawdzane jest, czy identyfikator użytkownika żądania odpowiada identyfikatorowi użytkownika konta:

Przykładowy snippet

Deweloperzy vs. Bezpieczeństwo: Przyjaciele czy wrogowie?

Zdarza się, że programiści i zespół bezpieczeństwa nie mają ze sobą zbyt wiele wspólnego. Może to wynikać z faktu, że mają oni w pewnym sensie sprzeczne interesy. Programiści mogą być skupieni na tworzeniu użytecznych funkcji (a.s.a.p.) i współpracować z zespołami bezpieczeństwa tylko podczas prowadzenia dochodzeń, naprawiania błędów i wprowadzania zmian w podatnym kodzie. Zespoły ds. bezpieczeństwa (np. SecOps i/lub AppSec) mogą skupiać się bardziej na tym, aby programiści pisali bezpieczne oprogramowanie i używali bezpiecznych zależności. Mogą również tworzyć ścieżki bezpieczeństwa poprzez szkolenia, testy, narzędzia i integrację potoków. Będą także badać zdarzenia, które mogą być incydentami lub naruszeniami bezpieczeństwa.

Podsumowując, programista chce tworzyć nowe linie kodu, aby jak najszybciej tworzyć funkcje, natomiast zespoły ds. bezpieczeństwa chcą, aby były one staranne i bezpieczne. Jak możemy sprawić, aby te zespoły lepiej ze sobą współpracowały?

Cisco AppDynamics z Secure Application

Cisco może pomóc w rozwiązaniu tego konfliktu interesów. Niestety, nie rozwiąże go całkowicie, ale może pomóc w złagodzeniu niektórych tarć.

Narzędzie to może wykrywać luki w zabezpieczeniach na poziomie zależności kodu aplikacji i konfiguracji w produkcji z automatyczną ochroną runtime. W sposób ciągły monitoruje ono podatności, aby automatycznie wykrywać, a nawet blokować exploity, maksymalizując szybkość i czas działania przy jednoczesnym minimalizowaniu ryzyka. Jak wspomniano wcześniej, Cisco Secure Application to rozwiązanie Runtime Application Self-Protection (RASP)

dla nowoczesnych aplikacji, które chroni przed atakami, aby zapobiec naruszeniom. Co najważniejsze, rozwiązanie to upraszcza cykl życia poprawek luk w zabezpieczeniach, zapewniając wspólny interfejs do pracy zarówno programistom, jak i zespołom ds. bezpieczeństwa. Mała uwaga: w momencie pisania tego wpisu Cisco Secure Application działa tylko dla agenta Java AppDynamics, ale wsparcie jest obecnie rozszerzane na pozostałe agenty.

Dotarłeś do końca tego wpisu na blogu! Dzięki! W nagrodę mam dla Ciebie jeszcze kilka informacji, które możesz sprawdzić:

Chętnie dowiemy się, co o tym myślisz. Zadaj pytanie lub zostaw komentarz poniżej.
Bądź na bieżąco z Cisco DevNet w serwisach społecznościowych!

LinkedIn | Twitter @CiscoDevNet | Facebook | Developer Video Channel

Share

:

Czytaj dalej: https://blogs.cisco.com/developer/pythonvulnerabilities01

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.