Najlepsze praktyki bezpieczeństwa dla twórców wtyczek i motywów WordPress

Opublikowany: 2020-12-09

Jako programista WordPress musisz podjąć wiele decyzji dotyczących tego, nad czym pracować. Twoim głównym zainteresowaniem i priorytetem jest zbudowanie niesamowitego motywu lub wtyczki, a środki bezpieczeństwa często schodzą na dalszy plan, gdy zasiadasz za kierownicą, aby pracować nad kodem. Kiedy ostatnio usiadłeś i sprawdziłeś swój własny kod pod kątem problemów z bezpieczeństwem? Nie, nie myślałem

Te wskazówki są oparte na moich doświadczeniach zarówno z opracowywaniem wtyczek w CleverPlugins, jak i pomaganiem niezliczonym klientom w przywracaniu ich witryn internetowych po zhakowaniu. Opracowywanie wtyczki zabezpieczającej, takiej jak WP Security Ninja, nie spowodowało, że straciłem paranoję na punkcie kodu innych ludzi.

Najczęstszym powodem ataków na strony internetowe jest wciąż kiepskie zarządzanie hasłami, ale nie powinno to być wymówką do korzystania z niektórych prostych sposobów ochrony kodu.

Kiedy tworzysz wtyczkę lub motyw, chcesz, aby stała się popularna i została zainstalowana na jak największej liczbie stron internetowych. Im większy Twój sukces, tym większa szansa, że ludzie będą próbować nadużywać Twojej pracy, by włamać się na strony internetowe Twoich użytkowników.

Ze względu na popularność WordPress stał się jednym z najczęstszych celów hakerów. Wykrycie luki we wtyczce lub motywie może oznaczać tysiące, jeśli nie setki tysięcy stron internetowych, które są narażone na nadużycia.

Niestety często zdarza się, że w znanym produkcie pojawia się podatność, dlatego warto zastosować podstawowe zabezpieczenia, aby chronić swój kod przed użytkownikami.

A co z zespołem ds. recenzji WordPress.org?

Można by pomyśleć, że zespół, który przegląda wtyczki i motywy przed opublikowaniem w oficjalnym repozytorium, sprawdza wszelkiego rodzaju problemy z bezpieczeństwem, ale zespół jest niewielki i składa się tylko z kilku osób. Kolejka wtyczek i motywów do sprawdzenia stale rośnie, więc czas, który muszą sprawdzić, jest ograniczony.

Jeśli jednak coś znajdą, mogą automatycznie zamknąć wtyczkę, dopóki jej nie naprawisz lub wyślesz wiadomość e-mail z ostrzeżeniem, że musisz naprawić lukę przed upływem określonego czasu.

Chodzi o to, że gdy twoja wtyczka lub motyw znajduje się na liście w repozytorium, możesz wysyłać aktualizacje za pośrednictwem repozytorium bez dodatkowego sprawdzania, dzięki czemu luka w zabezpieczeniach może łatwo wślizgnąć się w dowolnym momencie i pozostać niewykryta przez prawie dowolny okres czasu.

Zasadniczo zaostrzenie środków bezpieczeństwa wtyczek zależy od Ciebie, więc przyjrzyjmy się, jak możesz chronić swój produkt WordPress i zapobiec wielu bólom głowy i potencjalnie negatywnemu wpływowi na Twoją markę.

Oto, co możesz zrobić, aby bezpiecznie opracować swoją wtyczkę lub motyw WordPress.

1. Pomyśl o bezpieczeństwie ze wszystkich perspektyw!

Nigdy nie wiesz, kto może używać Twojej wtyczki lub motywu i jaki poziom wiedzy na temat bezpieczeństwa mają, jeśli w ogóle.

Nigdy nie wiesz, kto może używać Twojej wtyczki lub motywu i jaki poziom wiedzy na temat bezpieczeństwa mają, jeśli w ogóle.Tweetuj

Administratorzy, redaktorzy lub zwykli użytkownicy dowolnej witryny klienta mogą nie używać bezpiecznych haseł, a ich konta mogą zostać zhakowane. Jeśli Twój produkt nie jest zabezpieczony, konta te mogą zostać wykorzystane w celu uzyskania dalszego dostępu w celu zainstalowania złośliwego kodu w witrynie klienta.

Nie należy oczekiwać, że administratorzy serwerów, którzy skonfigurowali serwer, na którym działa witryna, będą wiedzieć wystarczająco dużo o tym, jak chronić witrynę przed innymi witrynami na tym samym serwerze. Jeśli witryna jest hostowana przez dużego dostawcę, możesz oczekiwać, że witryna zostanie odpowiednio „oddzielona”, ale nie wiesz, gdzie zostanie zainstalowany Twój produkt.

Czy to brzmi paranoicznie? Być może. Ale jeśli i kiedy twoja wtyczka lub motyw stanie się bardzo popularny, z przyjemnością przyjmiesz paranoidalne podejście do bezpieczeństwa.

Jeśli i kiedy twoja wtyczka lub motyw stanie się bardzo popularny, z przyjemnością przyjmiesz paranoidalne podejście do bezpieczeństwa.Tweet

2. Zapobiegaj atakom XSS — Cross-Site Scripting

Ten staje się coraz ważniejszy, ponieważ WordPress staje się bardziej frontendowym projektem z Gutenbergiem i ReactJS.

Jednym z najczęstszych błędów programistów WordPressa jest zapominanie o walidacji i oczyszczaniu kodu – pozostawiając go podatnym na ataki XSS. Istnieje kilka odmian XSS, ale generalnie atak XSS ma miejsce, gdy haker może wstrzyknąć kod do serwera, a następnie uruchomić go w przeglądarce odwiedzającego.

Wyobraź sobie, że masz pole wejściowe. Dla uproszczenia załóżmy, że jest to pole komentarza, w którym użytkownicy lub odwiedzający mogą przesyłać komentarz do posta.

Haker spróbuje przesłać komentarz za pomocą "<script>alert('XSS');</script>" .

To tylko podstawowy przykład, który wyświetla alert na ekranie użytkownika i nic więcej. Rzeczywisty haker użyje pola komentarza do wstrzyknięcia kodu, który ładuje kod z jego witryny, który może wykraść informacje z przeglądarki odwiedzającego i wiele więcej.

Możemy temu zapobiec, sprawdzając, czyszcząc i uciekając.

Walidacja polega na sprawdzeniu przesłanych danych przed wykonaniem jakichkolwiek czynności, na przykład zapisaniem ich w bazie danych. Za każdym razem, gdy przesyłane są dane, możesz je sprawdzić i upewnić się, że są akceptowalne. Jeśli jest to pole ilościowe, oczekujesz liczby. Jeśli nie jest to liczba, możesz zwrócić użytkownikowi komunikat o błędzie.

Odkażanie danych polega na przetwarzaniu przesłanych informacji i upewnianiu się, że nie zawierają one niczego, czego nie chcemy przechowywać, na przykład usuwanie niechcianych znaków. WordPress ma kilka wbudowanych funkcji, które mogą w tym pomóc. Więcej o odkażaniu za chwilę.

Ucieczka zapobiega faktycznemu wykonywaniu złośliwego kodu w Twojej przeglądarce. Załóżmy, że masz już wstrzyknięty złośliwy kod do swojej witryny lub inna wtyczka lub motyw pozwala hakerom wstawić kod do danych, z których korzystasz – wyprowadzenie danych na ekran przed ich wyświetleniem zapobiegnie występowaniu problemu.

Spójrzmy na ten sam prosty przykład, którego użyliśmy przed "<script>alert('XSS');</script>"

Jeśli nic nie zrobimy z tym kodem, przeglądarka pomyśli, że jest to kod HTML. Ważnym szczegółem są tutaj znaki < > używane do definiowania znaczników HTML. Unikając tych, zmieniamy < w < i > na > Przeglądarka rozumie teraz, że nie jest to rzeczywisty kod HTML i zamiast tego powinien pokazywać znak „mniej niż” i „większy niż”.

Weryfikując, oczyszczając i usuwając wszystkie dane przychodzące i wychodzące z aplikacji, chronisz swoich użytkowników przed jedną z najczęstszych metod ataków.

3. Uważaj na iniekcje SQL

Jak sama nazwa wskazuje, atakujący może użyć wstrzyknięć SQL, aby Twoja witryna przetworzyła zmodyfikowane zapytanie SQL i wykorzystać je, aby uzyskać dostęp do Twojej bazy danych.

W zależności od danych, które przechowujesz w swojej witrynie, wyciek danych z witryny w wyniku ataku polegającego na wstrzyknięciu SQL może stać się kłopotliwym, a nawet całkowicie zrujnować Twoją reputację i firmę.

Wstrzyknięcie SQL to stary sposób na atakowanie strony internetowej, ale nadal jest bardzo skuteczny i wiele osób szuka sposobów na wykorzystanie tej formy ataku. W październiku 2020 r. popularna wtyczka Loginizer WordPress ogłosiła, że ma lukę w postaci wstrzyknięcia SQL, która zagroziła ponad milionowi stron internetowych.

W 2019 r. nieznani hakerzy ukradli miliony danych podatkowych Bułgarów za pomocą ataku SQL injection, a w 2016 r. grupa rosyjskich hakerów wydobyła informacje o wyborcach około 500 000 osób w Ohio. Tego rodzaju ataki są nadal bardzo skuteczne i można znaleźć na ich temat wiele informacji.

Źródło: https://xkcd.com/327/

Najczęstszym miejscem wstrzyknięcia SQL jest pole formularza, które akceptuje dane wejściowe użytkownika — na przykład imię i nazwisko. Atak odbywa się poprzez wprowadzenie części kodu SQL w pola wejściowe, tworząc niestandardowe zapytanie dające inny wynik niż można by się spodziewać.

Załóżmy, że masz formularz, który umożliwia wyszukiwanie określonej nazwy.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';

Ten prosty przykład pobrałby wszystkie wiersze z metatabeli postu ze wszystkimi wierszami o nazwie Henry i określonym kluczu celebrity_name – w ten sposób nie zwracamy całej bazy danych, a tylko te, których potrzebujemy.

Atakujący próbowałby przeanalizować inną wartość – na przykład 'Henry' OR 1=1--

Zapytanie zwróci teraz wszystkie wiersze z naszą konkretną wartością lub cokolwiek innego – ponieważ OR 1=1 w SQL jest zawsze prawdziwe.

Jednak jest coraz gorzej. Nasze zapytanie SQL prosiło tylko o wyniki, w których meta_key pasuje do konkretnej wartości, której szukamy, więc nie zwrócilibyśmy wszystkiego. Powinno to ograniczyć wpływ ataku SQL injection, prawda?

Cóż, nie tak. W SQL podwójna kreska jest wskaźnikiem komentarza, więc wszystko, co nastąpi po tym, jest skomentowane.

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';

Oznacza to, że zapytanie wygląda tak:

SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1

Zapytanie teraz zasadniczo zwraca wszystko w tej tabeli bazy danych.

To był tylko prosty przykład. Istnieje wiele bardziej skomplikowanych sposobów dostępu do większości, jeśli nie wszystkich informacji w bazie danych. Atakujący mógłby spróbować ślepych ataków wstrzykiwania SQL, co oznacza uruchamianie kodu w Twojej bazie danych – dodanie nowego administratora, usunięcie wszystkich danych i tak dalej.

Większość ataków miałaby formę losowych ciągów zapytań zawierających części SQL przesłane do formularzy Twojej witryny. Zautomatyzowane skrypty wykryją wszelkie zmiany w wynikach Twojej witryny, a następnie wykryją potencjalny atak.

Prostym, skutecznym sposobem jest wysłanie apostrofu ' jako danych wejściowych i sprawdzenie, czy coś się zmieni, wystąpi błąd lub zostanie zwróconych więcej wyników.

WordPress na ratunek

Zamiast wchodzić w bezpośrednią interakcję z bazą danych, każdy programista powinien użyć wbudowanej w WordPress klasy abstrakcji bazy danych, $wpdb .

Klasa $wpdb w WordPressie ma wszystkie funkcje CRUD potrzebne do bezpiecznej interakcji z bazą danych, a jeśli potrzebujesz wtyczki lub motywu, możesz nawet użyć tej klasy do interakcji z własnymi tabelami bazy danych.

Możesz rozwiązać problem, przewidując, jakie dane należy rozsądnie wprowadzić w każdym formularzu wejściowym. W naszym poprzednim przykładzie szukaliśmy nazwy. Moglibyśmy oczyścić dane wejściowe, aby upewnić się, że akceptujemy tylko listy. Jeśli masz pole wyboru lub grupę radiową, która zawiera tylko kilka opcji, możesz sprawdzić dane, aby upewnić się, że jest to tylko jedna z dozwolonych opcji.

Najważniejszą rzeczą, jaką możesz zrobić, aby rozwiązać problem, jest przygotowanie danych za pomocą funkcji $wpdb->prepare() .

Ta funkcja pobiera przygotowany ciąg zapytania i tablicę argumentów, które chcesz dodać do zapytania SQL.

$meta_key = 'celebrity_name';
$meta_val = 'Henry'
$allhenrys = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM $wpdb-&gt;postmeta WHERE meta_key = %s AND meta_value = %s",
    $meta_key,
    $meta_val
  )
);

Cała praca odbywa się wewnątrz funkcji prepare() . Pierwszy parametr, przygotowane zapytanie – zawiera symbol zastępczy %s zamiast rzeczywistych wartości. Jest to zastępowane przez inne przeanalizowane zmienne, $meta_key i $meta_val .

Uwaga – ważne jest, aby w zapytaniu nie umieszczać apostrofu wokół symboli zastępczych, ponieważ funkcja doda je za Ciebie.

Jest to uproszczony przykład, ale ten sam proces może być użyty dla dowolnego zapytania do bazy danych i możesz użyć %s dla ciągów, %d dla liczb całkowitych i %f dla liczb zmiennoprzecinkowych.

Dostępne są również funkcje dla konkretnych sytuacji, takich jak dodanie nowego wiersza do bazy danych. W tym celu możesz użyć $wpdb->insert() .

$wpdb->insert(
  "{$wpdb->prefix}my_custom_table",
  array(
    'name'   => 'Henry',
    'userid' => 123,
    'score'  => 10,
  ),
  array(
    '%s',
    '%d',
    '%d',
  )
);

Korzystanie z funkcji przygotowania może pomóc w zapobieganiu większości prób wstrzykiwania SQL przeciwko Twojemu produktowi.

Pamiętaj, aby sprawdzić dokumentację $wpdb. Niektóre funkcje uciekną z wprowadzania danych; inni oczekują, że sam wyjdziesz z danych wejściowych przed analizowaniem danych do funkcji.

4. Używaj znaków jednorazowych, aby chronić swoje prośby

Korzystanie z systemu nonce w WordPressie może pomóc w zapobieganiu wielu atakom. Jednorazowy pod względem bezpieczeństwa jest liczbą używaną tylko raz. Pomysł polega na dodaniu tego unikalnego numeru do wszystkich żądań, które wysyłasz z kodu do instalacji WordPressa, aby sprawdzić, czy to żądanie jest uzasadnione.

To trochę jak posiadanie tajnego hasła, które musisz podać bramkarzowi, aby dostać się do klubu

Jednak jednorazy w WordPressie są nieco inne – nie są ani liczbą, ani jednorazową liczbą używaną tylko raz.

Technicznie rzecz biorąc, numery jednorazowe w WordPressie mogą zawierać zarówno małe litery, jak i cyfry, a zamiast tego, że są używane tylko raz , są odtwarzane po pewnym czasie.

Sposób, w jaki używasz nonce, polega na tym, że kod PHP, który rejestruje twoje pliki JavaScript, generuje trochę unikatową kombinację cyfr i liter i analizuje je, aby twój kod JS mógł go odczytać.

Za każdym razem, gdy kod JavaScript wysyła żądanie do Twojej witryny, wysyła wraz z tym fragmentem kodu, a jeśli kod nie pasuje, Twój kod powinien całkowicie zignorować żądanie.

Na przykładzie jest to zawsze trochę łatwiejsze, więc zobaczmy prosty sposób na załadowanie pliku .js do wtyczki, wykonując następujące kroki:

Używanie nonces we wtyczce WordPress

add_action('wp_enqueue_scripts', 'load_my_plugin_script');

function load_my_plugin_script() {
  // Register the script with all details and ensures it is loaded after jQuery
  wp_register_script('secure-plugin', plugin_dir_url( __FILE__ ). 'js/secure-plugin.js', array( 'jquery' ) );

  // Here happens the magic, we add some details to an object that we can later reference and read from in our JS code.
  wp_localize_script(
    'secure-plugin',
    'plugin_ajax_object',
    array(
      'nonce' => wp_create_nonce('secure-plugin-nonce')
    )
  );

  // Once that is done, we can now enqueue the script
  wp_enqueue_script('secure-plugin');
}

W tej funkcji mówimy WordPressowi, aby załadował plik JavaScript. Najpierw rejestrujemy plik, który chcemy załadować za pomocą wp_register_script() .

Następnie używamy wp_localize_script() do parsowania tablicy danych, w szczególności „nonce”, która zawiera unikalną wartość jednorazową, której chcemy użyć w naszym kodzie JS. Pamiętaj, że w tej tablicy możesz również wysyłać wszelkiego rodzaju inne informacje, ale w tym przykładzie po prostu staramy się to uprościć.

Gdy wysyłasz żądanie z pliku JavaScript, musisz dołączyć ten unikalny numer jednorazowy. Robienie tego jest łatwe:

Używanie nonce z wtyczki WordPress w pliku JavaScript

jQuery(document).ready(function($) {
  $.ajax({
    url: ajaxurl, // WP variable, contains URL pointing to admin-ajax.php
    type: 'POST',
    data: {
      'action':      'get_custom_data',
      '_ajax_nonce': plugin_ajax_object.nonce,
      'user_data':   'Some input from a user'
    },
    success: function( response ) {
      // Here we do what happens if all is good - update the interface with a success message!?
    },
    error: function( response ) {
      // Whooops, something went wrong!
      // console.log(response);
    }
  });
});

Ponieważ użyliśmy wp_localize_script() , możemy użyć zmiennej plugin_ajax_object w JavaScript. Wysyłamy wartość jednorazową jako zmienną _ajax_nonce .

Sprawdź i zweryfikuj jednorazowy kod we wtyczce WordPress z kodu JavaScript

add_action('wp_ajax_get_custom_data', 'get_custom_data');

function get_custom_data() {
  // Ready for the magic to protect your code?
  check_ajax_referer('secure-plugin-nonce');

  /**
   * That's it - the check_ajax_referer function verifies the nonce is correct or it dies and stops code execution if it fails.
   *
   * If you want to customize the error handling and perhaps return an error to your JS code, you could change the code to something like:
   * if ( ! check_ajax_referer( 'secure-plugin-nonce', false, false ) ) {    
   *   wp_send_json_error( 'Invalid nonce' );
   * }
   */

  $sanitized_user_data = sanitize_text_field( $_POST['user_data'] );

  // ... continue with the rest of your plugin's function code ...
}

Magia dzieje się z funkcją check_ajax_referer() , która sprawdza numer jednorazowy i po prostu kończy się niepowodzeniem i zatrzymuje dalsze wykonywanie kodu, jeśli numer jednorazowy nie pasuje do oczekiwanego.

Możesz dalej dostosować kod, aby zwrócić użytkownikowi określone informacje o tym, co się stało.

Używanie nonces w kodzie jest szybkim, łatwym i skutecznym sposobem zapobiegania wielu rodzajom prób włamania. Nie oznacza to, że możesz pominąć wszystkie inne środki bezpieczeństwa, ale pomaga to zmniejszyć najgorsze problemy.

Pamiętasz, co powiedziałem o nieufaniu nikomu? To prowadzi nas do innego sposobu ochrony Twojego kodu – odkażania.

Zapisz się i zdobądź bezpłatną kopię naszej książki

11 sprawdzonych technik zwiększania sporów dotyczących kart kredytowych o 740%

Dziękuję za zasubskrybowanie!

- właśnie wysłaliśmy Twoją kopię „11 sprawdzonych technik zwiększania współczynnika sukcesu w sporach dotyczących kart kredytowych o 740%” na adres .

Masz literówkę w swoim e-mailu? kliknij tutaj, aby edytować adres e-mail i wyślij ponownie.

5. Oczyść dane wejściowe użytkownika

W poprzednim przykładzie dołączyliśmy dodatkową porcję danych przesłanych z JS do PHP. Za każdym razem, gdy pobierasz dane do swojego kodu, powinieneś oczekiwać, że będzie on niebezpieczny.

'user_data':'Some input from a user'

W tym przykładzie jest to prosty ciąg, ale ponieważ wysyłamy dane z powrotem do PHP, musimy upewnić się, że dane wejściowe nie zawierają żadnego kodu, który mógłby zostać wykorzystany w naszym środowisku PHP lub być przechowywany w bazie danych, co pozwala na dalsze nadużycia.

Wchodzi odkażanie. WordPress ma szereg funkcji, które pobierają dane wejściowe, które wprowadzisz, i czyszczą dane przed zwróceniem ich do Ciebie.

W tym przykładzie użyliśmy funkcji sanitize_text_field() , ale WordPress zawiera wiele funkcji odkażających dostosowanych do różnych typów danych.

Istnieje wiele innych wspaniałych funkcji i metod wbudowanych w WordPress, których możesz użyć do zabezpieczenia kodu i zapobiegania nadużyciom.

Nigdy, przenigdy nie powinieneś używać żadnych danych wysłanych do twojego kodu bez uprzedniego oczyszczenia go. Zapoznaj się z tym artykułem o typowych błędach programistów WordPress z dodatkowymi szczegółami na temat dezynfekcji i innymi świetnymi praktycznymi wskazówkami.

I to prowadzi mnie do następnej wskazówki, której doświadczyła większość programistów WordPress:

6. Pamiętaj, że `is_admin()` nie jest tym, o czym myślisz

Kiedy po raz pierwszy zaczniesz myśleć o ochronie swojego kodu przed złem, prawdopodobnie natkniesz się na funkcję is_admin() , a od nazwy brzmi to, że jest wszystkim, czego potrzebujesz, a wszystko, co musisz zrobić, to opakować swój kod w to, i wszystko będzie dobrze.

Nie, niestety nie. Funkcja is_admin() wykrywa tylko, czy kod jest wykonywany po stronie administracyjnej witryny. Nie wykrywa, czy Twój kod jest uruchamiany przez zwykłego użytkownika lub administratora.

Nigdy tego nie zauważysz, jeśli po prostu wpiszesz kod w swojej wtyczce, ponieważ najprawdopodobniej uruchamiasz kod w interfejsie administracyjnym, a to oznacza, że kod zostanie po prostu oceniony na true , a ty przestaniesz o tym myśleć i przejdziesz do czegoś w przeciwnym razie.

Prawidłowym sposobem sprawdzenia, czy użytkownik jest administratorem, jest sprawdzenie możliwości użytkownika:

  if ( current_user_can( 'activate_plugins' ) ) { 
    // Do your code here
  }

Istnieją różne możliwości dla różnych ról użytkowników, dzięki czemu masz znacznie bardziej szczegółową kontrolę. W większości przypadków 'activate_plugins' jest tym, czego potrzebujesz tylko dla administratorów.

Jeśli chcesz, aby umożliwić coś zarówno administratorom, jak i redaktorom, powinieneś przetestować pod kątem możliwości 'edit_pages' .

7. Dodaj rel="noopener" lub rel="noreferrer" do swoich linków

Łączenie się z zasobami zewnętrznymi jest całkiem normalne, a stara metoda dodawania target="_blank" do tych linków ma sens, ponieważ nie chcesz, aby użytkownicy opuszczali stronę wtyczki/motywu.

To jednak otwiera cię na coś, co nazywa się Tabnabbing. Jest to problem dotyczący bezpieczeństwa polegający na tym, że złośliwy kod JavaScript może wykraść informacje od użytkowników, nadużywając funkcji JavaScript window.opener .

Aby temu zapobiec, wystarczy dodać rel="noopener" do swoich linków. Strona, do której linkujesz dzisiaj, może być w porządku, ale może się to zmienić w przyszłości.

rel=noopener oznacza, że strona, do której prowadzisz, nie może uzyskać dostępu do informacji ani uzyskać żadnej kontroli nad Twoją stroną.

rel=noreferrer robi to samo, a także instruuje przeglądarkę, aby nie przekazywała żadnych informacji o skierowaniu za pośrednictwem nagłówka Referrer. Dodanie rel="noreferrer" oznacza, że strona, do której prowadzisz, nie wie, skąd pochodzi odwiedzający.

Uwaga: tych dwóch właściwości nie należy mylić z rel=nofollow , który jest powiązany z SEO.

8. Używaj HTTPS i bezpiecznych tokenów z zewnętrznymi interfejsami API

Jako programista często będziesz musiał integrować interfejsy API i ważne jest, aby zrobić to w bezpieczny sposób, aby chronić dane, które przesyłasz tam iz powrotem.

Na szczęście istnieją już normy dotyczące bezpiecznego wykonywania tego zadania; jednym z nich jest HTTPS. Korzystanie z protokołu HTTPS wprowadza warstwę bezpieczeństwa, w której wszystkie przesyłane dane są szyfrowane.

Jednak, aby mieć pewność, że Twoje dane są chronione przed oczami szpiega, korzystanie z HTTPS nie wystarczy.

Jak wyjaśnia ten artykuł autorstwa Ars Technica: „HTTPS nie oznacza, że Twoje dane są bezpieczne, oznacza to po prostu, że Twoje połączenie jest bezpieczne”.

Bezpieczne tokeny – JWT

Bezpiecznym standardem obsługi komunikacji i integracji API jest użycie JSON Web Tokens, JWT.

Bezpieczny token jest tworzony przez wysłanie żądania do serwera, który weryfikuje dane logowania użytkownika i generuje token, mały fragment ciągu, który zawiera dane, takie jak nazwa użytkownika, identyfikator i tak dalej.

Gdy wysyłasz kolejne żądania do serwera, dołączasz ten token do żądania. Ten token potwierdza, że jesteś uwierzytelniony i masz dostęp. Jeśli token jest ważny i nie wygasł, serwer użyje danych użytkownika zawartych w tokenie i pobierze żądane dane.

Serwer może w ten sposób szybko przetwarzać żądania, w przeciwieństwie do korzystania z klucza API, co wymagałoby wyszukania użytkownika za pomocą tego klucza przed podjęciem decyzji o przetwarzaniu danych. Używając tokena, możesz dołączyć do tokena dane dotyczące użytkownika i zapisać wiele zapytań do bazy danych.

Sposób, w jaki bezpieczny token jest generowany, a następnie używany, uniemożliwia tworzenie fałszywych tokenów lub manipulowanie zawartością tokena. Prawidłowy token jest możliwy tylko dzięki znajomości tajnego klucza, który firma stojąca za platformą będzie dobrze ukrywać.

Bardzo ważną uwagą do zapamiętania jest to, że dane wewnątrz tokena nie są szyfrowane. Nie można manipulować zawartością tokena bez jego unieważnienia, ale dane wewnątrz tokena mogą być łatwo odczytane przez każdego, więc nie jest to dobre miejsce do przechowywania danych wrażliwych.

Dobrym źródłem informacji, jeśli chcesz bardziej zagłębić się w tokeny i sposób ich działania, jest wprowadzenie do tokenów internetowych JSON.

9. Nie używaj zewnętrznych bibliotek z CDN

Chociaż może być kuszące, aby dołączyć dowolne biblioteki, których możesz potrzebować, za pośrednictwem cdnjs.com lub innych bezpłatnych globalnych sieci CDN, istnieje kilka wad.

Przede wszystkim nie masz kontroli nad bibliotekami i jakimkolwiek złośliwym kodem, który wkrada się do dołączonych plików.

Chociaż CDN są z definicji stabilne i szybkie, są również przedmiotem większej liczby ataków. Jeśli Twój kod opiera się na bibliotece JS w atakowanej sieci CDN, Twoja wtyczka i motyw będą ładowane bardzo wolno lub wcale.

Zdarzyło się to w przypadku witryny klienta, w której publiczny CDN, z którego korzystała w tym czasie wtyczka, przekraczał limit czasu dla użytkowników w niektórych regionach, przez co interfejs był bezużyteczny. W końcu musiałem zmienić wtyczkę, aby zamiast tego używała lokalnej kopii skryptu JS jako szybką naprawę.

Korzystanie z zewnętrznego źródła zewnętrznego może również naruszyć prywatność. CDN będzie mógł rejestrować wszystkie adresy IP użytkowników – koniecznie sprawdź politykę RODO i poinformuj swoich klientów.

Ogólnie rzecz biorąc, jeśli korzystasz z renomowanych zewnętrznych dostawców CDN, nie napotkasz żadnych problemów, ale najprostszym i najbardziej niezawodnym podejściem jest dystrybucja biblioteki JS zawartej w Twoim produkcie.

Czy wiedziałeś? WordPress zawiera kilka bibliotek JS. Wiele z bardziej popularnych bibliotek JS, których możesz chcieć użyć, jest dołączonych do WordPressa. Te biblioteki zaspokoją większość Twoich podstawowych potrzeb.

Wskazówka dla programistów: dodatkowe pliki JS i CSS należy ładować tylko na określonych stronach, których potrzebujesz. Jako programista i użytkownik bardzo nie lubię wtyczek, które spowalniają administratora, ładując niepotrzebne pliki JS i CSS na każdej stronie. Nie tylko spowalnia inne strony administracyjne, ale może również naprawdę zepsuć układ wizualny i sprawić, że niektóre strony administracyjne będą prawie bezużyteczne. Proszę

Istnieje również kilka narzędzi, które mogą pomóc w ochronie kodu, a świetnym narzędziem, z którego możesz korzystać bezpłatnie, jest Coderisk.

Zatrudnia

Starszy programista PHP

Zbuduj rdzeń produktów, usług i interfejsów API Freemiusa i zobacz, jaki masz bezpośredni wpływ na biznes wtyczek i motywów WordPress.

Specjalista ds. Migracji eCommerce

Zarządzaj migracją licencji i procesem integracji produktów dla firm zajmujących się wtyczkami i motywami, które zaczynają sprzedawać z Freemius.

Marketing treści

Dziel się naszą wiedzą za pomocą praktycznych treści pisemnych, wizualnych i dźwiękowych na temat najlepszych sposobów sprzedaży wtyczek i motywów.

10. Użyj narzędzi i usług do analizy kodu

Coderisk

Istnieje wiele zautomatyzowanych usług, które pomagają zidentyfikować problemy z kodem. Exakat, SonarSource i PHPStan, aby wymienić tylko kilka, i mój ulubiony — Coderisk.com — Łatwy sposób na znalezienie niektórych z bardziej oczywistych błędów bezpieczeństwa w kodzie.

Ta firma skanuje wszystkie wtyczki WordPress z publicznego repozytorium WordPress.org. Ich oprogramowanie jest w stanie skanować i identyfikować setki różnych rodzajów problemów związanych z bezpieczeństwem w oparciu o różne standardy kodowania.

Według ich własnych statystyk, do tej pory zeskanowali ponad 4 miliardy linii kodu publicznego i jest sporo problemów nawet z najlepszymi wtyczkami.

Rejestracja w ich bezpłatnej usłudze jest dość prosta – możesz utworzyć darmowe konto, a następnie zacząć zgłaszać swoje wtyczki. Zgłoszenie wtyczki jest tak proste, jak pobranie pojedynczego wiersza kodu, który umieszczasz w pliku readme.txt przy następnym wdrażaniu nowej wersji.

Dzięki temu możesz uzyskać dostęp do najnowszego skanu Twojej wtyczki, a wewnątrz mają określone informacje i szczegóły dotyczące każdego problemu, z linkami bezpośrednio do Twojego kodu.

Pamiętaj, że jest to usługa bezpłatna, więc mogą nie aktualizować skanowania Twojej wtyczki tak często, ale gdy otrzymasz powiadomienie, warto sprawdzić swój kod, ponieważ mogłeś wprowadzić błąd od czasu ostatniego sprawdzania Twój kod.

Interfejs jest dość łatwy w nawigacji, gdy już go opanujesz, a system jest bardzo przydatny, dając bardzo łatwe do zrozumienia instrukcje dotyczące tego, co jest nie tak, co pomaga wyśledzić błąd.

Istnieje również wiele sposobów filtrowania błędów i możesz oznaczyć każdy problem jako naprawiony lub wiele innych opcji, aby szybko uzyskać przegląd wszystkich problemów.

Uwaga: Jeśli nigdy nie uruchomisz Coderiska (ani żadnego innego narzędzia z tej kategorii) w swoim kodzie, nie przejmuj się liczbą podejrzanych problemów, przed którymi zostaniesz ostrzeżony. Narzędzia te mogą generować dużą liczbę fałszywych trafień, ponieważ analizują tylko kod bez zrozumienia logiki biznesowej. Użyj danych wyjściowych narzędzia jako solidnej początkowej listy elementów do przejrzenia.

PHP_CodeSniffer

Kolejnym świetnym narzędziem do sprawdzania kodu jest PHP_CodeSniffer. PHPCS składa się z dwóch skryptów, PHPCS, który sprawdza Twój kod i zgłasza błędy, oraz PHPCBF, który może automatycznie naprawiać wiele problemów zidentyfikowanych przez PHPCS.

Korzystanie z PHPCS jest bardzo łatwe w użyciu z wiersza poleceń po zainstalowaniu. To narzędzie nie zapobiegnie pojawianiu się problemów bezpieczeństwa w kodzie, ale możesz wyeliminować proste błędy kodowania, co znacznie utrudnia nadużywanie większych problemów.

Możliwe jest również zintegrowanie PHPCS bezpośrednio z edytorem, takich jak Sublime Text i Visual Code. W ten sposób możesz łatwo zobaczyć wszelkie błędy i szybko je naprawić w swoim IDE.

Bez względu na to, czy pracujesz w zespole, czy jako pojedynczy programista, warto skorzystać z automatycznego systemu, ponieważ jest to łatwy sposób na wyeliminowanie podstawowych problemów związanych z bezpieczeństwem, które w innym przypadku możesz przeoczyć.

Używanie zautomatyzowanego systemu do skanowania kodu pod kątem problemów z bezpieczeństwem nie jest bezpieczną metodą wyłapywania wszystkich błędów, ale może pomóc w zlokalizowaniu najbardziej oczywistych błędów.

11. Nie kopiuj i nie wklejaj kodu z sieci bez odpowiedniej recenzji

Zapewnienie maksymalnego bezpieczeństwa produktu WP powinno być procesem ciągłym, a nie tylko raz na jakiś czas. Wprowadzając nowe funkcje lub usuwając kod, możesz również wprowadzić nowe problemy z bezpieczeństwem.

Google nie zawsze jest Twoim przyjacielem. Jako programista jesteś przyzwyczajony do sprawdzania szerokiego Internetu w poszukiwaniu przykładów kodu, które mogą Cię zainspirować – lub po prostu przepisuj fragmenty tu i tam, jeśli jesteś leniwy.

Większość fragmentów kodu, które można znaleźć w Internecie, rzadko jest gotowa do użycia w bezpiecznym środowisku produkcyjnym i ma służyć jako przykład każdego problemu z kodowaniem, który próbujesz naprawić. Używanie tych fragmentów kodu na ślepo i bez przeglądu może bardzo szybko spowodować problemy.

Jako programista WordPressa jest dużo do zrobienia, a naprawienie pilnego problemu bezpieczeństwa we wtyczce z tysiącami instalacji nie powinno być jednym z nich.

Pamiętaj, że stawką jest Twoja reputacja

Jeśli nie zwracasz uwagi na bezpieczeństwo swojej wtyczki lub motywu, narażasz swoich użytkowników, ich firmy, firmę i reputację. To dużo potencjalnie straconego czasu i pieniędzy!

Luki w zabezpieczeniach mogą mieć ogromny wpływ na zaufanie klientów do Twojej marki lub produktów. Powyższy przykład Loginizera pokazuje, że nawet najbardziej żenujące luki w zabezpieczeniach mogą przydarzyć się samym twórcom wtyczek bezpieczeństwa! Inne przykłady oszustw wyborczych i włamań rządowych mówią nam, że każdy jest narażony.

Jeśli i kiedy odkryjesz lukę w zabezpieczeniach, działaj szybko, aby ją rozwiązać, i postępuj zgodnie z najlepszymi praktykami dotyczącymi publicznego informowania o problemie (jeśli to konieczne) wraz z wydaniem poprawki.

Jeśli będziesz wyprzedzać grę, jeśli chodzi o komunikację i problemy „public relations”, które mogą wynikać z luki w zabezpieczeniach, możesz uniknąć gigantycznych bólów głowy i zwiększyć swoją reputację zamiast ją niszczyć.

Dziękuje za przeczytanie!

Zaglądanie do wszystkich rzeczy, które musisz zrobić, kiedy nie wiesz, czego szukać, może być zniechęcające, a znalezienie właściwych informacji może być trudne. Jeśli nie masz pojęcia, od czego zacząć, powinieneś rozważyć sprawdzenie swojego produktu przez eksperta ds. Bezpieczeństwa WP (ja też robię przeglądy bezpieczeństwa).

Oszczędzanie pieniędzy lub czasu na przegląd bezpieczeństwa jest kuszące, ale koszt braku zabezpieczenia produktu w maksymalnym możliwym stopniu może być nawet wyższy na dłuższą metę.

To tylko niektóre ze sposobów, w jakie możesz i powinieneś chronić swój produkt WordPress przed nadużyciami. Jeśli masz jakiekolwiek wątpliwości, pamiętaj – nie ufaj nikomu