Kurs "WordPress: Pierwsze kroki" (bezpłatna lekcja)

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.

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.

(!) Zgłoś błąd na stronie | Lub postaw nam kawę :-)
LUTy dla D-Cinelike (DJI Mini 3 Pro, DJI Avata, OSMO Pocket) od MiniFly
Wdrożenie Omnibusa w sklepie na WooCommerce
Jak (legalnie) latać dronem w Kategorii Otwartej
Kurs "WordPress: Pierwsze kroki" (na dobry początek)
Patryk
Kurs "WordPress: Pierwsze kroki" (na dobry początek)