Fiți atenți: funcțiile PHP și WordPress care vă pot face site-ul nesigur

Securitatea unui site WordPress (sau a oricărui site) este o problemă cu mai multe fațete. Cel mai important pas pe care îl poate face oricine pentru a se asigura că un site este securizat este să rețineți că niciun proces sau metodă nu este suficient pentru a se asigura că nu se întâmplă nimic rău. Dar există lucruri pe care le poți face pentru a ajuta. Una dintre ele este să fii la ceas, în codul pe care îl scrii și codul de la alții pe care îl implementezi, pentru funcții care pot avea consecințe negative. În acest articol, vom acoperi exact acelea: funcții pe care un dezvoltator WordPress ar trebui să le gândească clar înainte de a le folosi.

WordPress însuși oferă o bibliotecă considerabilă de funcții, dintre care unele pot fi periculoase. În plus, există o mulțime de funcții PHP pe care un dezvoltator WordPress (PHP) le va folosi cu o anumită frecvență care poate fi periculoasă atunci când este folosită.

Toate aceste funcții au utilizări legitime și sigure, dar sunt și funcții care pot face mai ușor ca codul tău să fie abuzat în scopuri proaste. Vom acoperi lucrurile cel mai probabil să fie cauza unei vulnerabilități de securitate și de ce trebuie să le urmăriți. Mai întâi vom epuiza funcțiile PHP din codul tău pe care actorii răi le pot folosi pentru rău, apoi vom vorbi despre funcțiile PHP specifice WordPress care pot provoca și dureri de cap.

Funcții PHP de care trebuie să aveți grijă

După cum am spus, PHP conține o mulțime de funcții ușor de utilizat. Unele dintre aceste funcții sunt renumite pentru ușurința cu care oamenii pot face lucruri rele cu ele. Toate aceste funcții au o utilizare adecvată, dar fiți atenți la modul în care le utilizați și la felul în care alt cod pe care îl introduceți într-un proiect.

Vom presupune că aveți deja ghilimele magice și înregistrările globale sunt dezactivate dacă versiunea dvs. de PHP le acceptă. Erau dezactivate implicit în PHP 5 și versiunile ulterioare, dar puteau fi activate pentru versiunile sub 5.4. Puține gazde au permis acest lucru, dar nu cred că un articol de securitate PHP este cu adevărat complet fără a le include.

Sau o mențiune că PHP 5.6 este ultima versiune 5.x cu suport de securitate în curs de desfășurare. Ar trebui să fii în ea, cel puțin. Și ar trebui să aveți un plan pentru a trece la PHP 7 înainte ca suportul 5.6 să se încheie la sfârșitul anului 2018.

După aceea, veți avea doar câteva funcții riscante de care trebuie să vă ocupați. Incepand cu…

extract este o veste proastă, mai ales pe $_POST sau similar

Din fericire, utilizarea funcției de extract a PHP a căzut în mare parte din favoarea. Miezul utilizării sale a fost că îl puteți rula pe o serie de date, iar perechile cheie-valoare vor deveni variabile vii în codul dvs. Asa de

 $arr = array( 'red' => 5 ); extract($arr); echo $red; // 5

ar funcționa. Acest lucru este grozav, dar este, de asemenea, foarte periculos dacă $_GET , $_POST , etc. În aceste cazuri, în esență, recreați singur problema register_globals : un atacator extern vă poate schimba cu ușurință valorile variabilei prin adăugarea unui șir de interogare. sau câmp de formular. Cea mai bună soluție este simplă: nu utilizați extract .

Dacă creați matricea pe care o extrageți singur, nu este o problemă de securitate să utilizați extract și, în unele cazuri, poate fi util. Dar toate utilizările lui au problema de a deruta viitorii cititori. Crearea unui tablou și apelarea extract este mai confuză decât declararea variabilelor. Așa că vă încurajez să faceți declarații manuale, cu excepția cazului în care este complet imposibil de fezabil.

Dacă trebuie să utilizați extract la intrarea utilizatorului, ar trebui să utilizați întotdeauna EXTR_SKIP . Aceasta are încă problema confuziei, dar elimină posibilitatea ca valorile dvs. prestabilite să poată fi modificate de un străin rău intenționat printr-un simplu șir de interogare sau modificare a formularului web. (Pentru că „omite” valorile deja setate.)

„ eval este rău” deoarece codul arbitrar este înfricoșător

eval în PHP și aproape orice altă limbă care îl poartă este întotdeauna în fruntea listelor ca aceasta. Și din motive întemeiate. Documentația oficială a PHP de pe PHP.net spune asta destul de sincer:

ATENȚIE : Construcția limbajului eval() este foarte periculoasă deoarece permite executarea unui cod PHP arbitrar. Prin urmare, utilizarea sa este descurajată. Dacă ați verificat cu atenție că nu există altă opțiune decât să utilizați acest construct, acordați o atenție deosebită să nu transmiteți date furnizate de utilizator în el fără a le valida în mod corespunzător în prealabil.

eval permite ca orice șir arbitrar din programul dumneavoastră să fie rulat ca și cum ar fi cod PHP. Aceasta înseamnă că este util pentru „meta-programare” în cazul în care construiți un program care poate construi singur un program. Este, de asemenea, foarte periculos, deoarece, dacă permiteți vreodată ca surse arbitrare (cum ar fi o casetă de text pe o pagină web) să fie transmise imediat evaluatorului de șiruri de eval , ați făcut dintr-o dată ușor ușor pentru un atacator rău intenționat să facă aproape orice poate PHP. faceți pe serverul dvs. Aceasta include, evident, conectarea la baza de date, ștergerea fișierelor și aproape orice altceva poate face cineva atunci când SSHed într-o mașină. Asta e rău.

Dacă trebuie să utilizați eval în programul dvs., ar trebui să faceți totul pentru a vă asigura că nu permiteți introducerea arbitrară a utilizatorului în el. Și dacă trebuie să permiteți utilizatorilor arbitrari accesul la intrări pentru a eval , limitați ceea ce pot face printr-o listă neagră de comenzi pe care nu le lăsați să ruleze sau (mai bine, dar mult mai greu de implementat) o listă albă care este doar comenzile pe care le aveți considera sigur. Mai bine, permiteți doar un număr mic de modificări ale parametrilor specifici, cum ar fi doar numere întregi validate.

Dar țineți întotdeauna cont de această linie a lui Rasmus Lerdorf, fondatorul PHP:

„Dacă „eval()” este răspunsul, aproape sigur că pui întrebarea greșită.”

Variații La eval

Există, pe lângă binecunoscutul eval , o varietate de alte moduri prin care PHP a suportat istoric șiruri-evaluate-ca cod. Cele două cele mai relevante pentru dezvoltatorii WordPress sunt preg_replace cu modificatorul /e și create_function . Fiecare funcționează puțin diferit, iar preg_replace după PHP 5.5.0 nu funcționează deloc. (PHP 5.5 și versiunile anterioare nu mai primesc actualizări oficiale de securitate și, prin urmare, cel mai bine nu sunt folosite.)

Modificatorii /e din Regex sunt, de asemenea, „răi”

Dacă rulați PHP 5.4.x sau mai jos, veți dori să fiți atenți la apelurile PHP preg_replace care se termină cu e. Asta poate arata ca:

 $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );) $html = preg_replace( '( (.*?) )e', '" " . strtoupper("$2") . " "', $html );) // or $html = preg_replace( '~ (.*?) ~e', '" " . strtoupper("$2") . " "', $html );)

PHP oferă diverse modalități de „îngrădire” în expresia dvs. obișnuită, dar principalul lucru pe care doriți să îl căutați este „e” ca ultimul caracter al primului argument al lui preg_replace . Dacă este acolo, de fapt treceți întregul segment găsit ca argument PHP-ului dvs. inline și apoi îl eval . Aceasta are exact aceleași probleme ca eval dacă lăsați intrarea utilizatorului în funcția dvs. Exemplul de cod poate fi înlocuit folosind în schimb preg_replace_callback . Avantajul acestui lucru este că ți-ai scris funcția, așa că este mai greu pentru un atacator să schimbe ceea ce este evaluat. Deci ai scrie cele de mai sus ca:

 // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html ); // uppercase headings $html = preg_replace_callback( '( (.*?) )', function ($m) { return " " . strtoupper($m[2]) . " "; }, $html );

Permiterea introducerii utilizatorului create_function s este, de asemenea, rău...

PHP are și funcția create_function . Acest lucru este acum depreciat în PHP 7.2, dar era foarte asemănător cu eval și avea aceleași dezavantaje de bază: permite ca un șir (al doilea argument) să fie transformat în PHP executabil. Și avea aceleași riscuri: îți este prea ușor să dai accidental unui cracker inteligent capacitatea de a face orice pe server dacă nu ai fost atent.

Acesta, dacă sunteți pe PHP peste 5.3, este chiar mai ușor de remediat decât preg_replace . Puteți să vă creați propria funcție anonimă fără a utiliza șiruri de caractere ca intermediari. Acest lucru este și mai sigur și mai ușor de citit, cel puțin pentru ochii mei.

assert Este, de asemenea, eval -Ca

assert nu este o funcție pe care văd că o folosesc mulți dezvoltatori PHP, în WordPress sau în afara acestuia. Intenția sa este pentru afirmații foarte ușoare despre condițiile prealabile pentru codul dvs. Dar, de asemenea, suportă o operație de tip eval . Din acest motiv, ar trebui să fii la fel de precaut ca și față de eval . Afirmațiile bazate pe șiruri (inima motivului pentru care acest lucru este rău) sunt, de asemenea, depreciate în PHP 7.2, ceea ce înseamnă că ar trebui să fie mai puțin îngrijorătoare în viitor.

Includerea fișierelor variabile este o modalitate de a permite eventual execuția PHP necontrolată

Am explorat destul de bine de ce eval este rău, dar ceva de genul include sau require($filename'.php') poate, mai ales acolo unde $filename este setat de la o valoare controlabilă de utilizator, să fie o veste la fel de proastă. Motivul este subtil diferit de eval . Numele de fișiere variabile sunt adesea folosite pentru lucruri precum rutarea simplă de la URL la fișier în aplicațiile PHP non-WordPress. Dar s-ar putea să le vedeți folosite și în WordPress.

Miezul problemei este că, atunci când include sau require (sau include_once sau require_once ), faceți ca scriptul dvs. să execute fișierul inclus. Mai mult sau mai puțin, eval conceptual acel fișier, deși rareori ne gândim la el în acest fel.

Dacă ați scris toate fișierele pe care le-ați include variabila și v-ați gândit la ce s-ar întâmpla atunci, sunteți bine. Dar este o veste proastă dacă nu v-ați gândit la ce va face include ing password.php sau wp-config.php . De asemenea, este o veste proastă dacă cineva ar putea adăuga un fișier rău intenționat și apoi ar putea executa include dvs. (deși în acel moment probabil aveți probleme mai mari).

Soluția la aceasta nu este totuși prea grea: hard-code include atunci când poți. Când nu puteți, aveți fie o listă albă (mai bună), fie o listă neagră de fișiere care pot fi incluse. Dacă fișierele din lista albă (adică ați verificat ce face atunci când sunt adăugate), veți ști că sunteți în siguranță. Dacă nu se află pe lista albă, scriptul nu îl va include. Cu această simplă modificare, ești destul de în siguranță. O listă albă ar arăta cam așa:

 $white_list = ['db.php', filter.php', 'condense.php'] If (in_array($white_list, $file_to_include)) { include($file_to_include); }

Nu transmiteți niciodată intrarea utilizatorului către shell_exec și variante

Acesta este unul mare. shell_exec , system , exec și backtick-urile în PHP permit codului pe care îl executați să vorbească cu shell-ul de bază (de obicei Unix). Acest lucru este similar cu ceea ce face eval periculos, dar dublat. Dublat pentru că dacă lăsați accesul utilizatorului să treacă aici fără grijă, atacatorul nici măcar nu este legat de constrângerile PHP.

Capacitatea de a rula comenzi shell din PHP poate fi foarte utilă ca dezvoltator. Dar dacă lăsați vreodată intrarea unui utilizator acolo, acesta are capacitatea de a câștiga pe ascuns o mulțime de puteri periculoase. Așa că aș merge până acolo încât să spun că intrarea utilizatorului nu ar trebui să fie niciodată transmisă funcțiilor de tip shell_exec .

Cel mai bun mod în care m-aș putea gândi pentru a gestiona acest tip de situație, dacă ați fi tentat să o implementați, ar fi să ofere utilizatorilor acces la un set mic de comenzi shell predefinite, cunoscute și sigure. Acest lucru ar putea fi posibil de asigurat. Dar chiar și atunci te-aș avertiza să fii foarte atent.

Urmăriți pentru unserialize ; Rulează codul automat

Acțiunea de bază de a apela la serialize pe un obiect PHP viu, de a stoca acele date undeva și apoi de a folosi acea valoare stocată mai târziu pentru a unserialize acel obiect înapoi la viață este cool. De asemenea, este destul de comun, dar poate fi riscant. De ce riscant? Dacă intrarea la acel apel de unserialize nu este complet sigură (să spunem că este stocată ca cookie, mai degrabă decât în ​​baza ta de date...), un atacator poate schimba starea internă a obiectului tău într-un mod care face ca apelul de unserialize să facă ceva rău.

Acest exploit este mai ezoteric și mai puțin probabil să fie observat decât o problemă de eval . Dar dacă utilizați un cookie ca mecanism de stocare pentru datele serializate, nu utilizați serialize pentru acele date. Folosiți ceva de genul json_encode și json_decode . Cu aceste două PHP nu va executa niciodată automat niciun cod.

Vulnerabilitatea de bază aici este că atunci când PHP unserialize un șir într-o clasă, apelează metoda magic __wakeup pe acea clasă. Dacă intrarea nevalidată a utilizatorului este permisă să fie unserialized , ceva precum un apel la baza de date sau o ștergere a fișierului în metoda __wakeup ar putea fi îndreptat către o locație periculoasă sau nedorită.

unserialize este diferit de vulnerabilitățile eval deoarece necesită utilizarea metodelor magice asupra obiectelor. În loc să-și creeze propriul cod, atacatorul este forțat să abuzeze de metodele tale deja scrise asupra unui obiect. Atât metodele magice __destruct , cât și __toString pe obiecte sunt, de asemenea, riscante, așa cum explică această pagină OWASP Wiki.

În general, ești în regulă dacă nu folosești metodele __wakeup , __destruct sau __toString în clasele tale. Dar pentru că s-ar putea să vedeți mai târziu pe cineva care le adaugă la o clasă, este o idee bună să nu lăsați niciodată un utilizator în apropierea apelurilor dvs. să serialize și să unserialize și să transmită toate datele publice pentru acest tip de utilizare, deși ceva de genul JSON ( json_encode și json_decode ) acolo unde există nu este niciodată executarea automată a codului.

Preluarea adreselor URL cu file_get_contents este riscantă

O practică obișnuită atunci când scrieți rapid un cod PHP care trebuie să apeleze o adresă URL externă este să ajungeți la file_get_contents . Este rapid, este ușor, dar nu este super sigur.

Problema cu file_get_contents este subtilă, dar este destul de comun ca gazdele să configureze uneori PHP să nu vă permită accesul la adrese URL externe. Acest lucru este menit să te protejeze.

Problema aici este că file_get_contents va prelua paginile de la distanță pentru dvs. Dar când face asta, nu verifică integritatea conexiunii protocolului HTTPS. Ceea ce înseamnă că scriptul tău ar putea fi o victimă a unui atac de tip man-in-the-middle, care ar permite unui atacator să pună aproape orice vrea în rezultatul paginii file_get_contents .

Acesta este un atac mai ezoteric. Dar pentru a mă proteja împotriva lui atunci când scriu PHP modern (bazat pe Compozitor), aproape întotdeauna folosesc Guzzle pentru a încheia API-ul cURL, mai sigur. În WordPress, este și mai ușor: utilizați wp_remote_get . Funcționează mult mai consecvent decât file_get_contents și va verifica implicit conexiunile SSL. (Puteți dezactiva asta, dar, um, poate nu...) Mai bine, dar puțin mai enervant de vorbit, sunt wp_safe_remote_get , etc. Acestea funcționează identic cu funcțiile fără safe_ în numele lor, dar vor face asigurați-vă că redirecționările și redirecționările nesigure nu au loc pe parcurs.

Nu aveți încredere orbitor în validarea URL-ului de la filter_var

Deci acesta este puțin obscur, așa că recuzită lui Chris Weigman pentru că a explicat-o în această discuție WordCamp. În general, filter_var al PHP este o modalitate excelentă fie de a valida, fie de a dezinfecta datele. (Deși, nu vă confundați cu privire la ceea ce încercați să faceți...)

Problema aici este destul de specifică: dacă încercați să o utilizați pentru a vă asigura că o adresă URL este sigură, filter_var nu validează protocolul. Aceasta nu este adesea o problemă, dar dacă transmiteți intrarea utilizatorului acestei metode pentru validare și utilizați FILTER_VALIDATE_URL , ceva de genul javascript://comment%0aalert(1) va ajunge. Adică, acesta poate fi un vector foarte bun pentru un atac XSS de bază într-un loc la care nu te-ai fi așteptat.

Pentru validarea unei adrese URL, funcția esc_url a WordPress va avea un impact similar, dar permite doar protocoalele permise. javascript nu este în lista implicită, așa că vă va ține în siguranță. Cu toate acestea, spre deosebire filter_var , va returna un șir gol (nu un fals) pentru un protocol nepermis care îi este transmis.

Funcții specifice WordPress pe care să țineți cont

În plus față de funcțiile de bază PHP potențial vulnerabile, există câteva funcții specifice WordPress care pot fi un pic de înțeles. Unele dintre acestea sunt foarte asemănătoare cu varietatea de funcții periculoase enumerate mai sus, unele puțin diferite.

WordPress deserializează cu maybe_unserialize

Acesta este probabil evident dacă citiți cele de mai sus. În WordPress există o funcție numită maybe_unserialize și, după cum ați ghici, deserializează ceea ce i se transmite dacă este necesar.

Nu există nicio vulnerabilitate nouă pe care aceasta o introduce, problema este pur și simplu că, la fel ca și funcția de unserialize de bază, aceasta poate provoca exploatarea unui obiect vulnerabil atunci când nu este serializat.

is_admin nu răspunde dacă un utilizator este administrator!

Acesta este destul de simplu, dar funcția este ambiguă ca nume și, prin urmare, este predispusă să încurce oamenii sau să fie ratată dacă vă grăbiți. Ar trebui să verificați întotdeauna dacă un utilizator care încearcă să efectueze o acțiune în WordPress are drepturile și privilegiile necesare pentru a efectua acea acțiune. Pentru aceasta, ar trebui să utilizați funcția current_user_can .

Dar ați putea, din greșeală, să credeți că is_admin va spune dacă utilizatorul actual este un cont la nivel de administrator și, prin urmare, ar trebui să poată seta o opțiune pe care o folosește pluginul dvs. Aceasta este o greșeală. Ce face is_admin în WordPress este, în schimb, să vă spună dacă încărcarea curentă a paginii este în partea de administrare a site-ului (față de partea frontală). Deci, fiecare utilizator care poate accesa o pagină de administrare (cum ar fi „Tabloul de bord”) va putea să treacă de această verificare. Atâta timp cât vă amintiți că is_admin este despre tipul de pagină, nu despre utilizatorul actual, veți fi bine.

add_query_arg() nu dezinfectează adresele URL

Acest lucru nu este atât de comun, dar a existat un val mare de actualizări în ecosistemul WordPress cu câțiva ani în urmă, deoarece documentația publică despre aceste funcții nu era corectă. Problema principală este că funcția add_query_arg (și inversul său remove_query_arg ) nu dezinfectează automat adresa URL a site-ului dacă nu i-a fost transmisă o adresă URL, iar oamenii credeau că a făcut-o. Multe plugin-uri au fost induse în eroare de Codex și, ca urmare, foloseau acest lucru în mod nesigur.

Principalul lucru pe care au trebuit să-l facă diferit: igienizează rezultatul unui apel la această funcție înainte de ao folosi. Dacă faci asta, ești cu adevărat ferit de atacurile XSS pe care le credeai că sunt. Deci arată ceva de genul:

 echo esc_url( add_query_arg( 'foo', 'bar' ) );

$wpdb->query() este deschis pentru atacul prin injecție SQL

Dacă știți despre injecția SQL, acest lucru poate părea o prostie, chiar de prisos de enumerat. Deoarece lucrul este că în orice mod în care accesați o bază de date (să zicem folosind driverele PHP mysqli sau PDO) pentru a crea interogări de baze de date care permit atacuri de injectare SQL.

Motivul pentru care apelez în mod special la $wpdb->query este că alte metode (cum ar fi insert , delete , etc.) pe $wpdb se ocupă de atacurile de injecție pentru tine. În plus, dacă sunteți obișnuit să faceți interogări de bază de baze de date WordPress cu WP_Query sau similar, nu va fi nevoie să luați în considerare injectarea SQL. Acesta este motivul pentru care îl spun: pentru a vă asigura că înțelegeți că este posibil un atac de injecție asupra bazei de date atunci când încercați prima dată să utilizați $wpdb pentru a vă face propria interogare.

Ce sa fac? Folosiți $wpdb->prepare() și apoi $wpdb->query() . De asemenea, veți dori să vă asigurați că vă pregătiți înainte de alte metode de „obținere” de $wpdb , cum ar fi, get_row() și get_var() . Altfel, Bobby Tables s-ar putea să te prindă.

esc_sql nu vă protejează nici de injecția SQL

Pentru majoritatea dezvoltatorilor WordPress, aș spune că esc_sql nu se înregistrează cu niciun sens, dar ar trebui. După cum tocmai am menționat, ar trebui să utilizați wpdb->prepare() înainte de a efectua orice interogare la baza de date. Asta te va ține în siguranță. Dar este tentant și de înțeles că un dezvoltator poate apela la esc_sql . Și s-ar putea aștepta să fie în siguranță.

Problema este că esc_sql nu are protecții la fel de robuste împotriva injectării SQL. Este într-adevăr o versiune glorificată a funcției add_slashes a PHP, pe care ați fost descurajat să o utilizați pentru a vă proteja baza de date de ani de zile.

Mai sunt de făcut, dar acesta este un mare început

Există mult mai mult în ceea ce privește securitatea decât să fii în căutarea funcțiilor din codul tău pe care atacatorii le pot folosi greșit. Nu am discutat, de exemplu, în profunzime despre necesitatea de a valida și igieniza toate datele pe care le primiți de la utilizatori și de a le scăpa înainte de a le introduce într-o pagină web (deși recent am publicat un articol pe acest subiect, „Protejarea WordPress-ului dvs. Site împotriva unui atac de scripting între site-uri”). Dar puteți și ar trebui să utilizați acest lucru ca parte a unei strategii de securitate mai largi.

Păstrarea acestei liste de funcții ușor de utilizat greșit alături de dvs. în timp ce faceți o inspecție finală înainte de a implementa un nou plugin în WordPress este o idee grozavă. Dar veți dori, de asemenea, să vă asigurați că aveți încredere în securitatea găzduirii dvs., să vă asigurați că utilizatorii dvs. au parole bune și multe altele.

Principalul lucru de reținut despre securitate este că cea mai slabă verigă a ta este cea care contează. Bunele practici într-un domeniu întăresc posibilele puncte slabe în altă parte, dar nu le pot corecta niciodată în totalitate. Dar fii atent la aceste funcții și vei avea un avans în cele mai multe.