Odpowiadając na pytanie z komentarzy - wybrałem FrogCMS, a później przeszedłem na WolfCMS (fork tego pierwszego). Zmiana wynikła z braku aktywności tego pierwszego projektu, a na wszelki wypadek (potencjalne błędy) wolę korzystać z czegoś, co przynajmniej daje nadzieję na wypuszczenie poprawek. Wybór tego konkretnego rozwiązania wynikał z faktu, że ten CMS jest dość minimalistyczny, by nie powiedzieć prymitywny. Jego funkcjonalność była dla mnie w zupełności wystarczająca, choć nie wykluczam, że teraz wybrałbym coś w stylu projektu jekyll.
O wyborze (nie tylko) CMS II
Dlaczego tak dużą wagę przywiązuję do prostoty wybranego rozwiązania? Ilość błędów jest funkcją ilości linii kodu. Jeśli mam taką możliwość, to staram się ograniczać ilość funkcji do niezbędnego minimum. W ten sposób ograniczam ilość kodu, a więc pośrednio zmniejszam również ilość potencjalnych błędów bezpieczeństwa. Lubię projekty, które składają się z niewielkiej "części podstawowej", a dodatkowe funkcje mogą być wprowadzane poprzez mechanizm pluginów.
Tu pojawić się może pytanie, czy kod, który jest nieużywany jest rzeczywiście taki groźny? Przecież teoretycznie nie powinien się nigdy wykonać. W przypadku aplikacji internetowych wcale nie musi tak być. To, że jakaś funkcjonalność nie jest dostępna bezpośrednio (np. z GUI), wcale nie znaczy, że nie można jej wywołać wysyłając odpowiednie żądanie lub odpowiednio manipulując parametrami. W logach serwerów stosunkowo często można znaleźć ślady po próbach odwołań do różnego rodzaju "edytorów", szczególnie tych, które oferują funkcje zarządzania obrazami, w szczególności możliwość uploadu plików. Po prostu kilka błędów w takich funkcjach się trafiło. Inne ciekawe ślady, to próby odwołania do skryptów instalacyjnych. Czuję się spokojniej, gdy tego nadmiarowego kodu po prostu nie ma.
Pisałem wcześniej, że warto spojrzeć na historię błędów wybranego projektu. W przypadku FrogCMS/WolfCMS nie na wiele to się zdaje. Nie są to zbyt popularne projekty, wiec stosunkowo czysta kartoteka niewiele mówi. Dla WolfCMS na chwilę obecną zgłoszony jest bodajże jeden problem: Wolf CMS Arbitrary User Creation CSRF, dość trywialny błąd CSRF (więcej o CSRF: Lekcja 4: Cross Site Request Forgery, Lekcja 5: Cross Site Scripting i Cross Site Request Forgery).
Porównanie informacji o błędach będzie ciekawsze dla WordPress i Serendipity, ale to już w kolejnych odcinkach. Z drugiej strony sama lista zgłoszonych błędów dla Drupala daje do myślenia. Po pierwsze jest ich dużo. Po drugie warto poświęcić chwilę czasu i zobaczyć ile z tych podatności jest w "samym" Drupalu, a ile w dodatkach do niego. Podobnie zresztą jest często w przypadku błędów dotyczących innych projektów. Jakoś pluginów jest bardzo często niższa, niż jakość "głównego" kodu. Teoretycznie można zakładać, że w takim przypadku pojawi się nowa wersja projektu, wystarczy zaktualizować zainstalowaną wersję i problem znika. By tak było projekt musi pozwalać w łatwy sposób odseparować swoją "część główną" od "dostosowań", które użytkownik do niego wprowadza. Z drugiej strony użytkownik powinien z tego sposobu korzystać, bo później może okazać się, że proces aktualizacji wcale nie jest taki bezproblemowy.
Skoro mowa o aktualizacjach. Ostatnio pojawiła się nowa wersja WolfCMS i w ramach aktualizacji z bazy zniknęli mi wszyscy użytkownicy. W moim przypadku wszyscy oznaczają sztuk jeden, więc nie było większego problemu w jego odtworzeniu i odzyskaniu dostępu do CMS. Cóż, nikt nie obiecywał, że skrypty instalacyjne/aktualizacyjne działają bez problemów :)
Pod koniec stycznia odbędą się dwa spotkania OWASP: OWASP Kraków - 20 stycznia, OWASP Warszawa - 27 stycznia, Ciekawy jestem jak wypadnie panel dyskusyjny dotyczący ASVS. Na temat ASVS mówiłem i pisałem niejednokrotnie. Bardzo podoba mi się pomysł,
Przesłany: Jan 16, 12:21