5 najlepszych sposobów na rozwiązanie luki w WordPressie

Opublikowany: 2020-02-01

Obecnie WordPress obejmuje 33% sieci. Oznacza to, że korzysta z niego ogromna liczba użytkowników, co z pewnością przyciągnie więcej napastników i hakerów. Z tego powodu istnieje więcej zagrożeń i ataków, takich jak atak SQL Injection, atak przekierowania, atak CSRF, atak XSS itp., które powodują lukę w WordPressie. Z tego powodu nie oznacza to, że WordPress nie jest bezpieczny. Musimy skupić się na sanityzacji danych, walidacji danych, ucieczce danych, użyciu i weryfikacji jednorazowości, bezpiecznym przekierowaniu, możliwościach użytkownika itp., aby WordPress był bezpieczny. Jednak luki w WordPress sprawiają, że jest on niepewny. Omówmy więc problemy związane z bezpieczeństwem WordPressa.

W WordPressie pojawiają się również luki w zabezpieczeniach. Ale jak?

Z jednej strony istnieją poważne zagrożenia i ataki związane z podatnością WordPressa . Z drugiej strony musimy przezwyciężyć lub zapobiec tym atakom za pomocą naszego kodu podczas tworzenia WordPressa.

Nawet jeśli nie jesteś programistą WordPress, zachęcamy do przeczytania posta, ponieważ będziesz w stanie poznać główne ataki, które przyciągają hakerów do ataku na Twoją witrynę. Będziesz także w stanie zrozumieć, jak poznać słabo zakodowane wtyczki i motywy WordPress. Jeśli prowadzisz sklep internetowy, warto wybrać najlepsze wtyczki i motywy WooCommerce, które są bezpieczne.

Zawartość
1 luki w zabezpieczeniach WordPress
2 zagrożenia i ataki
2.1 Luka w WordPressie – atak polegający na wstrzyknięciu SQL
2.2 Sanityzacja danych
2.2.1 Przykład sanityzacji danych:
2.3 Luka w WordPressie – atak XSS
2.3.1 Przykład ataku XSS:
2.4 Walidacja danych
2.4.1 Przykład walidacji danych:
2.5 Ucieczka danych
2.5.1 Przykład ucieczki danych:
2.6 Luka w WordPressie – atak CSRF
2.7 Używanie Nonce
2.8 Weryfikacja nonce
2.9 Luka w zabezpieczeniach WordPress – atak przekierowania
2.10 Bezpieczne przekierowanie
2.11 Luka w zabezpieczeniach funkcji użytkownika
2.12 Zawsze wracaj lub wyjdź w WordPressie

Luki w zabezpieczeniach WordPress

Skąd pochodzą podatne kody?

Na początku powinniśmy dobrze zrozumieć, gdzie są problemy z bezpieczeństwem WordPressa . WordPress składa się z podstawowego kodu WordPress, motywów i wtyczek, które obejmują PHP, Html, JavaScript i inne kody.

Społeczność open-source sprawdza WordPress Core Code. Istnieje ogromna liczba osób, które zgłaszają błąd, naprawiają luki i przypisują mu zasługi. Luka w WordPressie może zostać wykorzystana przez atak SQL Injection, atak CSRF, atak XSS, atak Redirection i inne podobne techniki. Tak więc luka w zabezpieczeniach WordPressa z powodu rozwoju rdzenia nie jest duża.

Ani motywy zwykle nie wchodzą w interakcję z bazami danych wp, ani witryny często nie zmieniają motywów. Ponieważ Gutenberg jest domyślnym edytorem WordPress, musimy wybrać motywy WordPress kompatybilne z Gutenberg, aby uzyskać lepszą wydajność i bezpieczeństwo. Dzięki temu występuje mniej luk w zabezpieczeniach.

Z drugiej strony wtyczki WordPress mają złożone funkcje i zachowanie. Ponadto interakcja z użytkownikami i bazami danych jest wysoka. Witryna zawiera dużą liczbę wtyczek, które mają funkcje zewnętrzne. W rezultacie mogą wprowadzić do witryny dużą liczbę luk w zabezpieczeniach. Wtyczki wprowadzają główne luki w WordPress.

Luka w zabezpieczeniach WordPress — zagrożenia i ataki
Luka w zabezpieczeniach WordPress – WPscan.org

Według wpscan.org 11% luk pochodzi z motywów, podczas gdy 37% luk pochodzi z rozwoju WordPress Core. W podobny sposób pozostałe 52% pochodzi z wtyczek. Zakładam, że już wiesz, co to jest wtyczka WordPress

Zagrożenia i ataki

Jeśli jesteś twórcą motywów lub wtyczek WP, musisz mieć dobrą znajomość zagrożeń i ataków, aby zabezpieczyć swój kod i zmniejszyć lukę w zabezpieczeniach WordPress.

Zagrożenia i ataki-SQL Injection-XSS-CSRF-Redirection
Zagrożenia i ataki

Istnieje wiele ataków, takich jak atak SQL Injection, atak XSS, atak przekierowania, atak CSRF, którym można zapobiec poprzez sanityzację danych, walidację danych, ucieczkę danych, użycie i weryfikację jednorazowości, bezpieczne przekierowanie, możliwości użytkownika itp.

Jako programista Twoim wrogiem jest zazwyczaj złośliwy użytkownik. Tacy użytkownicy szkodzą naszemu kodowi. Kiedy włączymy Never Trust User Inputs do naszego codziennego kodowania, jesteśmy już w połowie drogi do napisania bezpieczniejszego kodu, aby zmniejszyć problemy z bezpieczeństwem w WordPressie. Ułatwi Ci to pracę jako konfigurator WordPress.

Luka w zabezpieczeniach WordPress – atak polegający na wstrzyknięciu SQL

Próbując odzyskać krytyczne i wrażliwe dane, atak SQL injection wstrzykuje złośliwy kod SQL do bazy danych WP. Ich celem są witryny WordPress, które korzystają z bazy danych SQL – MySQL, Oracle, SQL Server itp.

W tym celu mają dostęp do hasła, adresu e-mail lub wszelkich danych wrażliwych, ponieważ mogą łatwo dodawać, edytować lub odczytywać dane.

Przykładem może być komiks Słynny „Stoły Bobby”.

Słynne stoliki bobby Comic- Threat and Attack
Słynne stoliki bobby Comic

W tym komiksie dama zachowuje imię syna „Robert”); DROP TABLE Uczniowie; –') '; za pomocą polecenia SQL, które po wejściu do bazy danych usunie całą tabelę uczniów szkoły, jeśli nazwa nie została oczyszczona.

Aby uniknąć wstrzyknięcia SQL, musimy oczyścić dane wejściowe użytkownika.

Omówmy szczegółowo sanityzację danych.

Oczyszczanie danych

Odkażanie oznacza zabezpieczanie wkładu, czyszczenie wkładu użytkownika. Ten proces usuwa nieprawidłowy tekst, znaki UTF-8 lub kod z danych wejściowych, aby zmniejszyć podatność WordPressa.

Konwertuje specyficzne znaki HTML na byty, usuwa wszystkie znaczniki. Usuwa również podziały wierszy, tabulatory i dodatkowe spacje, oktety pasków, które są przyczyną poważnych problemów z bezpieczeństwem w WordPress.

Istnieje wiele wbudowanych funkcji WordPress do oczyszczania danych. Niewiele z nich znajduje się na poniższej liście:

  1. sanitize_email(): usuwa wszystkie znaki, które nie powinny znajdować się w wiadomości e-mail
  2. sanitize_text_field(): Oczyszcza ciąg (z danych wejściowych/bazy danych użytkownika)
  3. sanitize_file_name(): usuwa znaki (z nazwy pliku)
  4. sanitize_key(): Usuń klucze z wyjątkiem małych znaków alfanumerycznych, myślników i podkreśleń.

Przykład oczyszczania danych:

 $title=sanitize_text_field($_POST['title']); update_post_meta($post->ID,'title',$title);

Tutaj najpierw oczyszczamy tytuł. Po oczyszczeniu aktualizujemy wartość tytułu w bazie danych wp.

 $Name= ' Robert'); DROP TABLE Students; --') '; INSERT INTO Students VALUES ('$Name'); INSERT INTO Students VALUES ('Robert'); DROP TABLE Students; --')

Tutaj w powyższym poleceniu SQL nazwa zawiera ciąg znaków i znaki specjalne oraz encje, które wstawia się do tabeli uczniów, nazwa 'Robert'); Spowoduje to zamknięcie polecenia SQL insert, a kolejne polecenie zostanie uruchomione z połową nazwy DROP TABLE Students; –') '; a ta tabela upuszczania uczniowie usuwają wszystkie rekordy uczniów z bazy danych.

Więc tutaj, jeśli oczyszczanie zostało wykonane przed wprowadzeniem wartości do bazy danych, nie stracisz całej tabeli bazy danych uczniów.

Zobaczmy poniższy przykład, jak przeprowadzić odkażanie.


 $Name=sanitize_text_field("' Robert'); DROP TABLE Students; --') ';"); $sql = $wpdb->prepare("INSERT INTO Students VALUES ($Name)"); /* this will only insert 'Robert DROP TABLE Students' */ $wpdb->query($sql);

W powyższym przykładzie sanityzacja usunęła dodatkowe jednostki i znak z nazwy i pozwoliła tylko na wstawienie ciągu do bazy danych. W ten sposób możemy bezpiecznie wstawiać dane i być bezpieczni przed wstrzyknięciami SQL.

Kliknij ten link, aby dowiedzieć się więcej o zabezpieczaniu danych wejściowych .

Luka w WordPressie – atak XSS

Atak Cross-Site Scripting (XSS) polega na wstrzyknięciu wrażliwego kodu JavaScript języka skryptowego w celu kradzieży podobnych danych innego użytkownika, takich jak pliki cookie, tokeny sesji i inne informacje. Jeśli posiadamy informacje o plikach cookie, możemy połączyć się automatycznie. Problemy z bezpieczeństwem w WordPressie wiążą się ze skradzionymi plikami cookie, ponieważ możemy łatwo zalogować się przy użyciu innych tożsamości.
Działa w przeglądarce. Miliony osób, które przeglądają witrynę, zostaną dotknięte tym atakiem. Niewątpliwie ten atak jest jednym z najpoważniejszych ataków.

Przykład ataku XSS:

 <script <script type=”text/javascript”>
var hacker ='../hacker.php? cookie_data=' +escape(document.cookie);
</script>
</script>

W tym przykładzie ataku XSS pliki cookie uciekają i są wysyłane do zmiennej skryptu hacker.php „cookie_data”

Jeśli atakujący wstrzyknąłby ten skrypt do kodu witryny, zostanie on wykonany w przeglądarce użytkownika, a pliki cookie zostaną wysłane do atakującego, co jest niebezpiecznym problemem. Aby tego uniknąć, musimy zweryfikować. Weryfikuj i oczyszczaj wszystkie dane wejściowe użytkownika i dane wyjściowe ucieczki.

Omówmy szczegółowo poniżej.

Walidacji danych

Weryfikacja polega na sprawdzeniu danych wprowadzonych przez użytkownika. Ma to na celu sprawdzenie, czy użytkownik wprowadził prawidłową wartość, czy nie.
Istnieją trzy sposoby sprawdzania poprawności danych, które są wbudowanymi funkcjami PHP, podstawowymi funkcjami WordPress i funkcjami niestandardowymi. Nigdy nie unikaj tego, aby uniknąć luki w zabezpieczeniach WordPress. Niewiele z nich znajduje się na poniższej liście:

  1. isset()/empty(): sprawdź, czy zmienna istnieje, czy nie
  2. is_email(): sprawdź, czy podane dane są w formacie e-mail, czy nie
  3. is_serialized(): sprawdź, czy wartość jest ciągiem, czy nie

Przykład walidacji danych:

 $number='12323'; if(intval(number)){ //do your things } else{ esc_html_e('Enter valid number','text-domain'); }

Powyższy przykład sprawdza, czy dane wejściowe są liczbą, czy nie, uruchomi program tylko wtedy, gdy jest to liczba. W ten sposób sprawdzanie poprawności danych pomaga w zmniejszeniu problemów z bezpieczeństwem WordPress.

Kliknij ten link, aby dowiedzieć się więcej o walidacji danych

Ucieczka danych

Ucieczka zabezpiecza wyjście. Jest to proces usuwania niechcianych danych, takich jak zniekształcony kod HTML lub znaczniki skryptu. Ucieczka nie tylko konwertuje specjalne znaki HTML na encje HTML, ale także wyświetla zamiast wykonywania. Ma to na celu zapobieżenie atakowi XSS, a także upewnienie się, że dane wyświetlają się tak, jak oczekuje tego użytkownik.
WordPress udostępnia kilka funkcji pomocniczych. Są używane w większości przypadków. Niektórzy z nich są:

  1. esc_html(): Unika specyficznych znaków HTML
  2. esc_attr(): Zmienia wartość atrybutów tagów HTML
  3. esc_url(): Unika atrybutów odsyłacza hipertekstowego

Przykład ucieczki danych:

 $url = "javascript : alert ('Hello')";
<a href= "<?php echo esc_url ($url) ;?>"> Text </a> href= "<?php echo esc_url ($url) ;?>"> Text </a>

W powyższym przykładzie haker wprowadził kod języka skryptowego, aby zakwestionować problemy z bezpieczeństwem witryny WordPress. Aby tego uniknąć, użyliśmy esc_url do zmiany adresu URL, a dopiero potem powtarzamy wartość w naszym kodzie. W ten sposób zapobiegliśmy atakowi XSS.

Luka w WordPressie – atak CSRF

Omawiając dalej w WordPressie Luka w zabezpieczeniach, atak Cross-Site Request Forgery to zagrożenia i ataki jednym kliknięciem lub atak polegający na jeździe sesji.
Atak CSRF pozwala napastnikowi zmusić zalogowanego użytkownika do wykonania ważnej akcji bez jego zgody lub wiedzy.
Tutaj autoryzowany użytkownik przesyła nieautoryzowane polecenia.
Opiera się na założeniu, że autoryzowany użytkownik wysłany do określonej strony lub adresu URL może ewentualnie robić rzeczy, z których nie zdaje sobie sprawy. Co więcej, można to naprawić za pomocą nonce i zweryfikować nonce.

Korzystanie z Nonce

WP generuje token bezpieczeństwa zwany nonce. Jest to niepowtarzalny, niepowtarzalny numer tylko dla Ciebie, który możesz wykorzystać do konkretnej operacji. Wartość nonce jest ważna przez 24 godziny, po czym wygasa, a nowa zostanie wygenerowana przez wp. Możesz także ustawić czas weryfikacji dla nonce.
Chroni adresy URL i formularze przed niewłaściwym użyciem, aby zmniejszyć istniejące problemy z bezpieczeństwem w WordPress.

Ponadto, aby zabezpieczyć formularz wartością jednorazową, utwórz pole jednorazowe, które jest ukryte za pomocą funkcji wp_nonce_field():

 <form method="post"> <!-- some inputs here ... --> <?php wp_nonce_field( 'name_of_my_action', 'name_of_nonce_field' ); ?> </form>

Poniżej kilka funkcji na raz:

  1. wp_nonce_url() – Aby dodać jednorazową wartość do adresu URL.
  2. wp_create_nonce() – Aby użyć jednorazy w niestandardowy sposób do przetwarzania żądań AJAX.

Weryfikacja nonce

  1. check_ajax_referer() – Sprawdza wartość jednorazową (ale nie odsyłającą), a jeśli sprawdzenie się nie powiedzie, domyślnie przerywa wykonywanie skryptu.
  2. wp_verify_nonce() – Aby zweryfikować jednorazową liczbę.
 if(isset($_POST['name_of_nonce_field']) && wp_verify_nonce($_POST['name_of_nonce_field'],'name_of_my_action')){ //do something } else{ esc_html_e('Sorry,your nonce did not verify.','text-domain'); }

Kliknij ten link, aby dowiedzieć się więcej o nonce

Luka w WordPressie – atak przekierowania

Luka w zabezpieczeniach WordPress powoduje również, że odwiedzający witrynę automatycznie przekierowują do złośliwej witryny.
Zwykle dzieje się tak, gdy użytkownik przekierowuje na dowolną inną stronę zamiast na żądaną stronę lub witrynę.
Jeśli Twoja witryna ma duży ruch, ten atak może prowadzić do zmniejszenia ruchu w Twojej witrynie. Nawet nie zdasz sobie sprawy, że odwiedzający Twoją witrynę zostanie przekierowany na jakąkolwiek inną stronę. Można to jednak naprawić za pomocą Bezpiecznego przekierowania.

Bezpieczne przekierowanie

Po akcji lub formularzu, jeśli przekierowujesz użytkownika na dowolną stronę, użyj wp_safe_redirect. wp_safe_redirect sprawdza, czy jest dozwolony host. Jeśli host nie jest dozwolony, przekieruje do adresu URL witryny. Dzięki temu zapobiegnie to złośliwemu przekierowaniu do innego hosta. Ale nie jest to sprawdzane przez wp_redirect. Aby zmniejszyć problemy z bezpieczeństwem WordPress, użycie wp_safe_redirect jest bezpieczniejszym sposobem przekierowywania linków.

 $redirect=admin_url('edit.php'); wp_safe_redirect($redirect);

Luka w zabezpieczeniach funkcji użytkownika

Oprócz ataku przekierowania, ataku XSS, ataku CSRF i ataku SQL Injection, WordPress jest również podatny na ataki z zakresu User Capabilities. Jeśli pozwalasz dowolnemu użytkownikowi wejść do Twojej witryny w celu przesłania jakichkolwiek danych, sprawdź możliwości użytkownika. W przeciwnym razie będziesz ofiarą gróźb i ataków.
Im wyższa rola użytkownika, tym więcej możliwości ma użytkownik.
Czasami programiści po prostu zapominają o upewnieniu się, że użytkownik na stronie przesyłającej formularz ma niezbędne uprawnienia do wykonania danej czynności. Przyniesie wspólne źródło luki w zabezpieczeniach WordPressa.

 if ( current_user_can( 'edit_posts' ) ) { edit_post_link( esc_html__( 'Edit', 'wporg' ), '', ''); }

Weźmy za przykład lukę Contact Form 7 (Typ luki w WordPressie)

Numer aktywacji tej wtyczki to ponad 5 milionów użytkowników. Jeśli istnieje jeden wrażliwy kod, dotknie on ponad 5 milionów ludzi.

Formularz kontaktowy dotyczący luki w zabezpieczeniach 7
Uprzywilejowana luka w zabezpieczeniach formularza kontaktowego 7

W wersji 5.0.3 i starszych występowała luka w możliwościach. Zalogowany użytkownik w roli Contributor może łatwo edytować formularze kontaktowe. Domyślnie był dostępny tylko dla użytkowników z rolą Administratora i Edytora.
Tak więc istniała większa szansa na włamanie. Nowa wersja wtyczki rozwiązała te błędy.

Zawsze wracaj lub wyjdź w WordPress

Jeśli przegapiłeś return lub umrzeć po zakończeniu kodu podczas pisania dowolnej funkcji lub wywołania ajax. Może to wyglądać na proste, ale może prowadzić do ważnych problemów z bezpieczeństwem.

Upewnij się, że zawsze dodałeś zwrot i zgiń w miejscu, w którym chcesz. Możesz wziąć przykład błędu #gotofail firmy Apple.

 defined( 'ABSPATH' ) defined( 'ABSPATH' ) or die ( "No script kiddies please!" );
function function adls_view() { global $wpdb; { global $wpdb;
            include( 'inc/frontend/smls-detail/smls-grid-inline.php' );
           exit(); }
function function adls_generate_random_string ( $length ){
           $string = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
            $random_string = '';
            for ( $i = 1; $i <= $length; $i ++ ) { { $random_string .= $string[ rand( 0, 61 ) ];
            }
            return $random_string;
       }
 }

Zawijanie

To był ważny post dla profesjonalistów WordPress, którzy dbają o bezpieczeństwo. Z tego postu dowiedziałeś się o różnych zagrożeniach i atakach, które powodują podatność WordPressa. Zawiera krótkie wprowadzenie o ataku SQL Injection, XSS, CSRF, Redirection i wielu innych.

Walidacja-Sanityzacja-Ucieczka-Nonce
Punkty do zapamiętania

Omówiono również różne techniki, takie jak sanityzacja danych, walidacja danych, wymykanie się danych, używanie i weryfikowanie jednorazowości, bezpieczne przekierowanie i możliwości użytkownika. Z tego powodu w WordPress występują problemy z bezpieczeństwem.

Podsumowując ,

  1. Nigdy nie ufaj danych wprowadzanych przez użytkownika, aby uniknąć luki w zabezpieczeniach WordPress.
  2. Weryfikuj, oczyszczaj wszystkie dane wejściowe i unikaj wszystkich danych wyjściowych
  3. Zaufajmy WordPressowi!

Jeśli napotkałeś jakiekolwiek problemy związane z wyżej wymienionymi zagrożeniami i atakami, poinformuj nas o tym. Nasi eksperci doradzą Ci odpowiednie rozwiązanie w oparciu o Twój problem.