O unikaniu WAF

Z "laurkami bezpieczeństwa" mam ten problem, że nie bardzo wiem jakie mają być kryteria ich przyznawania. Zwłaszcza jeśli weźmie się pod uwagę, że test bezpieczeństwa/penetracyjny z zasady nie jest działaniem formalnym, takim jak audyt, choć terminy te często są (błędnie) używane zamiennie. OWASP ASVS to moim zdaniem krok w dobrym kierunku, choć muszę przyznać, że przy kilku próbach jego użycia - zatrzymałem się. Miałem wątpliwości, do którego momentu aplikacja dany punkt jeszcze spełnia, a kiedy już nie. Oczywiście, jeśli "laurka bezpieczeństwa" rzeczywiście ma być wyłącznie "laurką", wówczas te rozważania tracą sens. Tylko ja się nie podpiszę pod taką laurką, która poświadcza nie wiadomo co. To taka luźna refleksja w oderwaniu od tematu WAF

W sumie Wasze komentarze (wszystkie trzy do tej pory) są zgodne z moimi oczekiwaniami. Sam jednak zwykle kładę większy nacisk na testy samej aplikacji, a nie całej infrastruktury. W związku z tym wydaje mi się, że sensowne jest najpierw sprawdzenie aplikacji bez WAF, a później próba wykorzystania znalezionych podatności z włączonym WAF, czy nawet szersza analiza jego konfiguracji.

Testowanie "przez" WAF przypomina mi trochę testowanie aplikacji z mocną walidacją danych wejściowych. Jeśli walidacja jest dobra (reguły WAF dobre), to niewiele udaje się osiągnąć. Empirycznie nie można stwierdzić jak realizowany jest encoding danych albo jak realizowany jest dostęp do bazy danych (budowane zapytania SQL co wprost łączy się z SQLi). Później okazuje się, że występują "drobne" zmiany w warstwie odpowiadającej za walidację i nagle okazuje się, że "głębiej" jest mocno źle. Dlatego czasami chyba nawet wolę, gdy aplikacja ma usterki w walidacji i widzę, że działa druga czy trzecia linia obrony

Przy całej mojej sympatii do WAF, uważam, że aplikacja powinna bronić się bez nich. Choćby dlatego, że WAF nagle może zniknąć, tak jak pisze Przemek (sytuacja analogiczna do "nagłego" zepsucia walidacji).