WordPress dodatak može riješiti vrlo konkretan problem: povezati vanjski servis, automatizirati administracijski postupak ili dodati funkciju koju postojeći sustav nema. Budući da dodatak radi unutar stranice i obrađuje njezine podatke, sigurnost nije završna provjera nakon razvoja. Ona počinje opisom toga tko smije pokrenuti koju radnju i što se događa s primljenim podacima.
Jedna funkcija, jasne granice
Prije pisanja koda treba definirati odgovornost dodatka. Koje podatke čita, koje mijenja, tko ga koristi i s kojim se drugim dodacima povezuje? Dodatak koji istodobno mijenja naručivanje, korisničke uloge i prikaz sadržaja teže je pregledati i održavati. Manji, jasno opisani dijelovi olakšavaju provjeru promjena.
Vlastite funkcije, klase i pohranjene opcije trebaju jedinstvene nazive kako se ne bi sudarile s drugim dodacima. Za spremanje podataka i povezivanje s WordPressom prednost treba dati njegovim postojećim API-jima. Službeni priručnik za razvoj dodataka opisuje upravo te osnovne postupke.
Prvo opišite što dodatak smije učiniti
Uzmimo zamišljeni dodatak koji administratoru omogućuje izvoz narudžbi. Prije izrade gumba treba odgovoriti na nekoliko pitanja: tko smije pokrenuti izvoz, sadrži li datoteka osobne podatke, gdje se privremeno sprema i koliko dugo ostaje dostupna? Ako se izvoz pokreće u pozadini, treba znati tko može vidjeti njegov status i preuzeti rezultat. To su sigurnosna pitanja, ali i dio funkcionalnog opisa.
Korisno je za svaku radnju zapisati korisničku ulogu, podatke koje čita ili mijenja te posljedicu ponavljanja zahtjeva. Takav kratak pregled otkriva gdje se mora provjeriti ovlast i koji podaci nikada ne smiju završiti u javnoj poveznici. Ne predstavlja jamstvo sigurnosti, ali omogućuje da provjera prati stvarni tijek rada umjesto samo vidljivih gumba.
Za dodatke koji rade s osobnim ili poslovno osjetljivim podacima treba odrediti i tko ih može izbrisati, izvesti ili pregledati u zapisniku. Pravila pristupa mogu se promijeniti tijekom uporabe, pa je važno da ih dodatak ne pretpostavlja samo na temelju početne konfiguracije.
Provjera dopuštenja prethodi promjeni podataka
Nije dovoljno sakriti gumb od korisnika koji ne smije izvršiti radnju. Dopuštenje se mora provjeriti i na samoj putanji koja zahtjev obrađuje: u administraciji, AJAX pozivu ili REST zahtjevu. Za svaku radnju treba odrediti odgovarajuću mogućnost korisnika, a kada se mijenja određeni zapis, provjeriti ovlast nad tim zapisom.
WordPress sigurnosni token, odnosno nonce, štiti od određenih neželjenih zahtjeva, ali ne dokazuje da korisnik ima pravo mijenjati podatke. Zato se provjera tokena i provjera ovlasti koriste zajedno. To izričito navodi WordPress dokumentacija o sigurnosnim tokenima. Za javne obrasce bez prijave treba zasebno definirati koje su radnje dopuštene anonimnim posjetiteljima.
Token nije dozvola za radnju
Ako korisnik otvori administracijski obrazac i u njemu dobije valjan sigurnosni token, to još ne znači da ima pravo promijeniti svaki zapis. Token pomaže provjeriti podrijetlo zahtjeva u određenom kontekstu. Dodatak zasebno mora provjeriti korisnikovu ovlast, a kod promjene konkretnog zapisa i pravo rada nad tim zapisom. Isti redoslijed vrijedi kada zahtjev dolazi kroz AJAX ili REST sučelje.
Provjeru treba ponoviti na poslužitelju čak i ako su kontrola i poruka o pogrešci već riješene u pregledniku. Korisnik može poslati zahtjev bez otvaranja predviđenog zaslona. Zato skriveni gumb, JavaScript potvrda ili nepoznata adresa krajnje točke nisu zaštita. Za anonimnu javnu radnju treba zasebno ograničiti dopušteni opseg i predvidjeti zloporabu učestalim slanjem.
Ulaz provjerite, izlaz prilagodite mjestu prikaza
Podatak iz obrasca, URL-a ili vanjskog servisa ne treba smatrati pouzdanim samo zato što stiže preko poznate putanje. Provjerite vrstu, dopuštene vrijednosti, duljinu i očekivani format. Neispravan unos treba odbiti uz razumljivu poruku. Pri spremanju se primjenjuje odgovarajuća normalizacija, a pri prikazu se vrijednost prilagođava kontekstu: tekstu stranice, HTML atributu, URL-u ili drugom izlazu.
Primjerice, korisnički naziv prikazan kao tekst i vrijednost umetnuta u adresu poveznice ne obrađuju se jednakom funkcijom. Kod izravnog rada s bazom koriste se pripremljeni upiti umjesto spajanja korisničkog unosa u SQL niz. WordPressove upute za sigurnu obradu izlaza i OWASP-ov pregled zaštite od XSS-a korisni su za provjeru tih odluka.
Provjera ulaza i obrada izlaza nisu ista radnja
Primjerice, polje koje prima broj narudžbe treba odbiti vrijednosti izvan očekivanog oblika. Opis koji dopušta slobodan tekst može se normalizirati prije spremanja. Kada se oba podatka kasnije prikazuju, izlaz se obrađuje prema mjestu uporabe: tekst unutar HTML-a, vrijednost atributa i URL poveznice nemaju isti kontekst. Jedna opća funkcija na ulazu ne može zamijeniti pažnju pri svakom izlazu.
Na isti način treba promatrati podatke vraćene iz vanjskog servisa. Činjenica da odgovor dolazi s poznate adrese ne znači da će uvijek imati očekivanu strukturu ili siguran sadržaj. Provjera oblika odgovora, kontrolirana poruka pri pogrešci i sigurno prikazivanje vrijednosti štite i urednika i posjetitelja kada integracija zakaže.
Pri izravnom SQL upitu parametri se predaju kroz pripremljeni upit. Ručno dodavanje vrijednosti u SQL niz, čak i nakon pokušaja „čišćenja”, nepotrebno povećava rizik. U WordPressu se za uobičajene zapise najprije razmatraju postojeći API-ji, a vlastiti upit treba imati jasan razlog.
REST i integracije trebaju isti oprez
Ako dodatak uvodi REST rutu, potrebno je jasno odrediti tko joj može pristupiti i koje podatke vraća. Prava pristupa ne treba oslanjati na to što krajnja točka nije vidljiva u sučelju. Kod povezivanja vanjskog servisa treba ograničiti koje se informacije šalju, sigurno pohraniti pristupne podatke i definirati što se događa kada servis ne odgovori ili vrati neispravan rezultat.
Posebno je važno spriječiti da poruke o pogrešci ili zapisnici otkriju lozinke, tokene i osobne podatke. Integracija mora imati razumljiv način ponavljanja ili ispravka neuspjele radnje, bez dvostrukog izvršavanja poslovnog učinka.
Što provjeriti kod REST ruta i vanjskih servisa?
Za svaku REST rutu navedite dopušta li anonimni pristup ili traži prijavljenog korisnika, koje parametre prihvaća i vraća li podatke samo iz dopuštenog opsega. Provjera prava pristupa mora biti dio same rute, a ne pretpostavka da ju koristi samo administratorska stranica. Korisno je ispitati zahtjev s manjim ovlastima i zahtjev za tuđim zapisom, jer upravo tu često nastaju propusti.
Vanjski servis može kasniti, vratiti pogrešku ili nakratko prihvatiti zahtjev bez jasne potvrde. Dodatak mora znati smije li se tada pokušati ponovno i kako spriječiti dvostruki učinak. Ako se, primjerice, šalje narudžba, isti zahtjev ne bi smio nenamjerno stvoriti dvije narudžbe. U zapisniku treba ostaviti dovoljno podataka za dijagnostiku, ali bez lozinki, pristupnih ključeva i nepotrebnih osobnih podataka.
Provjera prije objave i nakon nadogradnje
Dodatak treba ispitati barem kroz tri skupine scenarija: očekivani uspjeh, odbijanje nedopuštene radnje i obradu pogrešnog ulaza. Provjerite i korisnika s manjim ovlastima, ne samo administratorski račun. Ako dodatak ovisi o WooCommerceu ili drugom dodatku, testirajte što se događa kada ovisnost nije aktivna ili se promijeni njezina verzija.
Prije puštanja u rad dogovorite sigurnosne kopije, način nadogradnje i povratka na prethodno stanje. Sigurnost nije jamstvo koje se dobije jednim pregledom koda; ovisi i o održavanju WordPressa, poslužitelja i svih povezanih dijelova. Dobar dodatak zato dolazi s jasnim opsegom, provjerljivim pravilima i planom održavanja.
Održavanje je dio sigurnosnog plana
Prije objave pripremite način ažuriranja i povratka na prethodnu verziju. Sigurnosna kopija korisna je tek kada se zna može li se iz nje vratiti i baza i datoteke te tko pokreće oporavak. Nakon nadogradnje provjerite nekoliko stvarnih radnji, uključujući one koje mijenjaju podatke, umjesto da se oslonite samo na to što se stranica otvara.
Dokumentirajte ovisnosti, potrebne postavke i osobe koje smiju pristupiti ključevima za vanjske servise. Kada se dodatak prestane koristiti, treba znati što se događa s njegovim podacima. Takve odluke olakšavaju buduće promjene i smanjuju mogućnost da zastarjeli dio sustava ostane aktivan bez vlasnika.
Ako postojeća stranica treba funkciju koju gotovi dodaci ne rješavaju, pogledajte kako pristupamo izradi WordPress dodataka i WooCommerce proširenja po mjeri. Prvi korak je kratak opis korisnika, podataka i radnji koje dodatak treba podržati.
