W trakcie testów bezpieczeństwa aplikacji nie jestem zwolennikiem podejścia "czarnego pudełka". Wychodzę z założenia, że celem testów jest identyfikacja jak największej ilości podatności oraz słabości (słabość nie jest tożsama z podatnością). Wszystko po to, by bezpieczeństwo aplikacji poprawiło się.
Różne odcienie szarości
Wiele razy zwracałem uwagę na dysproporcję między atakującymi a testującymi. Jest ICH zdecydowanie więcej i mają ONI więcej czasu. Dlatego uważam, że sam proces testowania powinien być jak najbardziej efektywny. Możliwość sprawdzenia w kodzie aplikacji podejrzanych miejsc jest w takim przypadku bardzo przydatna.
Posłużę się przykładem, jego rolę będzie pełniła kolejna wersja wyzwania, z którym tak doskonale poradził sobie Krzysiek Kotowicz. Zakładam, że zidentyfikowanie miejsc, w których może występować błąd typu sql injection nie powinno być wielkim problemem. W razie czego można zastosować podejście opisane w tym przykładzie. Słabość istnieje. Czy i jak można ją wykorzystać?
Jakiś czas temu przygotowałem nową wersję zadania. Jak na razie zabrał się za nią chyba tylko Krzysiek Kotowicz, oczywiście jak zwykle z sukcesem. Samo zadanie nie jest zbyt trudne, występujące warianty sql injection nie różnią się wiele od tych już opisa
Przesłany: May 03, 10:27