Kobieta Koduje

Bezpieczeństwo w wordpress cz. I

Bezpieczeństwo ogółem

Z racji, że temat cyberbezpieczeństwa jest dość rozległym zagadnieniem, to zanim przejdziemy do miejsca w którym znajduje się tu WordPress należy przedstawić nieco szerszy obraz rzeczywistości w jakiej się znajdujemy, w jakim środowisku pracujemy, i co możemy z nim zrobić by zwiększyć bezpieczeństwo naszej strony.

Wyróżniamy co najmniej cztery najpopularniejsze środowiska na jakich możemy znaleźć strony internetowe:

  • Serwer VPS – środowisko do którego mamy zazwyczaj dostęp na poziomie superużytkownika, będące najbardziej opłacalne uwzględniając kwestię cena / jakość. Wymaga ono jednak podstawowej wiedzy z zakresu administracji serwerami na poziomie konsoli by móc je w pełni wykorzystać. Plusem środowisk VPS jest uproszczone zarządzanie kopiami zapasowymi dzięki często oferowanym (dodatkowo płatnym) automatycznym kopiom zapasowym.
  • Serwer dedykowany – kolokwialnie “VPS na sterydach” za odpowiednio wyższą cenę. W odróżnieniu od serwerów VPS jesteśmy w pełni odpowiedzialni za organizację kopii zapasowych. Zyskujemy największą wydajność kosztem obciążenia nas zorganizowaniem częściowych zabezpieczeń infrastruktury
  • Serwer współdzielony – serwer którego zasoby są współdzielone z innymi użytkownikami. Zazwyczaj oferują możliwość instalacji aplikacji z poziomu panelu administracyjnego metodami “1-click” i otrzymaniu dostępu FTP. Tu podobnie jak w funkcjach VPS możemy liczyć na kopie zapasowe jako element wliczony w cenę. Wybierając tę opcję bezpieczeństwo infrastruktury (nie aplikacji) zrzucamy praktycznie na dostawcę usługi.
  • Chmura – najczęściej skonteneryzowana sieć serwerów zarówno dedykowanych jak i VPSów. W tym rozproszonym środowisku publiczne CMSy praktycznie nie występują, lub ich obecność tam jest drogą pod górę ponieważ aplikacje w środowiskach chmurowych powinny być odpowiednio zaprojektowane u podstaw czego WordPress z racji powstania zanim chmury zostały spopularyzowane nie spełnia.

W przypadku, gdy nie mamy doświadczenia w konfiguracji środowisk “od zera” jako superużytkownik, to zostaje nam efektywnie wybór środowisk współdzielonych. Praktycznie każda firma hostingowa ma w swojej ofercie takie środowiska i są one w skali roku najtańszym rozwiązaniem spośród wszystkich wyżej wymienionych.

Ważne

Dalsza część artykułu wymaga ode mnie jako autora zawarcia informacji, że treści tu zawarte mają charakter czysto edukacyjny i nie mogą stanowić dla czytelnika źródła wiedzy służącej łamaniu prawa, lub działania na cudzą niekorzyść.

Testując cudzą własność pod kątem cyberbezpieczeństwa musimy uzyskać od tej osoby zgodę na wykonanie tych czynności, w przeciwnym razie następuje łamanie prawa.

Mając tę kwestię za nami, można przejść do kolejnej części.

Wektor ataktu

Popularny buzzword w IT służący do określenia metodyki jaką atakujący stronę użytkownik zamierza zastosować. Na potrzeby wizualizacji popularnych wektorów ataku przygotowałem poniższą ilustrację :
Niektóre z tych słów mówią same za siebie, inne mogą wymagać pewnych wyjaśnień, więc spróbujemy zawęzić je do tych, które są dla nas najbardziej ryzykowne na środowiskach współdzielonych. Dla uproszczenia zamieszczam tę ilustrację ponownie zostawiając to na czym powinniśmy się skupić najbardziej, czyli:
Tak więc zacznijmy od czegoś, co w dzisiejszych czasach jest najbardziej popularnym powodem włamań – człowiek.

Człowiek

I to nie ten, który dokonuje samego włamania – pomylimy przyczynę ze skutkiem. W ramach powiedzenia “lepiej zapobiegać niż leczyć” warto jest przeszkolić osoby mające dostęp administracyjny w taki sposób by były one wyczulone na najpopularniejsze techniki manipulacji w sieci.

Za psychologa się nie uważam, natomiast za kogoś kto dostał dziesiątki maili tego rodzaju już chyba mogę. Jako przykład jednej z ciekawszych prób oszustwa mogłabym przytoczyć historię w której dostałam email informujący mnie o tym, że pewna domena X.pl w której jestem posiadaniu naraża mnie na nieprzyjemności karne związane z tym, że koncern nadawcy zastrzegł sobie prawa do tej nazwy przed tym jak zarejestrowałem daną domenę. Niewiele myśląc odpisałam coś w stylu “no i?” wiedząc, że to za mało by móc wygrać sprawę w sądzie. W odpowiedzi uzyskałem coś bardziej ciekawego bo propozycję wykupienia nazwy pod innymi domenami (eu, dev, biz, etc.) za grosze, co właściwie mogłabym zrobić i bez ich namowy (to dobra praktyka), gdyby to nie była moja strona o niskiej dla mnie wadze. Uświadomiłam sobie, że to nie jest już rozmowa z botem, tylko przydzielono do mnie kogoś kto miał ten angielski na poziomie komunikatywnym. Jak się później okazało po drobnym researchu linki jakie zostały mi podesłane kierowały na serwery w Chinach, a że Chiny są skrajnie na bakier z poszanowaniem praw od razu przestałam sobie zawracać głowę tematem. Uzupełniłam tylko w miarę możliwości swój research i okazało się, że firma rzekomo oferująca te domeny miała skrajnie niesymetryczne umowy obciążają klientów dużymi kwotami.

Jestem skłonna uwierzyć, że dużo osób dało by się przekonać do zakupu większej ilości domen dla zabezpieczenia ich interesu.

Przykładów tego typu podejść można znaleźć mnóstwo, natomiast to co się powtarza w nich regularnie to:

-wywołanie u ofiary wrażenia, że sytuacja jest poważna
-zbudowanie atmosfery w której wierzymy, że osoba z którą piszemy jest po naszej stronie i stara się nam pomóc, lub też znaleźć kompromis
-jeśli możliwe – wywołanie presji czasu, lub stworzenie odpowiedniego momentu, np.
przed godziną 17stą gdy ludzie chcą szybko skończyć prace bo są zmęczeni – zwłaszcza na koniec tygodnia lub na koniec roku, gdzie zazwyczaj panują pewne zawirowania prawne i łatwiej jest wpędzić przedsiębiorców w błąd na podstawie plotek

Gdybym miała wskazać kilka punktów które pomagają znacznie zredukować ryzyko bycia oszukanym:

  • Nigdy nie pozwalamy, by to ktoś decydował za nas, że coś jest ważne. Atakujący chce nam narzucić narrację, którą niekoniecznie przestudiujemy, i paradoksalnie coś co jest ważne dla niego może dla nas nie mieć znaczenia.
  • Zawsze w chwilach niepewności podważamy najprostsze założenia – czy osoba, która do nas dzwoni to na pewno osoba, za którą się podaje? Czy adres email z którego do nas piszą to na pewno oficjalny email firmy? Czy adres zawiera jedynie podobny znak do tego z nazwy firmy, etc…
  • Zawsze w przypadku, gdy ktoś nam grozi musimy do tego podejść od strony prawa a nie emocji. Weryfikujemy prawdomówność takiej osoby na podstawie własnej wiedzy, ewentualnie porady prawniczej. Ogólne domniemanie niewinności wymaga od osoby po drugiej stronie przedstawienia realnych informacji do których jako oszust nie powinien mieć dostępu.
  • Nigdy nie podajemy danych prywatnych osobom które się z nami kontaktują – jeżeli jest to pracownik banku, to te dane już ma, jeżeli rozmówca prosi o potwierdzenie informacji, do których potencjalnie ma lub powinien mieć dostęp – rozłączamy się. To on wykonuje telefon.

HiJacking

A właściwie to session hijacking, czyli przejęcie danych pozwalających na nawiązanie połączenia z serwerem w Twoim imieniu. Chodzi o login i hasło? Nie. Chodzi o dane, które otrzymujemy po poprawnym zalogowaniu się na stronie. Trzeba tu trochę wspomnieć o tym jak działa protokół HTTP. Dawno dawno temu gdy strony internetowe nie były niczym innym niż jednokierunkowym źródłem informacji, w których odbiorca nie miał możliwości komentowania, w którym nie było takich rzeczy jak wyrafinowane statystyki odwiedzin, a cała strona to mógł być jedynie kod HTML, nie było wtedy sesji – połączenie było tzw. stateless i taki też jest protokół HTTP. Czasy zmieniły się dawno temu i standardem jest, że niemal każda strona internetowa musi mieć jakąś informację związaną z danym użytkownikiem, nawet jeśli nie chodzi o samo logowanie. Poruszając się po stronie możemy zapisywać przeróżne ciasteczka pozwalające nam bez bycia zalogowanym utrzymywać wymianę informacji z serwerem, oraz zapisywać o nas informacje na serwerze. Przykładowo:

Użytkownik za pomocą przeglądarki wchodzi na stronę zajmującą się dostarczaniem żywności pod wskazany adres. Adres użytkownika można przechować na kilka sposobów, lecz najprościej jest zapisać go w sesji tak by większość informacji można było dla użytkownika spersonalizować przy ich wyświetlaniu, i nie pytać go o to co chwilę.

I co to ma do mojego bezpieczeństwa?

Specjalnie pogrubiłam tutaj słowo sesja ponieważ jest ono mylone z samymi ciasteczkami.
Uzupełnię teraz trochę diagram o kilka bloków więcej:

I okazuje się, że ciasteczka to nie jedyne miejsce, gdzie można przechowywać dane użytkownika Trochę się gubię Uprośćmy to do tego, że w większości przypadków w ciasteczkach znajduje się hash naszej sesji, a dopiero sesja przechowuje nasze bardziej prywatne dane. Dzięki temu prywatne dane znajdują się na serwerze w sesjach a nie w ciasteczkach i przeglądarce:

Czyli mając wartość ciasteczka innej osoby można się efektywnie pod nią podszyć?

Tak, jeśli wykradamy ciasteczko zawierające hash naszej sesji z serwerem to jest to wtedy session hijacking i z jego pomocą możemy uzyskać taki efekt jakbyśmy byli danym użytkownikiem.

Ale to nie moja wina, że użytkownikowi ktoś ukradł ciasteczka

Może. Na pewno można utrudnić nieco ten proces przez instalację certyfikatu SSL. Zazwyczaj taki certyfikat sprzedawany jest przez webhosting, chociaż osobiście polecam skorzystać z Let’s Encrypt, lub wtyczki Really Simple SSL.

To takie proste?

Niestety nie do końca. Sposobów na wykradnięcie ciasteczek użytkownika jest bardzo dużo, i często jest to z winy nietechnicznego użytkownika (otwieranie złośliwych linków, lewe wtyczki do przeglądarki, wirusy, etc.). To co my możemy zrobić to upewnić się, że sami nie instalujemy na naszej stronie podatnych wtyczek, czy dziurawych szablonów o czym będzie potem.

Dostawcy trzeci

Dużo się ostatnio mówi o tym, że jakaś strona ma problemy z działaniem bo, np. AWS ma problemy ze swoimi usługami, ale my tutaj skupimy się bardziej na ekosystemie wtyczek.

Czy wiesz, że duża ilość wtyczek nie realizuje swojej funkcjonalności bezpośrednio u Ciebie na serwerze? Ta lista funkcjonalności to nie tylko notyfikowanie użytkownika o nowym CVE dla jednej ze wtyczek na serwerze – to akurat miałoby prawo nie zadziałać, bo na kolejny dzień prawdopodobnie zostałoby naprawione i dla zdecydowanej większości stron nie miało by to znaczenia.

Co jeżeli taka wtyczka jest kluczowa dla działania naszej strony? Np. ReCaptcha?

Ten przykład został wzięty jako pierwszy z brzegu, i w momencie pisania tego artykułu można zaobserwować na stronie https://downdetector.com następujący wykres:

Z jednej strony nie wygląda to jak globalna awaria, lecz z drugiej jeśli spojrzymy w komentarze:

To zobaczymy jak niektórym może to napsuć w życiu. Co gdyby zacytowany wyżej Peter był klientem naszego sklepu? Niezależnie od tego czy sklep nie działa bo ktoś wykonał na nim atak DDoSowy czy nie, to efekt jest ten sam – system leży i nie wstaje.

Bronienie się przed tego rodzaju problemami zazwyczaj składa się z następujących rozwiązań:

  • Nie instalujemy kodu realizującego usługi przez serwery pośrednika, jeżeli nie ma takiej potrzeby. W przypadku captchy powinniśmy być w stanie znaleźć wystarczająco dobrą alternatywę.
  • Instalujemy więcej niż jedną wtyczkę realizującą te samą funkcjonalność, tak by w przypadku awarii w, np. InPost móc użyć kuriera UPS/DHL, lub w przypadku awarii Przelewy24 użyć PayU (kolejność wymienionych produktów jest losowa).

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.