Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o "autorski, profesjonalny CMS", to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.
Pułapki "profesjonalnego" CMS
Dlaczego tak twierdzę? Przecież ten CMS jest sprzedany w tyle miejsc i działa. Działa. Jakoś. I lepiej go unikać właśnie dlatego, że został sprzedany w tyle miejsc. Problem polega na tym, że takie "autorskie" rozwiązania są często tworzone bez ładu i składu, bez jakiejkolwiek wizji tego, do czego dane rozwiązanie ma służyć i jak to zadanie poprawnie zrealizować. Przy każdym nowym projekcie dopisywane są kolejne fragmenty i to bynajmniej nie jako moduły, ale często jako wielokrotnie rozgałęzione instrukcje warunkowe. W zależności od tego jakie parametry zostaną przekazane i w jakiej kombinacji, zachowanie tego rozwiązania może być kompletnie inne. Oczywiście w części przypadków ścieżka wykonania może zabłądzić w rejony, które nie były używane od dawna, które zawierają jakieś mało istotne podatności pozwalające na wykonanie kodu na serwerze, czy odczytanie dowolnych danych z bazy.
Testowanie bezpieczeństwa aplikacji opartych o takie rozwiązania, to droga przez mękę. Można oczywiście przetestować to, co widać. Wówczas często okazuje się, że aplikacja w tym konkretnym wdrożeniu nie posiada interesujących punktów wejścia, a przynajmniej ich nie widać. Jeśli jednak dopisze się parametr foobar (koniecznie w POST) i parametr ten będzie zawierał znak średnika, przy czym po prawej stronie od średnika musi być jeszcze znak przecinka, to nagle okaże się, że wykona się kod zupełnie niezwiązany z tą aplikacją, ale mimo wszystko operujący na bazie danych, z której ta aplikacja korzysta.
Nawet dostęp do kodu źródłowego nie upraszcza zadania. Może okazać się, że plik zawierający główny fragment logiki odpowiedzialnej za przetwarzanie żądania to kilkaset kilobajtów makaronu inkludujący kilka innych podobnych potworków i nagminnie korzystający ze zmiennych globalnych. W efekcie nawet jeśli znasz wartość zmiennej w linii 15, to ustalenie tego co kryje się w tej zmiennej 5 linii dalej wcale nie jest zadaniem trywialnym. Nawet jeśli ten kod spróbować uruchomić i śledzić jego wykonanie, to i tak nie do końca wiadomo co się właściwie dzieje, bo w tych kilku liniach (oraz całym bloacie wykonującym się w tak zwanym międzyczasie) znajduje się kilkanaście konstrukcji warunkowych, które zależą na przykład od aktualnej konfiguracji CMS, albo od jakiejś zmiennej ustalonej w zupełnie innym miejscu kodu...
Jeśli coś ma być bezpieczne, nie może być (zbyt) skomplikowane. Niestety, takie "autorskie" rozwiązania mają tendencję do nadmiernej złożoności. Oczywiście, część tej złożoności wynika z (dużej) funkcjonalności takich rozwiązań. Z taką złożonością można sobie jednak radzić, na przykład dzieląc system na moduły. Ale te moduły powinny być "zamknięte" i komunikować się przy pomocy dobrze zdefiniowanych interfejsów, a nie paskudnych haków ze zmiennymi globalnymi i tym podobnych "profesjonalnych" rozwiązań.
kiedyś w czasie testów trafiłem na takie "autorskie" rozwiązanie
Tylko po ok. godz analizy, okazało się, że autorstwo jest i owszem...ale raczej innego osobnika.
Stąd tak czy owak, zdarza się albo tak jak wspomniał szanowny autor albo tak, że CMS oparty jest na innym znanym (często tak bezpiecznym jak jego pierwotna wersja)
W czasie swojej kilkuletniej pracy jako programista aplikacji internetowych w PHP miałem wątpliwą przyjemność w "grzebaniu" w paru takich "autorskich" rozwiązaniach. Stopień nieznajomości zagadnień związanych z bezpieczeństwem takich aplikacji często jest porażający.
Kuriozum stanowią przypadki autorskich CMS-ów posiadających poważne luki (SQLi, stored XSS) oferowane przez masę firemek typu "agencja interaktywna". Znalezienie takiej luki w jednym z serwisów, następnie analiza portfolio takiej agencji (z reguły jest to dział szumnie nazwany "wybrane realizacje" tudzież "wdrożenia") - i mamy listę od kilkunastu do kilkudziesięciu serwisów zbudowanych w oparciu o taki CMS, oczywiście większość podatnych na znalezione wcześniej błędy.
Choć przyznam, że wielokrotnie spotykam się z sytuacją, gdy w portfolio znajduję nowe, poprawione wersje, odporne na luki z wersji wcześniejszych. Pewną stwierdzoną przeze mnie empirycznie prawidłowością jest to, że w miarę, jak agencja interaktywna zdobywa coraz lukratywniejsze zlecenia, stopień bezpieczeństwa aplikacji rośnie. Pewnie wynika to z faktu, że większe zlecenia przyciągają do pracy lepszych, lepiej ogarniętych koderów, którzy przy okazji prac nad nowym zleceniem łatają bądź piszą od nowa kod CMS-a/CRM-a/sklepu czy innego produktu.
Nie zmienia to faktu, że widząc "autorski, profesjonalny CMS" mam podobny pogląd na sytuację, jak Ty
pozdrawiam,
bl4de
Niestety, nadal pojęcia takie, jak OWASP ASVS czy choćby biblioteka ESAPI to pojęcia z gatunku abstrakcyjnych dla większości.
Gdy w swojej poprzedniej pracy zorganizowałem mały, kilkugodzinny wykład na tema bezpieczeństwa aplikacji internetowych (gdzie m.in. wspomniałem o tych akurat dwóch projektach OWASP) mogłem podziwiać efekt znany jako "wielkie oczy" w reakcji na to, co prezentowałem
A już autentyczny przykład kompletnego ataku na źle zabezpieczoną aplikację webową wraz z finalnym efektem w postaci zalogowania na konto poczty elektronicznej jednego z zarejestrowanych w atakowanej aplikacji userów wywołał reakcję porównywalną chyba tylko do reakcji publiczności obserwującej sztuczki Davida Copperfielda.
A nie byli to programiści początkujący :/
Naprawdę jestem ciekaw, do czego to wszystko zmierza. Bardzo wielu programistów, nawet z dość długim stażem ma mgliste bądź bardzo niewielkie pojęcie o bezpieczeństwie. W sumie się nie dziwię, bo ilość wiedzy koniecznej do przyswojenia, by w miarę swobodnie posługiwać się dowolną technologią wzrasta niemal w postępie geometrycznym i często gęsto nie mają oni czasu na to, by ogarniać jeszcze tematykę security (która, jak wiesz z autopsji, sama w sobie też jest delikatnie mówiąc obszerną dziedziną).