Paweł Goleń, blog

Nie jestem programistą, nigdy nie pracowałem jako programista i tak naprawdę nigdy nie chciałem jako programista pracować. Jeśli ktoś chce, może mnie, (pen)testera, określać jako programistę, któremu nie wyszło (choć nigdy nie próbowałem). Może też w moich wypowiedziach doszukiwać się zawiści wobec Tych, Którzy Programują. A ja mam po prostu osobowość destrukcyjną, wrodzoną skłonność do szukania dziury w całym i sianie zniszczenia sprawia mi radość. Tak więc drodzy programiści - nie obrażajcie się :)

Napiszę to jeszcze raz: programiści zawsze potrafią mnie zaskoczyć. Czasami mechanizm działania jakiejś funkcji w aplikacji jest tak pokrętny, że muszę naprawdę się wysilić, by zrozumieć intencje twórców. Im bardziej złożona (skomplikowana) realizacja funkcji, tym większe prawdopodobieństwo wystąpienia różnych rodzajów błędów, nie tylko tych związanych z bezpieczeństwem. Szczególnie dziwi mi ich stosowanie w przypadkach, gdy to samo zadanie można równie efektywnie zrealizować w łatwiejszy sposób. Być może tu jest właśnie błąd mojego rozumowania? Może nie chodzi o efektywność lecz o efektowność? Drugą rzeczą, która mnie dziwi to fakt, że takie kulawe, przerośnięte rozwiązania wciąż żyją i spotykam się z nimi w kolejnych ich inkarnacjach.

Patrząc z perspektywy wielu różnych przetestowanych aplikacji różnych producentów mam wrażenie, że złe wzorce mają tendencję do rozprzestrzeniania się. Najpierw widać, że pewna funkcja jest realizowana w specyficzny sposób w produktach jednej firmy. Najpierw jednym, później jest powielany na kolejne. W pewnej chwili dochodzi do tego, że można "w ciemno" typować miejsca, w których będą występowały określone podatności. Trudno jest mi powiedzieć, czy wynika to z faktu, że w zespołach tworzących te różne produkty pracują ci sami ludzie, czy być może na drodze wewnętrznego transferu wiedzy inni programiści podchwytują to rozwiązanie. Z czasem to samo rozwiązanie zaczyna pojawiać się w systemach innych dostawców. Zastanawiam się, czy jest to efekt "podpatrywania konkurencji", czy raczej naturalnej rotacji pracowników i przechodzenia ich między firmami.

To, że raz wymyślone rozwiązanie problemu jest wykorzystywane wielokrotnie nie jest niczym złym. Bez sensu jest ciągłe odkrywanie koła na nowo, zresztą od dawna istnieje pojęcie design patterns. Problem w tym, że wykorzystywane i powielane wzorce są często po prostu ZŁE. I nie chodzi mi tu wyłącznie o błędy bezpieczeństwa, ale również o takie kwestie jak wydajność czy wygoda użytkownika.

Testując aplikację często chcę zrozumieć jak ona działa, szczególnie gdy jest w niej wiele automagizmu. Robię wówczas prawdopodobnie to, co robi większość programistów - szukam przykładów, i... widzę, że kwestie bezpieczeństwa nie są w nich uwzględniane. Rozumiem, że nie taki jest cel tych tutoriali, aplikacje są wyłącznie demonstracyjne i mimo tego, że naszpikowane często różnymi podatnościami, to nikt na tym nie ucierpi^w STOP, źle! Właśnie, że ucierpi... Kilka razy po znalezieniu podatności, znalazłem również ich pierwowzór. Wzorzec, na którym opierał się programista. Kod, który realizuje takie zadanie jak ten w badanej aplikacji, i który zawiera dokładnie taką samą podatność, jak ten w przykładzie. Internet to wspaniały wynalazek, zdecydowanie ułatwia dostęp do informacji, wiedzy. Z czasem jednak coraz wyraźniej widać to, że jakość tych informacji i wiedzy spada...

Pytanie do tych kilku programistów, którzy czytają tego bloga. Jak poruszana przeze mnie kwestia wygląda z Waszej strony? Skąd czerpiecie wzorce? Czy zastanawiacie się nad nimi, czy po prostu je kopiujecie bez głębszej refleksji?