Większość włamań do aplikacji webowych nie zaczyna się od egzotycznego exploita. Zaczyna się od żądania, które aplikacja powinna była odrzucić: faktury innego klienta, ceny zmienionej po drodze, resetu hasła, który ufa niewłaściwemu nagłówkowi. Skanery nie wykrywają takich błędów, bo nie wiedzą, do czego służy aplikacja.
Testujemy jako zalogowani użytkownicy każdej roli, ustalamy, do czego ma dostęp każda z ról, a potem próbujemy przekroczyć każdą granicę między nimi. Narzędzia automatyczne pokrywają znane klasy podatności. Czas specjalistów przeznaczamy na logikę, kontrolę dostępu i łańcuchy drobnych słabości, które razem pozwalają przełamać zabezpieczenia.
01Zakres
Co testujemy
Uwierzytelnianie, sesje, odzyskiwanie hasła i uwierzytelnianie wieloskładnikowe
Pozioma i pionowa kontrola dostępu, izolacja tenantów
Logika biznesowa: płatności, rabaty, limity, procesy, sytuacje wyścigu
Wstrzykiwanie: SQL, NoSQL, poleceń systemowych, szablonów, zewnętrznych encji XML
Klasa słabości leżącej u podstaw każdego znaleziska.
The MITRE Corporation
06Pytania
Pytania o tę usługę
Black box, grey box czy white box?
Domyślnie grey box: pracujemy z kontami i dokumentacją, bo w dostępnym czasie pozwala to znaleźć najwięcej. Black box ma sens, gdy chcesz zmierzyć, co osiągnie ktoś z zewnątrz bez żadnych informacji. White box obejmuje też kod źródłowy; opisujemy go w usłudze przeglądu bezpieczeństwa kodu.
Czy testujecie na środowisku produkcyjnym?
Wolimy środowisko odpowiadające produkcyjnemu. Jeśli istnieje tylko środowisko produkcyjne, uzgadniamy okna testowe, unikamy działań destrukcyjnych i pracujemy na własnych danych testowych.
Czy skaner podatności nie wystarczy?
Skaner znajduje znane wzorce w pojedynczych żądaniach. Nie wie, że jeden klient nie może widzieć zamówień innego ani że rabatu nie można naliczyć dwa razy. Takie błędy znajdują ludzie, którzy rozumieją aplikację.