Dziś kilka refleksji odnośnie wyboru narzędzia (CMS/platforma blogowa), a wszystko pośrednio pod wpływem dyskusji dotyczącej wpisu Jeden 0-day i.... Oczywiście nie musicie się zgadzać z moimi pomysłami/wskazówkami, ale być może dla kogoś będzie to przydatne.
O wyborze (nie tylko) CMS
Jako przykład do tego wpisu posłuży mi historia mojego "projektu", czyli przewodnika po bezpieczeństwie aplikacji internetowych. Na początku były to zwykłe strony HTML, ale w pewnej chwili zarządzanie treścią stało się zbyt uciążliwe. Nie chodziło nawet o samą treść, ale o całą "oprawę". Strony te nie są zbyt skomplikowane, ale choćby utrzymanie spójności w takim przypadku było trudne. Wówczas postanowiłem znaleźć "jakiś CMS", z którego użyciem będzie mi po prostu łatwiej.
Na początku warto odpowiedzieć sobie na pytanie co się chce osiągnąć. W tym przypadku jest to niezbyt rozbudowany serwis o małej oglądalności. Nie potrzebowałem funkcji zaawansowanych systemów CMS, nie potrzebowałem również wydajności wystarczającej do obsługi "połowy onetu". Dlatego na Open Source CMS Demos szukałem czegoś małego. Założyłem sobie, że narzędzie powinno wymagać wyłącznie PHP i SQLite, ten drugi warunek był dla mnie kluczowy.
Dlaczego tak upierałem się przy SQLite? Bo tak jest prościej. Prosty backup, proste recovery, prosta migracja, wydajność w zupełności wystarczająca. A do tego kilka rzeczy w bonusie. SQLite jest prostą bazą, więc możliwość penetracji serwera przez SQLi jest ograniczona. Nie tak, jak w przypadku tych większych (patrz: Advanced SQL injection to operating system full control). A do tego wiele (większość?) narzędzi do exploitowania błędów typu sql injection po prostu SQLite nie uwzględnia. To takie dodatkowe utrudnienie na wypadek istnienia tego typu błędów w wybranym oprogramowaniu.
Załóżmy, że kilka projektów spełnia wszystkie wymagania. Który wybrać? Na co zwrócić uwagę?
Pierwsza kwestia - warto zwrócić uwagę, czy dany projekt jest (bardzo) młody, czy ma już pewną historię. Do projektów we wczesnych fazach rozwoju podchodzę z dużą dozą nieufności. Jeśli projekt ma zdefiniowaną jasną drogę rozwoju, to wielki plus dla niego. Często jednak ma się do czynienia z czymś, co określam jako cheerful developement. Korzystanie z takiego produktu wcale nie jest radosne, nie jest też efektywne... Oczywiście można zaangażować się w rozwój takiego projektu jeśli ktoś ma czas/wiedzę/chęci, tylko nie (zawsze) o to chodzi. Ja chcę korzystać z narzędzia, a nie spędzać godzin nad zgłębianiem wiedzy tajemnej dotyczącej tego, jak ono działa, albo częściej - nie działa. A przynajmniej chciałbym, by ilość magii, którą muszę sobie przyswoić, była jak najmniejsza. To nie jest pochwała ignorancji, szukam narzędzia do realizacji konkretnego celu. Wsiadając do samochodu/pociągu/samolotu chcę dostać się z punktu A do punktu B i do realizacji tego celu nie potrzebuję znajomości procedur serwisowych nowoczesnych silników spalinowych czy licencji pilota. Nie widzę powodu, dla którego w przypadku narzędzie "informatycznych" miałoby być inaczej. To, że jestem informatykiem (z papierami) niewiele tu zmienia.
Jeśli projekt ma jakąś historię warto zwrócić uwagę na kilka kwestii, na przykład:
- dostępną dokumentację,
- kto go używa,
- historię błędów bezpieczeństwa,
Temat dokumentacji po części jest związany z tym, o czym pisałem wcześniej. Wolałbym znaleźć odpowiedź na nurtujące mnie pytania w dokumentacji projektu, a nie jego źródłach. To tak z perspektywy zwykłej używalności. A co z bezpieczeństwem? Warto sprawdzić, czy w dokumentacji znajduje się jakiś rozdział związany z bezpieczeństwem. Na przykład wskazówki związane z prawidłową instalacją i konfiguracją takiego systemu (w tym wypadku - CMS). Idealnie byłoby, gdyby w dokumentacji dostępny był opis architektury bezpieczeństwa systemu lub zasad przyjętych i konsekwentnie stosowanych w trakcie tworzenia kodu. Niestety, tego typu oczekiwania są chyba wciąż nieco przesadzone, choć istnieją projekty, które tego typu informacje udostępniają, na przykład w takiej formie jak OpenBSD: OpenBSD Security.
Poza ujęciem zagadnień związanych z bezpieczeństwem w dokumentacji, dobrze jest, gdy bezpieczeństwo jest w pewien sposób wyróżnione. Chodzi mi o wyraźne "znakowanie" informacji związanych z bezpieczeństwem projektu/produktu. Po prostu dobrze jest móc znaleźć tego typu informacje w jednym miejscu. Wygodniej jest je wówczas śledzić, a jest to (śledzenie) dość istotne. W tym wypadku również chciałbym śledzić informacje o ewentualnych błędach w wykorzystywanym przeze mnie oprogramowaniu w sposób możliwie najmniej uciążliwy.
Dlaczego dobrze jest wiedzieć kto korzysta z danego projektu? Mógłbym tu pisać coś o "zaufaniu", bo przecież skoro z projektu X korzystają takie firmy/organizacje jak Y, to na pewno jest on doskonały. Zbyt wiele razy jednak widziałem powszechnie wykorzystywane aplikacje (nie mam tu na myśli systemów CMS), które pod względem bezpieczeństwa prezentują się w sposób opłakany (ach te miliony much nie może się mylić). W tym wypadku bardziej chodzi mi o określenie, jak intensywnie dany produkt jest wykorzystywany. Jeśli jest używany przez trzech zapaleńców na całym świecie, raczej ciężko oczekiwać, by produkt miał swoją "historię" w bazie błędów (np. National Vulnerability Database, Open Source Vulnerability Database), więc "czysta karta" w takim przypadku niewiele mówi. W przypadku projektów wykorzystywanych bardziej intensywnie, bazy takie mogą dostarczyć podstaw do wnioskowania na temat bezpieczeństwa określonej aplikacji.
O tym jakie wnioski można wyciągnąć na podstawie informacji z baz błędów oraz co można w miarę łatwo sprawdzić w kodzie - w kolejnych odcinkach.
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
Przesłany: Jan 03, 07:48
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