Ile to razy byłem świadkiem (bo staram się nie brać bezpośredniego udziału w takich rozmowach, bo zazwyczaj nie mają one większego sensu) debaty nad wyższości dedykowanego CMSa nad ogólnodostępnym, z otwartym kodem, gdzie każdy może zaglądać i… szukać dziur, co z automatu sprawia, że tego typu rozwiązania są mniej bezpieczne. Oczywiście ciężko mi się z tym zgodzić, bo o ile faktycznie do kodu może zajrzeć każdy, to życie już nie raz pokazało, że odbywa się to z korzyścią dla oprogramowania, bo dzięki temu można skorygować problemy, również te związane z bezpieczeństwem.
Spis treści w artykule
WordPress 1 – 0 „własny CMS” (tym razem)
Ze wszystkich CMSów najczęściej korzystam z WordPressa, i jak przystało na rozbudowany system, tak i tutaj zdarzają się czasem jakieś problemy z (nie)bezpieczeństwem. Na szczęście są one dość szybko naprawiane, w dużej mierze właśnie dzięki ogólnodostępnemu kodowi, i rzeszy pasjonatów, którzy poświęcają swój czas na jego analizowanie. No chyba, że jakiś „magik” wyłączy aktualizacje lub korzysta z komercyjnych wtyczek „z drugiego obiegu”.
Ale to, że lubię WordPressa (i kilka innych systemów, z których korzystam do innych zadań) nie znaczy, że nie zdarza mi się korzystać z autorskich rozwiązań. Wręcz przeciwnie – często, gdy potrzebuje przygotować jakieś rozwiązanie, to wolę odpalić Notepad++ i samemu je przygotować. Ale mam też świadomość, że im projekt bardziej się rozrasta, tym trudniej zapanować nad kodem, i coraz więcej czasu zamiast na rozwój idzie na kolejne elementy, które mają zapobiegać ewentualnym podatnością. Ale w pewnym momencie, przy pewnej skali, zwłaszcza gdy dodamy do tego jeszcze rotacje wśród personelu nie ma szans – prędzej czy później jakiś błąd się pojawi. Nie mówiąc już nawet o tym, że często nawet przy autorskich rozwiązaniach, korzysta się z… zewnętrznych bibliotek, a więc…
Niedawno podobną rozmowę odbyła u siebie w pracy koleżanka, gdy firma zdecydowała się na uruchomienie – obok istniejącej strony internetowej – bloga. Z racji tego, że koleżanka ma doświadczenie z WordPressem i blog znalazł się w zakresie jej obowiązków, to zaproponowała tego CMSa. Decyzja zapadła, choć oczywiście nie obyło się bez drobnych przepychanek „WordPress vs autorski CMS” (wygrał WordPress, zapewne dzięki temu, że ekipa z działu IT nie musiała właściwie nic robić ;-)) .
Błąd połączenia z bazą danych
I tak sobie funkcjonowały obie strony spokojnie na jednym serwerze, aż do dziś, gdy z jakiś przyczyn usługa odpowiedzialna za bazy danych (zapewne MySQL) się wysypała. Zdarza się, od tego jest monitoring, który oprócz tego, że poinformuje o zdarzeniu, dobrze jak spróbuje też naprawić sytuację (np. poprzez restart usługi, czy ew. nawet całego serwera).
Ale awaria pokazała też, że o ile WordPress w przypadku problemów z bazą danych pokazuje nieciekawy komunikat (choć można ustawić własny), który poza podstawową informacją (tak, można zmienić ;-)) nie ujawnia żadnych wrażliwych informacji:
Błąd łączenia się z bazą danych
Trochę inaczej sytuacja wyglądała w przypadku „trochę bardziej autorskiego CMSa”:
Piękny komunikat błędu, z którego od razu możemy wywnioskować co się dzieje, a przy okazji każdy kto akurat wszedł na stronę mógł poznać ścieżki bezwzględne plików na serwerze, do tego komplet danych związanych z bazą danych (nazwa bazy, nazwa użytkownika i hasło, port). Autor może i chciał dobrze, tylko nie pomyślał, że w takiej sytuacji komunikat błędu zobaczy każdy, nie tylko dział IT firmy. Zapewne zabrakło testów, skali… użytkowników, którzy by sprawdzali kod, sprawdzali konfigurację…
W razie w…
Błędy się zdarzają, dlatego warto już na etapie wstępnej konfiguracji brać to pod uwagę. Jeśli pliki związane ze stroną działają na tym samym serwerze co baza danych, to warto w bazie danych ustawić tak, że wykorzystywany przez skrypty (np. PHP) użytkownik może łączyć się z bazą danych tylko lokalnie (localhost). Dzięki temu nawet gdy zdarzy się błąd taki jak powyżej, osoby postronne nie będą mogły połączyć się z bazą danych, korzystając ze zdobytych przypadkowo danych.
Jeśli baza danych znajduje się na innym serwerze, to możemy ustawić konkretne IP, z którego dany użytkownik może się z bazą łączyć. Jeśli ze względów serwisowych (np. kopia zapasowa bazy danych) potrzebujemy kolejnego użytkownika, to również ustalamy konkretne IP, lub zamiast bezpośredniego połączenia, korzystamy np. z SSH.
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.
Dumny przyjaciel swoich psów :-)
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
Wprawdzie WordPress idealny nie jest ….ale zwykle najbardziej na jego temat ujadają osoby, które mają o nim najmniejsze pojęcie.
A z autorskimi CMSikami, to z wieloletnich obserwacji podzielił bym ich fanów na dwie grupy:
1. cwaniacy, wciskają innym to, czego potem raczej nikt inny kijem nie będzie chciał ruszyć. A jeszcze ciach takim ionCube i już klient uwiązany i za każda pierdółkę można ładnie kasować.
2. ludki z ego większym od wiedzy i umiejętności.
O ile pierwszy przypadek jeszcze jakoś można zrozumieć, to drugi całkowicie rozkłada na łopatki.
I nie ma z takim nawet co dyskutować, bo i tak raczej nie zrozumie.
W sumie mam podobną obserwację, ba, mam znajomego, co gdy go poznałem, to tylko „autorski CMS”, a nie jakieś dziurawe WordPressy… A teraz? Nawet nie pytam się go na czym postawił ostatnią (kolejną) stronę, bo wiem, że… na WordPressie. Choć moim podstawowym systemem jest Windows, i na razie nic nie zapowiada by miało się to (szybko) zmienić, to ogólnie jestem zwolennikiem Open Source, zwłaszcza że już nie raz mieliśmy przykłady, że co tysiące oczu to nie…
Co do rozwiązań typu ionCube, to tu mam mieszane uczucia. Z jednej strony faktycznie często są wykorzystywane do tego, by trzepać kasę nawet za najdrobniejszą „poprawkę”, a znam przypadek, gdzie wewnętrzny dział IT stosował, tylko po to by zabezpieczyć się przed ich wywaleniem z pracy. Ale z drugiej strony, sam tworzę rozwiązania, których np. nie mogę „przekazać” jako usługi (SaaS) i muszę kod przesłać do zamawiającego. I choć uwzględniam wtedy to, że ktoś mi płaci za przygotowanie narzędzia a nie za korzystanie, i tym samym gdy zapłaci, to może robić z tym właściwie co chce, to są takie rozwiązania czy modele biznesowe, gdy nabywca świadomie decyduje się na subskrypcję (jednorazowo drożej, lub w ramach subskrypcji taniej, czyli jakby na raty) i wtedy taki ionCube może być jedyną ochroną. Bo niepłacącego klienta (ech…) od usługi świadczone w modelu SaaS zawsze możesz odciąć, ale gdy przekażesz mu kod (w przypadku PHP to w sumie pliki tekstowe, które dowolnie można modyfikować) to w tym momencie tracisz przewagę. Oczywiście pomijam celowe błędy, czy dostęp do aktualizacji.
I dla jasności – obecnie na serwerach nie korzystam z żadnego oprogramowania webowego, które byłoby „zaciemnione” (pomijam tutaj oczywiście skompilowane paczki, czy programy, zwłaszcza w Windowsie ;-)). Ale też gdy mam do wyboru jednorazowy i droższy zakup lub subskrypcje, zazwyczaj wybieram jednorazowy zakup. Dla świętego spokoju… :-)
W pewnych sytuacjach może i ma jakiś sens, ale gdy klient zamawia stronę, motyw czy wtyczkę i dostaje zakodowane coś i nawet nie jest o tym informowany, to słabo.
A co do ochrony, to własnie w odpowiednio zaprojektowanym SaaS nie potrzeba szyfrować kodu, po uwaleniu klienta po swojej stronie ten zostaje z wydmuszką i niech sobie ją modyfikuje do ukichanej …
A jak to nie SaaS, to albo klient dostaje tylko dostęp do środowiska testowego, a kod dopiero po zapłacie.
Albo odpowiednia zaliczka, czy podział pracy (i płatności) na etapy wraz z odpowiednim zabezpieczeniem w umowie. Można i zrobić pseudo SaaSa, a samodzielnego gotowca dawać dopiero na finiszu. Możliwości jest wiele.
Co do SaaS to właśnie to miałem na myśli – tutaj w każdej chwili możemy odciąć nierzetelnego klienta, bo to usługa, a tym samym nie ma ryzyka, że… Gorzej wygląda sytuacja w przypadku gdy kod trafia do klienta (nie SaaS), który od tego momentu staje się jego panem (pomijam ew. aspekty prawne), stąd rozumiem, że czasem ktoś może zdecydować się na tego typu (np. ionCube) zabezpieczenie. Zwłaszcza przy bardziej rozbudowanych i droższych platformach, gdzie ew. piractwo mogłoby znacznie wpłynąć na rentowność biznesu (trochę jak oprogramowanie na komputerach, gdzie najczęściej mamy już skompilowane binarki). Ale to są wyjątki, i w większości przypadków nie widzę potrzeby by stosować takie ograniczenia w przypadku rozwiązań opartych np. o PHP. A już na pewno nie w sytuacji, gdy ktoś płaci za przygotowanie jakiegoś rozwiązania, logicznie zakładając, że po uregulowaniu zobowiązań finansowych stanie się jego właścicielem, i jeśli zajdzie taka potrzeba, to będzie mógł niezależnie rozwijać kod. Chyba, że – jak piszesz – obie strony umówiły się wcześniej na takie rozwiązanie.
Nie chcę też by zabrzmiało to jakbym był zwolennikiem modelu SaaS, z którego zdarza mi się korzystać (np. księgowość internetowa). Ale w większości przypadków tam gdzie ma to jakiekolwiek uzasadnienie (np. ekonomiczne) staram się korzystać czy to z własnych rozwiązań, czy rozwiązań zewnętrznych, ale umożliwiających instalację na mojej maszynie. Tak samo jak nie przepadam za subskrypcyjnym modelem, który niestety zaczyna coraz bardziej się panoszyć – programowanie, wtyczki, np. do WordPressa… Można by długo tak wymieniać. Choć rozumiem, że dla sprzedawcy może to być korzystne rozwiązanie – nie dość, że łatwiej sprzedać produkt gdy sprawia wrażenie tańszego (subskrypcja = raty), to jeszcze zapewnia stały dochód, bo są takie miejsca, gdy jak się już wejdzie, to nie tak łatwo zrezygnować…