Oprócz ataków brute force, wstrzyknięcia SQL w WordPressiewielokrotnie pojawiają się na liście największych zagrożeń dla stron WordPressa. Są to stosunkowo łatwe manipulacje bazą danych twoich stron. W ten sposób hakerzy zdobywają poufne dane lub sami zakładają konta administratorów i mogą dowolnie manipulować Twoją witryną. Pokazujemy, jak działa ten atak i dlaczego jest tak niebezpieczny.

Marzec 2008: Hakerzy (wśród których znalazł się prawdziwy mistrz) uzyskują 134 miliony danych kart kredytowych amerykańskiej firmy Heartland Payment Systems. Połowa 2016 roku: Podejrzani rosyjscy hakerzy uzyskują dostęp do bazy danych zarejestrowanych wyborców Stanowej Rady Wyborczej Stanu Illinois (Illinois State Board of Elections). Podobne rzeczy dzieją się w Arizonie. Luty 2017: Dane z 65.000 kont użytkowników zostają wykradzione z amerykańskiego sprzedawcy broni Airsoft GI. Marzec 2017: Podejrzani chińscy hakerzy uzyskują dane osobowe 4 tys. klientów koreańskiej aplikacji i wysyłają do ofiar wiadomości tekstowe, niektóre z nich obsceniczne.

Wszystkie te ataki mają jedną wspólną cechę: stoi za nimi stosunkowo łatwy do wykonania hack zwany SQL injection. W tym ataku hakerzy uzyskują dostęp do bazy danych, a tym samym do wszystkich danych użytkownika na danej stronie. W rzeczywistości, iniekcje SQL są uważane za jedno z największych zagrożeń dla operatorów stron internetowych. Także i przede wszystkim dla webmasterów, którzy pracują głównie z WordPress .

A ponieważ, najpóźniej od WooCommerce , szczególnie większe i bardziej złożone sklepy mogą być obsługiwane bez problemów z WordPress , ważne jest, aby zrozumieć ryzyko WordPress SQL Injection i jak to działa.

Jak "niebezpieczne" są wstrzyknięcia SQL w WordPressie?

Na pytanie o "niebezpieczność" włamania do WordPressa nie można odpowiedzieć za pomocą jednego wskaźnika. Należy raczej wziąć pod uwagę co najmniej dwa aspekty: Po pierwsze, prawdopodobieństwo, że własny projekt WordPressa padnie ofiarą takiego ataku, a po drugie, szkody, jakie może spowodować włamanie.

W przypadku ataków brute force, na przykład, liczba ataków miesięcznie jest tak duża (w niektórych przypadkach ponad 1 miliard zmierzonych ataków + liczba niezgłoszonych przypadków), że można właściwie powiedzieć, iż prędzej czy później każdy projekt WordPressa zostanie zamierzony przez taki atak. Szkody, jakie może wyrządzić udane włamanie, są wielorakie. Ataki typu brute force są zazwyczaj wykorzystywane do porywania stron internetowych i włączania ich do botnetu. Cross-site scripting, z drugiej strony, występuje znacznie rzadziej, ale jest głównie używany do infekowania stron internetowych złośliwym kodem.

Organizacja non-profit Open Web Application Security Project (OWASP) regularnie publikuje listę 10 największych zagrożeń dla bezpieczeństwa aplikacji internetowych. A iniekcje SQL niezmiennie okupują tu pierwsze miejsce, nawet na (choć wstępnej) liście za 2017 rok.

W rzeczywistości, wstrzyknięcia SQL pozostaną na zawsze. Hack istnieje już od ponad 15 lat. Według raportu Akamai State of the Internet Security Report for 2017, częstotliwość ataków SQL wzrosła o 28% od pierwszego kwartału 2016 roku. W pierwszym kwartale 2017 roku najczęstszym atakiem były iniekcje SQL, które stanowiły 44% ataków. 

Wordfence, producent oprogramowania zabezpieczającego dla WordPressa, doszedł do wniosku, że wstrzyknięcia SQL stanowią duże zagrożenie zwłaszcza dla użytkowników WordPressa. Analiza prawie 1600 luk w zabezpieczeniach wtyczek zgłoszonych w ciągu 14 miesięcy wyraźnie pokazuje, że wstrzyknięcia SQL są drugim najczęstszym zagrożeniem bezpieczeństwa dla witryn WordPressa.

Przy tych wszystkich liczbach należy pamiętać, że liczba niezgłoszonych przypadków jest znacznie większa - ataki SQL często nie są nawet zauważane i nie pojawiają się w żadnych statystykach.

Liczby pokazują, że WordPress SQL Injections po atakachBrute Force i podatności XSS to jedne z najczęstszych rodzajów ataków. Ponadto, iniekcje SQL są wymierzone w szczególnie wrażliwy obszar witryny: bazę danych. Szczególnie dla właścicieli sklepów internetowych takie włamania są zagrożeniem egzystencjalnym. Dlatego ważne jest, aby zrozumieć, jak one działają i co można przeciwko nim zrobić.

WordPress SQL Injections celują w serce Twojej strony: bazę danych.

Aby zrozumieć jak działa SQL injection, musisz zrozumieć jak WordPress jest zbudowany. Jeśli już to wiesz, możesz spokojnie pominąć tę część.

Baza danych jest podstawą każdej instalacji WordPress : Tutaj przechowywane są wszystkie treści. Sam system CMS umożliwia wyświetlanie i edycję tych treści. WordPress jest bazą danych MySQL. SQL jest skrótem od Structured Query Language, w pełni funkcjonalnego języka programowania, który może być używany do tworzenia struktur w bazie danych oraz wstawiania, modyfikowania i usuwania danych.

Za każdym razem, gdy piszesz artykuł, tworzysz nową kategorię, zmieniasz hasło, a nawet gdy Twoi użytkownicy piszą komentarz, te nowe dane są zapisywane w bazie danych. Jest to więc miejsce, w którym znajduje się każda pojedyncza treść na Twojej stronie.

Za każdym razem, gdy użytkownik wywołuje Twoją stronę i żąda określonej treści,WordPress pobiera odpowiednie dane z bazy danych, łączy je z PHP i tworzy dokument HTML, który jest ostatecznie przesyłany do przeglądarki użytkownika. Użytkownik nie jest świadomy wszystkich procesów zachodzących do tego momentu.

SQL Injections wstrzykuje zewnętrzny kod do bazy danych

Nawet jeśli nigdy nie pracujesz bezpośrednio z bazą danych, a jedynie z backendem WordPress : Baza danych jest sercem Twojej strony internetowej.

Ale jak już powiedziałem: Użytkownicy są również w stanie wprowadzać dane do bazy danych. Napisanie komentarza, założenie konta użytkownika, wypełnienie i wysłanie formularza kontaktowego - wszystkie te czynności generują dane, które są przechowywane w bazie danych.

Ale co jeśli ktoś wykorzysta ten pośredni dostęp do Twojej bazy danych, aby przemycić do niej złośliwy kod? Jest to tzw. wstrzykiwanie kodu SQL.

Idea, która za tym stoi, nie jest nawet szczególnie skomplikowana: Jeśli nie ma żadnych zabezpieczeń, haker musi jedynie wprowadzić kod SQL do pola formularza (np. podczas pisania komentarza). Ten kod zawiera znaki pełniące specjalną funkcję dla interpretera SQL, który jest odpowiedzialny za wykonywanie poleceń SQL w bazie danych. Takimi znakami specjalnymi, zwanymi metaznakami, są na przykład ; " ' i Ą.

CMS uważa, że są to nieszkodliwe dane i przekazuje dane wejściowe do bazy danych jak zwykle z poleceniem ich zapisania. Interpreter SQL rozpoznaje kod jako żądanie akcji na podstawie metaznaków i wykonuje polecenie bazy danych.

Nawiasem mówiąc, to samo odnosi się do wstrzyknięć SQL, co do ataków Brute Force: prawie nigdy nie jest tak, że haker siedzi sam przy komputerze i ręcznie wpisuje kody do formularzy. Ataki te są również przeprowadzane za pośrednictwem zautomatyzowanych botnetów, które skanują tysiące stron internetowych jednocześnie w poszukiwaniu luk i uderzają tam, gdzie je wykryją.

Co może się teraz wydarzyć?

• Haker omija wszelkie mechanizmy uwierzytelniania lub ukrywa się za tożsamością istniejącego użytkownika, aby uzyskać dostęp. Jeśli haker stworzy na przykład nowe konto administratora, jest to określane jako exploit na eskalację przywilejów.
• W ten sposób może podsłuchiwać, zmieniać lub usuwać dane. Jest to szczególnie ważne, jeśli prowadzisz sklep internetowy i dysponujesz danymi płatniczymi swoich klientów.
• Może on przejąć kontrolę nad całą Twoją stroną i przestrzenią internetową, na przykład, logując się jako administrator i uzyskując dostęp do Twojego backendu. W ten sposób haker ma pełną kontrolę nad Twoją stroną i może ją wykorzystać jako przemytnika spamu, wstrzyknąć złośliwy kod lub wprowadzić do botnetu.

Wniosek: Szczególnie ze względu na automatyzację WordPress SQL Injections są bardzo niebezpieczne.

WordPress Wstrzyknięcia SQL to jedne z najniebezpieczniejszych włamań. Są one łatwe do wykonania, w większości zautomatyzowane i mogą powodować ogromne szkody: Szczególnie dla operatorów sklepów internetowych zagrożenie związane z iniekcjami SQL ma charakter egzystencjalny.

Dlatego ważne jest, aby odpowiednio zabezpieczyć swoją stronę: Dane wejściowe użytkownika muszą być sprawdzone i oczyszczone. Należy również maskować dane, aby zapobiec wykonaniu złośliwego kodu. Proces ten nazywany jest sanityzacją i walidacją danych i jest szczegółowo opisany na przykład w WordPress Codex. W jednym z następnych artykułów zajmiemy się jednak tym tematem bardziej szczegółowo i pokażemy, jak można zapobiec uaktywnieniu się złośliwego kodu w bazie danych.

Zasadniczo, kompleksowe zabezpieczeniaPlugins pomagają również tutaj: ponieważ są one szczególnie zdolne do blokowania automatycznych ataków na Twoje strony, które są podstawą wielu włamań.