ARK. 1Słownik pojęćStrony WWW, WordPress i hosting

XML-RPC

Protokół zdalnego wywoływania procedur, przesyłający wywołania zakodowane w XML przez HTTP. W WordPressie wystawiony plikiem xmlrpc.php (starszy kanał zdalnego zarządzania, dziś w większości zastąpiony przez REST API) i nadużywany do dwóch rzeczy: wzmacniania ataków brute-force (metoda system.multicall pozwala sprawdzić wiele haseł w jednym żądaniu, omijając liczniki nieudanych logowań) oraz do rozproszonych ataków DDoS, w których podatne witryny WordPress służą jako reflektory wysyłające ruch do ofiary (pingback).

TAB. 1Nazwabez tłumaczenia

Po angielsku	XML-RPC
Którą formą pisać	bez tłumaczenia Skrót, nazwa własna albo nazwa standardu — nie tłumaczymy w ogóle.
Inne formy	interfejs xmlrpc.php · starszy interfejs zdalnego wywoływania procedur w WordPressie
Odmiana	nieodmienne; w tekście zawsze z rzeczownikiem nadrzędnym: interfejs XML-RPC, interfejsu XML-RPC, żądanie XML-RPC, przez XML-RPC; nazwa pliku: xmlrpc.php (małymi literami)

TAB. 2Jak to nazywająprasa vs urząd

Prasa branżowa	„interfejs XML-RPC” (niebezpiecznik), „endpoint odpowiedzialny za obsługę XML-RPC”, „zablokować dostęp do xmlrpc.php” (sekurak)

TAB. 3Źródła3

Forma	Cytat	Skąd
EN	„Podatność (...) polega na wykorzystaniu endpointu odpowiedzialnego za obsługę XML-RPC, a dokładnie funkcjonalności pingback.”	sekurak.pl
EN	„jeśli w naszym WordPressie nie wykorzystujemy funkcjonalności związanych z XML-RPC, możemy zupełnie zablokować dostęp do xmlrpc.php na poziomie serwera WWW”	sekurak.pl
EN	„za atak odpowiedzialne są nie wtyczki w WordPressach, a sam WordPress, a dokładniej jego interfejs XML-RPC”	niebezpiecznik.pl

TAB. 4Obok w tej dziedzinie6

WPCS	WordPress Coding Standards (WPCS)	Zestaw reguł PHP_CodeSniffer sprawdzających, czy kod wtyczki lub motywu trzyma się oficjalnych standardów kodowania WordPressa. Poza stylem zawiera reguły bezpieczeństwa: weryfikację nonce, sanityzację i escapowanie danych oraz przygotowane zapytania SQL — to na nich opiera się automatyczna kontrola kodu przed wdrożeniem.
wpis na czarną listę (blacklisting)	blacklisting	Oznaczenie domeny jako niebezpiecznej przez Google Safe Browsing, przeglądarki lub filtry pocztowe, skutkujące ostrzeżeniem dla odwiedzających i gwałtowną utratą ruchu.
wtyczka bezpieczeństwa	security plugin	Wtyczka łącząca funkcje ochrony i wykrywania (zapora aplikacyjna, skaner plików, blokada prób logowania, powiadomienia, rejestr zdarzeń) — uzupełnienie, a nie zamiennik aktualizacji, kopii zapasowych i poprawnie napisanego kodu.
zabezpieczenia w .htaccess	.htaccess hardening	Reguły dopisane do pliku .htaccess (serwer Apache/LiteSpeed), które ograniczają dostęp do wrażliwych plików i katalogów WordPressa: blokują wp-config.php i xmlrpc.php, wyłączają listowanie katalogów (Options -Indexes), zabraniają uruchamiania PHP w uploads, zawężają wp-admin do wybranych adresów IP. Reguły wpisuje się poza blokiem # BEGIN WordPress, który WordPress sam nadpisuje.
zabezpieczenie katalogu hasłem	HTTP basic authentication (password-protecting wp-admin)	Dodatkowe hasło wymagane przez sam serwer WWW (okienko logowania przeglądarki, pliki .htaccess i .htpasswd) zanim w ogóle załaduje się wp-login.php lub wp-admin. Zatrzymuje boty zgadujące hasła WordPressa; trzeba wyłączyć z ochrony admin-ajax.php, bo korzystają z niego wtyczki na froncie strony.
zapytanie parametryzowane	prepared statement	Zapytanie SQL, w którym dane przekazuje się osobno od jego treści, dzięki czemu wartość od użytkownika nie może zmienić struktury zapytania — zalecana, niezależna od języka programowania ochrona przed SQL injection (w PHP: PDO/mysqli z bindowaniem parametrów). WAŻNE: WordPressowe $wpdb->prepare() NIE jest prawdziwym prepared statement — to własna funkcja działająca, jak pisze sekurak, „na zasadzie match & replace”, która podstawia wartości w miejsce %s/%d z escapowaniem po stronie PHP. Skutek praktyczny: sam szablon zapytania (pierwszy argument prepare) nigdy nie może pochodzić od użytkownika, bo wtedy parametryzacja niczego nie chroni.

Cały słownik →