Niedawno Departament Obrony Stanów Zjednoczonych (DoD) opublikował przewodnik zatytułowany "Detecting Agile BS". Odkładając na bok lekki tytuł z poważnej agencji rządowej, dokument przyniósł kilka powszechnych błędnych przekonań na temat rozwoju i narzędzi Agile w ostrym świetle. W dzisiejszych czasach, w dobie marketingowych buzzwordów, karnawałowych barkerów i nadmiaru informacji, trudno jest zdystansować się do tego, co jest naprawdę ważne.
Podczas gdy rozwój Agile jest z pewnością najważniejszy dla wielu zespołów programistycznych, bezpieczeństwo mobilne nie jest tak dojrzałe i nie mówi się o nim tak dużo. Niemniej jednak, nadal obserwujemy znaczną część BS-ów związanych z bezpieczeństwem aplikacji mobilnych. Wiele osób testuje bezpieczeństwo sieci i aplikacji internetowych od lat, ale testowanie bezpieczeństwa aplikacji mobilnych jest wciąż w powijakach. Jeśli więc naśladownictwo jest najszczerszą formą pochlebstwa, oto mój przykład testowania bezpieczeństwa aplikacji mobilnych.
Kluczowe podstawy bezpieczeństwa aplikacji mobilnych
W ciągu ostatniej dekady, NowSecure zbudowało imponujący zestaw najlepszych praktyk bezpieczeństwa mobilnego. Czerpiemy również z branżowych standardów i wytycznych, takich jak Open Web Application Security Project (OWASP). OWASP jest znakomitym źródłem wiedzy na temat bezpieczeństwa aplikacji internetowych, a ostatnio podniósł poziom bezpieczeństwa aplikacji mobilnych. Niektóre z kluczowych założeń, które wykorzystujemy do wspierania potrzeb naszych klientów w zakresie aplikacji mobilnych to:
Te kluczowe flagi ostrzegawcze mogą wskazywać, że narzędzie nie przeprowadza odpowiednich testów aplikacji mobilnych:
- Narzędzie nie potrafi analizować pakietów binarnych. Pakiety binarne zawierają komponenty, które mogą sprawić, że aplikacje będą podatne na ataki, a których nie można znaleźć poprzez przegląd kodu źródłowego.
- Narzędzie używa emulatorów do testowania aplikacji mobilnych. Emulatory nie symulują w pełni tego, co może zrobić fizyczne urządzenie i sieć, pozostawiając możliwe do wykorzystania luki w pokryciu.
- Narzędzie wykonuje tylko testy statyczne. Brak dynamicznego testowania binarnej wersji aplikacji na fizycznym urządzeniu pozostawia niewiarygodne luki w testach, szczególnie dla danych w spoczynku i danych w ruchu.
- Narzędzie nie posiada parytetu funkcji pomiędzy iOS i Android. iOS może być trudny do przetestowania, ale jest również podatny na podatności wysokiego ryzyka i musi być testowany z takim samym rygorem jak aplikacje Android.
- Narzędzie opiera się na ludziach do przeprowadzania testów. W świecie DevOps, wszystko opiera się na automatyzacji i nie ma sposobu, aby dodać wystarczająco dużo wykwalifikowanych analityków bezpieczeństwa, aby dotrzymać kroku wydaniom.
Istnieją trzy kluczowe elementy programu testowania aplikacji mobilnych, które należy rozważyć. Poniżej przedstawiamy ich zarys wraz z kilkoma przykładami.
Pytania, które należy zadać skanerom aplikacji webowych/statycznych:
- Jak testować ataki typu Man-in-the-Middle?
- Zła odpowiedź: Badanie kodu. Komunikacja sieciowa może być testowana tylko z aplikacją poprzez DAST na prawdziwym urządzeniu.
- Jak testować dane w stanie spoczynku?
- Błędna odpowiedź: Tylko statyczne. Aby przetestować przechowywanie danych, musisz uruchomić aplikację i zobaczyć wszystkie różne sposoby i metody, których używa do przechowywania danych na urządzeniu.
- Jak rozwijać nowe funkcjonalności mobilne?
- Większość dostawców testujących aplikacje internetowe nie posiada dedykowanych zespołów z doświadczeniem mobilnym.
- Jak szybko można generować wyniki?
- Błędna odpowiedź: Codziennie, co tydzień, co dwa tygodnie. DevSecOps wymaga czasu testowania liczonego w minutach, a nie dniach.
- Pokaż mi, jak pokrywasz OWASP Mobile Top 10.
- Błędna odpowiedź: Statyczność obejmuje wszystko. Tak naprawdę tylko część z trzech z 10 może być zidentyfikowana poprzez analizę statyczną.
- Jakich urządzeń używasz do przeprowadzania testów dynamicznych?
- Błędna odpowiedź: Brak. Wielu dostawców przeprowadza proste skanowanie punktów końcowych API, ale nie testuje rzeczywistej aplikacji.
- Jakie platformy kodowe obsługujesz? Czy wspierasz narzędzia XAMARIN, cross-platform i low-code?
- Błędna odpowiedź: Tylko Native. Większość narzędzi nie jest w stanie przetestować platform hybrydowych. Zapytaj, jak szybko będzie oferować wsparcie.
- Jak wypadają Twoje testy iOS w porównaniu do Androida?
- Błędna odpowiedź: Nie musimy testować tak dużo na iOS. Testowanie na urządzeniach z iOS jest o wiele trudniejsze, wymaga jailbreakingu lub wstrzyknięcia kodu, gdzie dynamiczne testowanie na urządzeniu jest jedyną opcją - ale podatności są takie same.
Pytania, które należy zadać "dynamicznym" testerom:
- Na jakich urządzeniach przeprowadzacie testy i gdzie znajdują się te urządzenia?
- Zła odpowiedź: Emulatory. Najlepiej testować swoje aplikacje mobilne na urządzeniach lokalnych lub na farmie internetowej.
- Jak wypadają Twoje testy na iOS w porównaniu do Androida?
- Błędna odpowiedź: Są takie same. Testowanie iOS jest o wiele trudniejsze, nie będą miały parytetu funkcji.
- Jak szybko zwracasz wyniki testów w potoku DevOps?
- Zła odpowiedź: Wszystko, co trwa dłużej niż 30 minut. Ważne jest, aby upewnić się, że wyniki mogą być również konsumowane przez API, w przeciwnym razie nie można prawdziwie zintegrować.
- Czy oferujecie testy na iOS?
- Zła odpowiedź: Nie. Jailbreaks nigdy nie są wystarczająco spójne, aby postawić swój biznes na.
Poniższy obraz jest pomocne drzewo decyzji, które prowadzi Cię przez zadawanie właściwych pytań, aby dostać się do sedna tego, co produkty dostawcy naprawdę zrobić.
Mam nadzieję, że znalazłeś ten blog cenne w kategoriach obierania warstw roszczeń dostawców vs rzeczywistość. Wszyscy chcielibyśmy żyć w świecie no-BS, ale to jest tam i musimy rozpoznać, kiedy to się dzieje. Poza pytaniami powyżej mamy listę kontrolną, która może okazać się cenna, jak również.
