Paweł Goleń: O wyciąganiu (błędnych) wniosków

nospam@example.com (Paweł Goleń) — Thu, 05 Nov 2009 07:22:11 +0100

Dokładnie, o ile udowodnienie, że aplikacja nie waliduje wszystkich danych jest teoretycznie proste, wystarczy znaleźć pierwszy przypadek, gdy tak nie jest, to potwierdzenie poprawności mechanizmu jest już sporym wyzwaniem. Rozwiązania, o których piszesz, są ciekawe (znajomy się z tego chyba nawet doktoryzował), tylko w przypadku testu bez dostępu do źródeł niestety nieprzydatne :(

Krzysztof Kotowicz: O wyciąganiu (błędnych) wniosków

nospam@example.com (Krzysztof Kotowicz) — Wed, 04 Nov 2009 21:53:14 +0100

Wydaje mi się, że takie podejście (dowodzenie, że walidacja ma miejsce w przypadku wszystkich parametrów wejściowych) bez przebudowy całej aplikacji od początku może być b. trudne (mogą się przydać w większości ubogie narzędzia do statycznej analizy kodu). Ciekawa za to i dość obiecująca wydaje mi się koncepcja tainted data - każda dana wejściowa jest oznaczana jako "skażona" i nie może zostać wysłana na output (bazę danych, kod HTML,...) bez jej wyczyszczenia poprzez użycie np. funkcji escape'ujacej. Na polu PHP w tym zakresie jest ciekawy projekt http://wiki.php.net/rfc/taint - ale, oczywiście, "in the works". Także niestety wszystko jest w powijakach. Ale dzięki użyciu takiego "tainted mode" możnaby uruchomić aplikację w trybie "raportowania" niezwalidowanych danych i odpowiednio reagować (bugfix-jeśli jesteśmyh programistą lub wskazanie podatności-jeśli pentestujemy). Jeśli mamy dobre pokrycie testami, rzecz staje się jeszcze prostsza, bo można ten proces zautomatyzować.

Paweł Goleń, blog - Formularz komentarzy "O wyciąganiu (błędnych) wniosków"

Paweł Goleń: O wyciąganiu (błędnych) wniosków

Krzysztof Kotowicz: O wyciąganiu (błędnych) wniosków