Cele mai bune practici de securitate pentru dezvoltatorii de pluginuri și teme WordPress
Publicat: 2020-12-09În calitate de dezvoltator WordPress, sunt multe decizii pe care trebuie să le iei cu privire la ce să lucrezi. Interesul și prioritatea dvs. principală sunt să construiți o temă sau un plugin uimitor, iar măsurile de securitate ocupă adesea un ban în spate atunci când vă așezați pe scaunul șoferului pentru a lucra la cod. Când a fost ultima dată când v-ați așezat și v-ați revizuit propriul cod pentru probleme de securitate? Nu, nu am crezut
Aceste sfaturi se bazează pe experiența mea atât în ceea ce privește dezvoltarea de plugin-uri la CleverPlugins, cât și pe nenumărați clienți să-și reia site-urile online după ce au fost piratați. Dezvoltarea unui plugin de securitate precum WP Security Ninja nu m-a făcut mai puțin paranoic în legătură cu codul altora.
Cel mai obișnuit motiv pentru site-urile web piratate este încă gestionarea proastă a parolelor, dar aceasta nu ar trebui să fie o scuză pentru a folosi unele dintre modalitățile simple prin care vă puteți proteja codul.
Când dezvoltați un plugin sau o temă, doriți ca acesta să devină popular și să îl aveți instalat pe cât mai multe site-uri web. Cu cât succesul tău este mai mare, cu atât sunt mai mari șansele ca oamenii să încerce să abuzeze de munca ta pentru a sparge site-urile utilizatorilor tăi.
Datorită popularității WordPress, acesta a devenit una dintre cele mai comune ținte pentru hackeri. Dacă o vulnerabilitate este detectată într-un plugin sau o temă, poate însemna că mii, dacă nu sute de mii de site-uri web sunt deschise pentru abuz.
Din păcate, se întâmplă în mod regulat să apară o vulnerabilitate într-un produs cunoscut, așa că merită să luați câteva măsuri de securitate de bază pentru a vă proteja codul pentru utilizatorii dvs.
Ce zici de echipa de revizuire WordPress.org?
S-ar putea să credeți că echipa care revizuiește pluginurile și temele înainte de a publica în depozitul oficial verifică tot felul de probleme de securitate, dar echipa este mică și este formată doar din câțiva oameni. Coada de pluginuri și teme de verificat este în continuă creștere, astfel încât timpul pe care îl au pentru a le revizui pe fiecare este limitat.
Cu toate acestea, dacă găsesc ceva, s-ar putea să vă închidă automat pluginul până când îl remediați sau vă avertizează prin e-mail că trebuie să remediați o vulnerabilitate înainte de un anumit interval de timp.
Ideea este că, odată ce pluginul sau tema dvs. este listată în depozit, puteți trimite actualizări prin intermediul depozitului fără screening suplimentar, astfel încât o vulnerabilitate se poate strecura cu ușurință oricând și rămâne nedetectată pentru aproape orice perioadă de timp.
Practic, înăsprirea măsurilor de securitate a pluginurilor depinde de dvs., așa că haideți să vedem câteva modalități prin care vă puteți proteja produsul WordPress și vă puteți preveni o mulțime de dureri de cap și, eventual, un impact negativ asupra mărcii dvs.
Iată ce puteți face pentru a vă dezvolta în siguranță pluginul sau tema WordPress.
1. Gândește-te la securitate din toate perspectivele!
Nu știi niciodată cine ar putea folosi pluginul sau tema și ce nivel de înțelegere au despre securitate, dacă este cazul.
Nu știi niciodată cine ar putea folosi pluginul sau tema și ce nivel de înțelegere au despre securitate, dacă este cazul.Tweet
Administratorii, editorii sau utilizatorii obișnuiți de pe orice site web al clienților ar putea să nu folosească parole sigure, iar conturile lor ar putea fi sparte. Dacă produsul dvs. nu este securizat, aceste conturi ar putea fi abuzate pentru a obține acces suplimentar pentru a instala cod rău intenționat pe site-ul web al clientului dvs.
Nu trebuie să vă așteptați ca administratorii de server care au configurat serverul pe care rulează site-ul web să cunoască suficient despre cum să vă protejați site-ul de alte site-uri de pe același server. Dacă site-ul web este găzduit de un furnizor mare, vă puteți aștepta ca site-ul web să fie „separat” în mod corespunzător, dar nu știți unde va fi instalat produsul dvs.
Sună paranoic? Pot fi. Dar, dacă și când pluginul sau tema ta devine super populară, vei fi fericit că ai adoptat o abordare paranoică a securității.
Dacă și când pluginul sau tema dvs. devine super populară, veți fi fericit că ați adoptat o abordare paranoică a securității.Tweet
2. Preveniți atacurile XSS – Cross-Site Scripting
Acesta devine din ce în ce mai important pe măsură ce WordPress devine un proiect mai mult bazat pe front-end cu Gutenberg și ReactJS.
Una dintre cele mai frecvente greșeli pentru dezvoltatorii WordPress este să uite să-și valideze și să-și igienizeze codul - lăsându-l deschis atacurilor XSS. Există câteva variante ale XSS, dar, în general, un atac XSS are loc atunci când unui hacker i se permite să injecteze cod în server și apoi să îl execute în browserul unui vizitator.
Imaginați-vă că aveți un câmp de introducere. De dragul simplității, să presupunem că este un câmp de comentarii în care utilizatorii sau vizitatorii pot trimite un comentariu la o postare.
Un hacker va încerca să trimită un comentariu cu "<script>alert('XSS');</script>"
.
Acum, acesta este doar un exemplu de bază care afișează o alertă pe ecranul utilizatorului și nimic altceva. Un hacker real va folosi câmpul de comentarii pentru a injecta cod care încarcă cod de pe site-ul său, care poate fura informații din browserul vizitatorului și multe altele.
Putem preveni acest lucru prin validare, igienizare și evadare.
Validarea înseamnă verificarea datelor transmise înainte de a face ceva, cum ar fi stocarea lor în baza de date. Ori de câte ori sunt transmise date, puteți să le verificați și să vă asigurați că sunt acceptabile. Dacă este un câmp de cantitate, vă așteptați la un număr. Dacă nu este un număr, puteți returna utilizatorului un mesaj de eroare.
Dezinfectarea datelor înseamnă procesarea informațiilor trimise și asigurarea faptului că acestea nu conțin nimic pe care nu vrem să îl stocăm, cum ar fi eliminarea oricăror caractere nedorite. WordPress are mai multe funcții încorporate pentru a ajuta acest lucru. Mai multe despre igienizare într-un pic.
Evadarea înseamnă a împiedica executarea efectivă a oricărui cod rău intenționat în browserul dvs. Să presupunem că ai deja injectat cod rău intenționat în site-ul tău web sau un alt plugin sau o temă permite hackerilor să introducă cod în datele pe care le folosești – evadarea datelor pe ecran înainte de a le arăta va împiedica să fie o problemă.
Să ne uităm la același exemplu simplu pe care l-am folosit înainte de "<script>alert('XSS');</script>"
Dacă nu facem nimic cu acest cod, browserul va crede că este cod HTML. Detaliul important aici sunt caracterele < > care sunt folosite pentru a defini etichetele HTML. Scăpând de acestea, transformăm <
în <
și >
în >
Browserul înțelege acum că acesta nu este un cod HTML real și ar trebui să arate doar un semn mai puțin decât și mai mare decât.
Prin validarea, igienizarea și evadarea tuturor datelor care intră și ies din aplicația dvs., vă protejați utilizatorii de una dintre cele mai comune metode de atac.
3. Aveți grijă la injecțiile SQL
După cum sugerează și numele, un atacator poate folosi injecții SQL pentru a face site-ul dvs. să proceseze o interogare SQL ajustată și să o folosească pentru a obține acces la baza de date.
În funcție de datele pe care le stocați pe site-ul dvs. web, ca datele site-ului dvs. să fie scurse dintr-un atac de injecție SQL ar putea trece de la a fi jenant la a vă devasta complet reputația și afacerea.
Injecția SQL este o modalitate veche de a ataca un site web, dar este încă foarte eficientă și există mulți oameni care caută modalități de a folosi această formă de atac. În octombrie 2020, popularul plugin WordPress Loginizer a anunțat că are o vulnerabilitate de injectare SQL care a pus în pericol peste un milion de site-uri web.
În 2019, hackeri necunoscuți au furat milioane de date fiscale ale bulgarilor printr-un atac de injecție SQL, iar în 2016, un grup de hackeri ruși a extras informații despre alegătorii a aproximativ 500.000 de persoane din Ohio. Aceste tipuri de atacuri sunt încă foarte eficiente și puteți găsi o mulțime de informații despre ele.
Sursa: https://xkcd.com/327/
Cel mai obișnuit loc în care are loc o injecție SQL este într-un câmp de formular care acceptă introducerea utilizatorului – de exemplu, un nume. Atacul are loc prin introducerea unor părți ale codului SQL în câmpurile de introducere, creând o interogare personalizată care oferă un rezultat diferit de cel la care v-ați aștepta.
Să presupunem că aveți un formular care permite oamenilor să caute un anumit nume.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' AND meta_key = 'celebrity_name';
Acest exemplu simplu ar prelua toate rândurile din tabelul meta post cu toate rândurile care au numele Henry
și o cheie specifică, celebrity_name
- în acest fel, nu returnăm întreaga bază de date și doar rândurile particulare de care avem nevoie.
Un atacator ar încerca să analizeze o valoare diferită – de exemplu 'Henry' OR 1=1--
Interogarea va returna acum toate rândurile cu valoarea noastră specifică sau orice altceva – deoarece OR 1=1
în SQL este întotdeauna adevărat.
Devine și mai rău, totuși. Interogarea noastră SQL a cerut doar rezultate în care meta_key
potrivește cu valoarea particulară pe care o căutăm, așa că nu am returna totul. Acest lucru ar trebui să limiteze impactul pe care îl are atacul de injecție SQL, nu?
Ei bine, nu așa. În SQL, liniuța dublă este un indicator de comentariu, deci tot ce vine după aceasta este comentat.
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1--' AND meta_key = 'celebrity_name';
Aceasta înseamnă că interogarea arată astfel:
SELECT * FROM wp_postmeta WHERE meta_value = 'Henry' OR 1=1
Interogarea acum returnează, în esență, totul din acel tabel al bazei de date.
Acesta a fost doar un exemplu simplu. Există multe modalități mai complicate de a accesa majoritatea, dacă nu toate, informațiile dintr-o bază de date. Un atacator ar putea încerca atacuri cu injecție SQL oarbă, ceea ce înseamnă rularea codului în baza de date - adăugarea unui nou administrator, eliminarea tuturor datelor și așa mai departe.
Cele mai multe atacuri ar fi sub forma unor șiruri de interogări aleatorii care conțin părți din SQL trimise în formularele site-ului dvs. Scripturile automate ar detecta orice modificări aduse site-ului dvs. web și apoi ar detecta potențialul de atac.
O modalitate simplă și eficientă este să trimiteți un apostrof '
ca intrare și să vedeți dacă modifică ceva, apare o eroare sau sunt returnate mai multe rezultate.
WordPress la salvare
În loc să interacționeze direct cu baza de date, orice dezvoltator ar trebui să folosească clasa de abstracție a bazei de date încorporată în WordPress, $wpdb
.
Clasa $wpdb
din WordPress are toată funcționalitatea CRUD de care aveți nevoie pentru a interacționa cu baza de date în siguranță și puteți chiar să utilizați clasa pentru a interacționa cu propriile tabele de bază de date dacă pluginul sau tema dvs. trebuie.
Puteți rezolva problema anticipând ce fel de date ar trebui introduse în mod rezonabil în fiecare formular de intrare. În exemplul nostru anterior, am căutat un nume. Am putea dezinfecta intrarea pentru a ne asigura că acceptăm doar litere. Dacă aveți o casetă de selectare sau un grup radio care conține doar câteva opțiuni, puteți verifica datele pentru a vă asigura că este doar una dintre opțiunile pe care le permiteți.
Cel mai important lucru pe care îl puteți face pentru a rezolva problema este să vă pregătiți datele cu funcția $wpdb->prepare()
.
Această funcție preia un șir de interogare pregătit și o matrice a argumentelor pe care doriți să le adăugați la interogarea SQL.
$meta_key = 'celebrity_name'; $meta_val = 'Henry' $allhenrys = $wpdb->get_results( $wpdb->prepare( "SELECT * FROM $wpdb->postmeta WHERE meta_key = %s AND meta_value = %s", $meta_key, $meta_val ) );
Toate lucrările au loc în interiorul funcției prepare()
. Primul parametru, interogarea pregătită – conține substituentul %s
în loc de valorile reale. Aceasta este înlocuită cu celelalte variabile analizate, $meta_key
și $meta_val
.
Notă – Este important să nu aveți un apostrof în interogarea dvs. în jurul substituenților, deoarece funcția le va adăuga pe aceștia pentru dvs.
Acesta este un exemplu simplificat, dar același proces poate fi folosit pentru orice interogare de bază de date și puteți folosi %s
pentru șiruri, %d
pentru numere întregi și %f
pentru floats.
Există, de asemenea, funcții pentru situații specifice, cum ar fi adăugarea unui nou rând la baza de date. În acest scop puteți folosi $wpdb->insert()
.
$wpdb->insert( "{$wpdb->prefix}my_custom_table", array( 'name' => 'Henry', 'userid' => 123, 'score' => 10, ), array( '%s', '%d', '%d', ) );
Utilizarea funcției de pregătire poate ajuta la prevenirea majorității încercărilor de injectare SQL împotriva produsului dumneavoastră.
Vă rugăm să nu uitați să verificați documentația $wpdb. Unele funcții vor scăpa de intrare pentru dvs.; alții se așteaptă ca tu să scapi de intrare înainte de a analiza datele în funcție.
4. Folosiți nonces pentru a vă proteja cererile
Utilizarea sistemului nonce în WordPress vă poate ajuta să preveniți multe atacuri. Un nonce din punct de vedere al securității este un număr folosit o singură dată. Ideea este să adăugați acest număr unic la toate solicitările pe care le faceți de la codul dvs. la instalarea WordPress ca o modalitate de a verifica dacă această solicitare este legitimă.
Este un pic ca și cum ai avea o parolă secretă pe care trebuie să o dai bouncerului pentru a intra într-un club
Cu toate acestea, nonce-urile în WordPress sunt puțin diferite - nu sunt nici un număr și nici nonce-ul nu este folosit o singură dată.
Din punct de vedere tehnic, nonces-urile din WordPress pot conține atât litere mici, cât și cifre, iar în loc să fie folosit o singură dată , se regenerează după o perioadă de timp.
Modul în care utilizați un nonce este că codul PHP care vă înregistrează fișierele JavaScript generează o mică combinație unică de numere și litere și analizează, astfel încât codul dvs. JS să o poată citi.
De fiecare dată când codul JavaScript trimite o solicitare către site-ul dvs., acesta trimite împreună acea bucată de cod și, dacă codul nu se potrivește, codul dvs. ar trebui să ignore complet solicitarea.
Este întotdeauna puțin mai ușor cu un exemplu, așa că haideți să vedem o modalitate simplă de a încărca un fișier .js în plugin, urmând acești pași:
Folosind nonces într-un plugin 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'); }
În această funcție, îi spunem WordPress să încarce un fișier JavaScript. În primul rând, înregistrăm fișierul pe care vrem să îl încărcăm cu wp_register_script()
.
Apoi folosim wp_localize_script()
pentru a analiza o serie de date, în special „nonce” care conține nonce unic pe care dorim să-l folosim în codul nostru JS. Amintiți-vă, puteți trimite tot felul de alte informații și în acea matrice, dar pur și simplu ne facem simplu în acest exemplu.
Când trimiteți o solicitare din fișierul JavaScript, trebuie să includeți acel nonce unic. Este ușor să faci asta:
Utilizarea nonce din pluginul WordPress într-un fișier 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); } }); });
Deoarece am folosit wp_localize_script()
, putem folosi variabila plugin_ajax_object în JavaScript. Trimitem nonce ca o variabilă, _ajax_nonce
.
Verificați și verificați un nonce într-un plugin WordPress din codul 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 se întâmplă cu funcția check_ajax_referer()
care verifică nonce și pur și simplu eșuează și oprește orice execuție suplimentară de cod dacă nonce nu se potrivește cu ceea ce era așteptat.
Puteți personaliza codul în continuare pentru a returna informații specifice utilizatorului despre ceea ce s-a întâmplat.
Utilizarea noncesului în codul dvs. este o modalitate rapidă, ușoară și eficientă de a preveni multe tipuri de încercări de hacking. Asta nu înseamnă că poți sări peste toate celelalte măsuri de securitate, dar ajută la reducerea celor mai grave probleme.
Îți amintești ce am spus despre a nu avea încredere în nimeni? Asta ne duce la o altă modalitate de a vă proteja codul - dezinfectarea.
Abonați-vă și luați o copie gratuită a cărții noastre
11 tehnici dovedite pentru a vă crește disputele privind cardurile de credit cu 740% rata de succes a câștigului
Distribuie unui prieten
Introdu adresa de e-mail a prietenului tău. Le vom trimite prin e-mail doar această carte, onoarea cercetașului.
Vă mulțumesc pentru partajarea
Minunat - tocmai a fost trimisă o copie a „11 tehnici dovedite pentru a-ți crește disputele legate de cardul de credit cu 740% rata de succes a câștigului”. . Vrei să ne ajuți să răspândim și mai mult cuvântul? Continuă, împărtășește cartea cu prietenii și colegii tăi.
Multumesc pentru abonare!
- tocmai ți-am trimis copia „11 tehnici dovedite pentru a crește rata de succes a câștigurilor cu cardurile de credit cu 740%” către .
Ai o greșeală de scriere în e-mail? faceți clic aici pentru a edita adresa de e-mail și a trimite din nou.
5. Dezinfectați intrarea utilizatorului
În exemplul anterior, am inclus o parte suplimentară de date trimisă de la JS la PHP. De fiecare dată când introduceți date în codul dvs., ar trebui să vă așteptați să fie nesigur.
'user_data':'Some input from a user'
În acest exemplu, este un șir simplu, dar deoarece trimitem date înapoi către PHP, trebuie să ne asigurăm că intrarea nu conține niciun cod care ar putea fi exploatat în mediul nostru PHP sau care ar putea fi stocat în baza de date, permițând abuzuri suplimentare.
Intervine igienizarea. WordPress are o gamă largă de funcții care preia orice intrare pe care i-o oferiți și curăță datele înainte de a vi le returna.
În acest exemplu, am folosit funcția sanitize_text_field()
, dar WordPress vine cu multe funcții de dezinfectare potrivite pentru diferite tipuri de date.
Există multe alte funcții și metode grozave încorporate în WordPress pe care le puteți folosi pentru a vă păstra codul în siguranță și pentru a preveni abuzul.
Nu ar trebui să utilizați niciodată datele trimise în codul dvs. fără să le dezinfectați mai întâi. Consultați acest articol despre greșelile comune ale dezvoltatorilor WordPress, cu mai multe detalii despre dezinfectare și alte sfaturi practice grozave.
Și asta mă duce la următorul sfat, pe care l-au experimentat majoritatea dezvoltatorilor WordPress:
6. Amintiți-vă că is_admin()
nu este ceea ce credeți
Când începeți să vă gândiți pentru a vă proteja codul de rău, probabil că veți întâlni funcția is_admin()
și, din nume, sună a fi tot ceea ce aveți nevoie și tot ce trebuie să faceți este să închei codul cu asta și totul va fi bine.
Nu, din pacate nu. Funcția is_admin()
detectează doar dacă codul este executat în partea de administrare a site-ului web. Nu detectează nimic dacă codul dvs. este rulat de un utilizator sau administrator obișnuit.
Nu o veți observa niciodată dacă introduceți codul în plugin-ul dvs. deoarece, cel mai probabil, rulați codul în interfața de administrare și asta înseamnă că codul se va evalua doar la true
și veți înceta să vă gândiți la asta și veți trece la ceva. altfel.
Modul corect de a verifica dacă un utilizator este administrator este să verifici capacitatea utilizatorului:
if ( current_user_can( 'activate_plugins' ) ) { // Do your code here }
Există capacități diferite pentru diferite roluri de utilizator, astfel încât aveți un control mult mai granular. În cele mai multe cazuri, 'activate_plugins'
este ceea ce aveți nevoie doar pentru administratori.
Dacă doriți o modalitate de a permite atât administratorilor, cât și editorilor să facă ceva, ar trebui să testați capacitatea 'edit_pages'
.
7. Adăugați rel=”noopener” sau rel=”noreferrer” la link-urile dvs
Conectarea la resurse externe este destul de normală, iar metoda veche de a adăuga target="_blank"
la acele linkuri are sens, deoarece nu doriți ca utilizatorii să părăsească pagina dvs. de plugin/temă.
Cu toate acestea, acest lucru vă deschide pentru ceea ce se numește Tabnabbing. Aceasta este o problemă de securitate în care codul JavaScript rău intenționat poate fura informații de la utilizatorii dvs. prin abuzarea funcției JavaScript window.opener
.
Prevenirea acestui lucru poate fi la fel de simplă ca și adăugarea rel="noopener"
la link-urile dvs. Pagina către care trimiteți astăzi poate fi în regulă, dar asta s-ar putea schimba în viitor.
rel=noopener
înseamnă că pagina către care conectați nu poate accesa informații sau nu poate obține control asupra paginii dvs.
rel=noreferrer
face același lucru și, de asemenea, instruiește browser-ul să nu transmită nicio informație de referință prin antetul Referrer. Adăugarea rel="noreferrer"
înseamnă că pagina către care trimiteți nu știe de unde provine vizitatorul dvs.
Notă: Aceste două proprietăți nu trebuie confundate cu rel=nofollow
, care este legat de SEO.
8. Utilizați HTTPS și Secure Tokens cu API-uri terță parte
În calitate de dezvoltator, va trebui adesea să integrați API-uri și este vital să faceți acest lucru în siguranță pentru a proteja datele pe care le trimiteți înainte și înapoi.
Din fericire, există deja standarde stabilite pentru a face acest lucru în siguranță; unul dintre ele este HTTPS. Utilizarea HTTPS introduce un nivel de securitate în care toate datele transmise sunt criptate.
Cu toate acestea, pentru a vă asigura că datele dumneavoastră sunt protejate împotriva ochilor spionaj, utilizarea HTTPS nu este suficientă.
După cum explică acest articol al Ars Technica, „HTTPS nu înseamnă că datele tale sunt sigure, înseamnă doar că conexiunea ta este sigură.”
Jetoane sigure – JWT
Un standard sigur pentru gestionarea comunicării și a integrărilor API este utilizarea JSON Web Tokens, JWT.
Un token securizat este creat prin efectuarea unei cereri către un server care validează detaliile de conectare ale unui utilizator și generează un token, o mică bucată de șir care conține date, cum ar fi numele de utilizator, ID-ul și așa mai departe.
Când trimiteți orice cereri ulterioare către server, includeți acel token în cerere. Acest simbol dovedește că sunteți autentificat și aveți acces. Dacă tokenul este valid și nu a expirat, serverul va folosi detaliile utilizatorului conținute în token și va extrage datele solicitate.
Serverul poate procesa rapid cererile în acest fel, în comparație cu utilizarea unei chei API, care ar necesita să caute utilizatorul prin acea cheie înainte de a decide să proceseze datele. Folosind un token, puteți include date în interiorul jetonului despre utilizator și puteți salva mai multe interogări la baza de date.
Odată cu modul în care este generat și utilizat ulterior un jeton securizat, nu este posibil să creați jetonuri false sau să manipulați conținutul unui jeton. Este posibil să creezi un token valid doar cunoscând o cheie secretă, pe care compania din spatele platformei o va păstra bine ascunsă.
O notă foarte importantă de reținut este că datele din interiorul unui token nu sunt criptate. Este imposibil să modifici conținutul jetonului fără a-l invalida, dar datele din interiorul unui jeton pot fi citite cu ușurință de oricine, așa că nu este un loc bun pentru a stoca date sensibile.
O resursă bună dacă doriți să explorați mai mult token-urile și modul în care funcționează ele este Introducerea la jetoanele web JSON.
9. Nu utilizați biblioteci externe de la CDN-uri
Deși poate fi tentant să includeți orice bibliotecă de care aveți nevoie prin cdnjs.com sau alte CDN-uri globale gratuite, există câteva dezavantaje.
În primul rând, nu aveți control asupra bibliotecilor și a oricărui cod rău intenționat care se strecoară în fișierele pe care le includeți.
Deși CDN-urile sunt în general stabile și rapide prin definiție, ele sunt, de asemenea, supuse mai multor atacuri. Dacă codul dvs. se bazează pe o bibliotecă JS pe un CDN atacat, atunci pluginul și tema se vor încărca fie foarte lent, fie deloc.
Acest lucru s-a întâmplat cu un site web al unui client în care CDN-ul public pe care îl folosea un plugin la momentul respectiv expira pentru utilizatorii din unele regiuni, făcând interfața inutilizabilă. În cele din urmă, a trebuit să schimb pluginul pentru a utiliza o copie locală a script-ului JS ca o soluție rapidă.
Utilizarea unei surse terțe externe ar putea compromite, de asemenea, confidențialitatea. CDN-ul va putea să vă înregistreze toate IP-urile utilizatorilor – asigurați-vă că verificați politica GDPR și vă informați clienții.
În general, dacă utilizați furnizori CDN terți de renume, nu vă veți confrunta cu probleme, dar cea mai simplă și mai de încredere abordare este să distribuiți biblioteca JS inclusă în produsul dvs.
Știați? WordPress vine cu mai multe biblioteci JS incluse. Multe dintre bibliotecile JS mai comune pe care ați dori să le utilizați sunt incluse în WordPress. Aceste biblioteci vor acoperi majoritatea nevoilor dumneavoastră de bază.
Sfat pentru dezvoltatori: vă rugăm să încărcați fișierele JS și CSS suplimentare numai în paginile specifice de care aveți nevoie. Ca dezvoltator și utilizator, nu-mi plac foarte mult pluginurile care încetinesc administrarea prin încărcarea fișierelor JS și CSS inutile pe fiecare pagină. Nu numai că încetinește alte pagini de administrare, dar poate, de asemenea, să încurce cu aspectul vizual și să facă unele pagini de administrare aproape inutilizabile. Vă rog
Există, de asemenea, câteva instrumente care vă pot ajuta să vă protejați codul, iar un instrument grozav pe care îl puteți folosi gratuit este Coderisk.
10. Utilizați instrumente și servicii pentru a vă analiza codul
Coderisk
Există multe servicii automatizate pentru a ajuta la identificarea problemelor de cod. Exakat, SonarSource și PHPStan pentru a numi câteva, și un favorit de-al meu – Coderisk.com – O modalitate ușoară de a găsi unele dintre erorile de securitate mai evidente din codul dvs.
Această companie scanează toate pluginurile WordPress din depozitul public WordPress.org. Software-ul lor este capabil să scaneze și să identifice sute de tipuri diferite de probleme de securitate pe baza diferitelor standarde de codare.
Conform propriilor statistici, până acum au scanat peste 4 miliarde de linii de cod public și există destul de multe probleme chiar și cu pluginurile de top.
Pentru a vă înscrie la serviciul lor gratuit este destul de simplu – vă puteți crea un cont gratuit și apoi puteți începe să vă revendicați pluginurile. Revendicarea unui plugin este la fel de simplă ca să luați o singură linie de cod pe care o introduceți în readme.txt data viitoare când implementați o nouă versiune.
Acest lucru vă permite să accesați cea mai recentă scanare a pluginului dvs. și, în interior, au informații și detalii specifice despre fiecare problemă, cu link-uri direct către codul dvs.
Rețineți că acesta este un serviciu gratuit, așa că s-ar putea să nu actualizeze scanarea pluginului dvs. atât de des, dar odată ce primiți o notificare, merită să vă verificați codul, deoarece este posibil să fi introdus o greșeală de la ultima dată când ați examinat. Codul tau.
Interfața este destul de ușor de navigat odată ce ați înțeles, iar sistemul este foarte util, oferindu-vă instrucțiuni foarte ușor de înțeles despre ceea ce este greșit, care vă ajută să urmăriți eroarea.
Există, de asemenea, o mulțime de moduri de a filtra prin erori și puteți marca fiecare problemă ca fiind remediată sau o mulțime de alte opțiuni pentru a vă ajuta să obțineți rapid o imagine de ansamblu asupra tuturor problemelor.
Notă: dacă nu rulați niciodată Coderisk (sau orice alt instrument din categoria sa) pe codul dvs., nu vă îngrijorați de numărul de probleme suspectate despre care veți fi avertizat. Aceste instrumente pot genera o cantitate bună de fals-pozitive, deoarece analizează doar codul fără a înțelege logica afacerii. Utilizați rezultatul instrumentului ca o listă de pornire solidă de elemente de revizuit.
PHP_CodeSniffer
Un alt instrument excelent pentru verificarea codului este PHP_CodeSniffer. PHPCS constă din două scripturi, PHPCS care vă verifică codul și vă raportează erorile și PHPCBF care poate rezolva automat o gamă lungă de probleme pe care le identifică PHPCS.
Utilizarea PHPCS este foarte ușor de utilizat din linia de comandă odată ce l-ați instalat. Acest instrument nu va preveni apariția problemelor de securitate în codul dvs., dar puteți elimina greșelile simple de codare, ceea ce face mult mai dificil să abuzați de probleme mai mari.
De asemenea, este posibil să integrați PHPCS direct în editorul dvs., cum ar fi Sublime Text și Visual Code. În acest fel, puteți vedea cu ușurință orice greșeli și le puteți remedia rapid în IDE.
Indiferent dacă lucrați în echipă sau ca un singur dezvoltator, merită să utilizați un sistem automatizat, deoarece este o modalitate ușoară de a elimina problemele de securitate de bază pe care altfel le-ați putea rata.
Utilizarea unui sistem automat pentru a vă scana codul pentru probleme de securitate nu este o metodă sigură pentru a prinde toate erorile, dar vă poate ajuta să identificați cele mai evidente greșeli.
11. Nu copiați și lipiți codul de pe web fără o revizuire adecvată
Păstrarea produsului WP cât mai sigur posibil ar trebui să fie un proces continuu, nu doar din când în când. Când introduceți noi funcții sau eliminați codul, puteți introduce și noi probleme de securitate.
Google nu este întotdeauna prietenul tău. În calitate de dezvoltator, ești obișnuit să verifici pe internetul larg pentru exemple de cod care să te inspire – sau pur și simplu să rescrii fragmente ici și colo dacă ești leneș.
Cele mai multe dintre bucățile de cod pe care le găsiți pe internet sunt rareori gata de utilizare într-un mediu de producție securizat și sunt menite ca un exemplu al oricărei probleme de codare pe care încercați să o remediați. Folosirea acestor bucăți de cod orbește și fără revizuire poate introduce probleme foarte rapid.
Sunt multe de făcut în calitate de dezvoltator WordPress, iar remedierea unei probleme urgente de securitate în pluginul tău cu mii de instalări nu ar trebui să fie una dintre ele.
Rețineți că reputația dvs. este în joc
Dacă nu acordați atenție securității pluginului sau temei dvs., vă puneți în joc utilizatorii, afacerile lor, afacerea și reputația dvs. Este o mulțime de timp și bani potențial pierdut!
Vulnerabilitățile de securitate pot avea un impact masiv asupra încrederii pe care clienții le acordă mărcii sau produselor dvs. Exemplul Loginizer de mai sus arată că până și cele mai jenante vulnerabilități de securitate se pot întâmpla dezvoltatorilor de pluginuri de securitate înșiși! Iar celelalte exemple despre frauda alegătorilor și hackurile guvernamentale ne spun că oricine este vulnerabil.
Dacă și când descoperiți o vulnerabilitate, acționați rapid pentru a o rezolva și urmați cele mai bune practici pentru anunțarea publică a problemei (dacă este necesar) împreună cu eliberarea unei remedieri.
Dacă rămâi înaintea jocului în ceea ce privește comunicarea și problemele de „relații publice” care ar putea apărea dintr-o vulnerabilitate, atunci poți evita unele dureri de cap uriașe și poți crește reputația în loc să o strici.
Mulțumesc pentru lectură!
Poate fi descurajant să te uiți la toate lucrurile pe care trebuie să le faci atunci când nu știi ce să cauți pentru început și poate fi greu să găsești informațiile potrivite. Dacă nu aveți nicio idee de unde să începeți, ar trebui să vă gândiți să vă revizuiți produsul de către un expert în securitate WP (fac și eu recenzii de securitate).
Este tentant să economisiți banii sau timpul pentru o revizuire a securității, dar costul de a nu vă asigura produsul cât mai mult posibil poate fi și mai mare pe termen lung.
Acestea sunt doar câteva dintre modalitățile prin care puteți și ar trebui să vă protejați produsul WordPress de a fi abuzat. Dacă aveți vreo îndoială, amintiți-vă – Nu aveți încredere în nimeni