Paweł Goleń, blog

Od dłuższego czasu mam pewną ideę. Pisałem już dawno temu, że jestem znudzony wyszukiwaniem podstawowych dość podatności związanych z walidacją danych wejściowych, kodowaniem na wyjściu, prostymi przypadkami SQL injection czy błędami kontroli dostępu do funkcji i do danych. Wyszukiwanie podstawowych przypadków tych wymienionych podatności to praca mozolna, metodyczna, ale również do pewnego stopnia mechaniczna. Nie twierdzę, że w czysto mechaniczny sposób uda się zidentyfikować 100%25 podatności tego typu, z doświadczenia jednak wiem, że jeśli w aplikacji są podatności, to często występują również takie proste błędy.

Moja idea zakłada(ła) nauczenie testerów funkcjonalnych prostych technik, które pozwolą na zidentyfikowanie wymienionych typów podatności. Muszę przyznać jednak, że pomysł ten muszę chyba jednak w pewnym stopniu zrewidować. Teraz coraz bardziej dochodzę do wniosku, że oprócz nauczenia tego, jak mechanicznie szukać prostych podatności, konieczne jest obudzenie w ludziach ukrytego upierdliwca/anarchisty/destruktora.

W trakcie testów funkcjonalności aplikacji główny nacisk jest kładziony na to, czy aplikacja/system działa zgodnie ze specyfikacją. Czy użytkownik jest w stanie wykonać opisane w scenariuszu akcje i czy wynik tych akcji jest zgodny z oczekiwaniami. To nic złego, rzeczywiście głównym celem aplikacji jest to, by działała ona zgodnie z założeniami, a przynajmniej, by działała na tyle dobrze, by dało się jej używać. Ujmując sprawę obrazowo – w trakcie takich testów sprawdzane jest, czy osoba, która ma klucz może otworzyć drzwi i wejść do pomieszczenia. Jeśli tak, to można odhaczyć stosowny przypadek użycia jako przetestowany, działający.

I tu właśnie pora na owo knucie. W tym przykładzie trzeba na testowaną funkcję z szerszej perspektywy. Drzwi chronią dostępu do czegoś. Chronią dostęp, bo są zamykane. Nie każdy może je otworzyć, tylko część użytkowników ma stosowny klucz. Patrząc z tej perspektywy istotne staje się nie tylko to, czy uprawniony użytkownik może otworzyć drzwi, ale również to, czy tych drzwi nie może otworzyć ktoś niepowołany. W jaki sposób mógłby to zrobić? Czy musi otwierać te drzwi? Przecież w zasadzie celem jest nie tyle ich otwarcie, co dostanie się do środka. Może lepiej wejść przez okno/komin/piwnicę/wejście dla psa? A może można wejść do środka razem z drzwiami (nie ma to jak solidne kopnięcie), albo przez ścianę (bo akurat jest z gipskartonu)?

Tu pozwolę sobie na małą dygresję. Kiedyś naprawdę spotkałem się z sytuacją, w której porządne drzwi z kontrolą dostępu były osadzone w umiarkowanie porządnej ścianie. Najłatwiejszym sposobem na znalezienie się w środku było jednak skorzystanie z... podłogi technicznej (przejść pod drzwiami) lub podwieszanego sufitu (przejść nad drzwiami).

Wracając do tematu drzwi. Może akurat w tym konkretnym przypadku wcale nie jest tak ważne, by atakujący dostał się do środka? Tym razem może mu akurat zależeć na tym, by do środka nie dostała się osoba uprawniona. Jak to najprościej osiągnąć? Można na przykład zastosować starą stolarską technikę polegającą na wbiciu zapałek, na przykład w dziurkę od klucza (...)

Coraz bardziej jestem zdania, że oprócz nauczenia “mechaniki testowania”, trzeba próbować obudzić w ludziach tendencję do knucia. To trochę tak, jak w tym przypadku:

Pewnego dnia Inżynier, Fizyk i Matematyk otrzymali zadanie do wykonania. Zadanie polegało na tym, aby stojąc na ziemi, dostępną ilości siatki ogrodzić jak największy teren.
Inżynier stworzył idealny kwadrat i odszedł z dumą.
Fizyk zakreślił idealne koło i pewny wygranej również odmaszerował.
Matematyk. Ten zrobił coś dziwnego. Poustawiał siatkę byle jak, tak aby grodziła „w miarę” mały teren. Następnie wskoczył do środka i zadeklarował, że jest na zewnątrz..

...a może właśnie kompletnie odwrotnie. Normalnie tester ma sprawdzić ten mały kawałeczek “w środku”. Jeśli chce/ma zająć się bezpieczeństwem, musi “wyskoczyć za siatkę” i zacząć patrzeć na testowaną funkcję z drugiej strony (tak przy okazji: Agile Software Development: Don't Forget EVIL User Stories). Nie oczekuję, że nagle każdy tester będzie generował “złe” przypadki testowe jak z rękawa (choć w kimś może uda się obudzić ukryty talent). Istotne jest natomiast uświadomienie faktu, że nie wszyscy użytkownicy aplikacji będą grali zgodnie z regułami i sprawdzenie kilku tych najbardziej oczywistych przypadków, które ONI najprawdopodobniej również dość szybko przetestują.

P.S. Ilu z Was policzyło, czy rację miał inżynier, czy fizyk? Matematyka pomijamy :)

Oryginał tego wpisu dostępny jest pod adresem Knucie jest stanem umysłu

Autor: Paweł Goleń