Pułapki “profesjonalnego” CMS
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.
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ń.
Oryginał tego wpisu dostępny jest pod adresem Pułapki “profesjonalnego” CMS
Autor: Paweł Goleń