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.

Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!
Spodobał Ci się artykuł? Zapisz się do naszego Newslettera - ZERO SPAMu, same konkrety, oraz dostęp do dodatkowych materiałów przeznaczonych dla subskrybentów!
Na podany adres e-mail otrzymasz od nas wiadomość e-mail, w której znajdziesz link do potwierdzenia subskrypcji naszego Newslettera. Dzięki temu mamy pewność, że nikt nie dodał Twojego adresu przez przypadek. Jeśli wiadomość nie przyjdzie w ciągu najbliższej godziny (zazwyczaj jest to maksymalnie kilka minut) sprawdź folder SPAM.
Młody Szymon pomógł tacie zapisać się do Newslettera WebInsider.pl i... teraz idzie popływać
WebInsider poleca księgowość wFirma
WebInsider korzysta z VPSa w HitMe.pl
WebInsider poleca VPSy DigitalOcean
WebInsider poleca serwis Vindicat
Napisz komentarz
wipl_napisz-komentarz_01Jeśli informacje zawarte na tej stronie okazały się pomocne, możesz nam podziękować zostawiając poniżej swój komentarz.

W tej formie możesz również zadać dodatkowe pytania dotyczące wpisu, na które – w miarę możliwości – spróbujemy Ci odpowiedzieć.
Linki partnerskie
Niektóre z linków na tej stronie to tzw. „linki partnerskie”, co oznacza, że jeśli klikniesz na link i dokonasz wymaganej akcji (np. zakup/rejestracja) możemy otrzymać za to prowizję. Pamiętaj, że polecamy tylko te produkty i usługi, z których sami korzystamy, i uważamy, że są tego na prawdę warte… :-)
Znaki towarowe i nazwy marek
W niektórych wpisach (oraz innych miejscach na stronie) mogą być przedstawione/użyte znaki towarowe i/lub nazwy marek, które stanowią własność intelektualną tych podmiotów, a zostały użyte wyłącznie w celach informacyjnych.
Młody Szymon pomógł tacie zapisać się do Newslettera WebInsider.pl i... teraz idzie popływać