Ročno testiranje in zapiranje SQL Injection ranljivosti za webmasterje

Ročno testiranje SQL Injection ranljivosti je proces, s katerim nadzorujemo in pooblaščeno potrjujemo, ali podatki iz obrazcev, URL parametrov, piškotkov, iskalnih polj ali API vhodov vplivajo na poizvedbe v bazi podatkov na spletni strani. Cilj webmasterjev ni izvajanje napadov, temveč zgodnje odkrivanje znakov, kot so sporočila o napakah, nenormalni odgovori, nepričakovano obnašanje filtriranja ali okvare logike poizvedb, in nato trajno zapiranje ranljivosti z uporabo poizvedb s parametri, preverjanjem vnosa, omejevanjem pravic in varno konfiguracijo strežnika.

Ta vodnik ponuja kontrolni seznam, osredotočen na obrambo, ki ga je mogoče uporabiti brez ogrožanja živih podatkov strank. Teste izvajajte le na svoji spletni strani, v projektih s pisnim dovoljenjem ali v testnem okolju. Postopki za pridobivanje podatkov, obvladovanje avtentikacije, raziskovanje tabel ali preizkušanje nepooblaščenih sistemov so izven obsega tega člena. Pristop tukaj je prepoznati znake, zbrati minimum dokazov, izvesti popravke in ponovno testirati.

Kaj je SQL Injection in zakaj je kritičen za webmasterje?

SQL Injection je ranljivost, ki nastane, ko se podatki uporabnika dodajo v SQL poizvedbo, ne da bi bili varno razločeni. Na primer, če lahko uporabniški vnos v iskalnih poljih, filtrih, podrobnostih izdelka, obrazcih za prijavo, poizvedbah o naročilu ali seznamih upravljalske plošče spremeni poizvedbo v bazi podatkov, obstaja tveganje. Rezultat lahko vključuje uhajanje podatkov, nepooblaščene operacije, manipulacijo z vsebino, prevzemanje uporabniških računov ali popolno onemogočitev spletnega mesta.

Razred injekcij se že vrsto let nahaja na vrhu seznama OWASP Top 10. Od majhnih blogov do e-trgovinskih platform lahko vsak projekt, ne glede na velikost, postane žrtev. Še posebej so ogrožene stare PHP aplikacije, neposodobljeni vtičniki, po meri napisane administrativne plošče, napačna uporaba ORM in API končne točke, ki niso beležene. Varnostna plast gostovanja ne odpravi tveganja sama; vendar pa ažurne različice PHP, izolirani računi gostovanja, WAF, redno varnostno kopiranje in SSL zmanjšujejo škodo. V tej fazi lahko naravno preverite svojo infrastrukturo z Spletno gostovanje in SSL certifikat stranema.

Varnostna priprava pred začetkom ročnega testiranja

Kvaliteta ročnega testiranja je v neposredni povezavi s pripravami. Namesto naključnih poskusov je treba določiti obseg, okolje, načrt beleženja in povratnih informacij. Še posebej, če izvajate teste v produkcijskem okolju, je treba previdno upravljati vpliv na zmogljivost in napačne pozitivne rezultate. Najvarnejši pristop je izvajanje testov na kopiji staging, ki deluje s istim kodo in podobno shemo baze podatkov.

1. Določite obseg in pravice

• Naštejte domene, poddomene, panele in API končne točke, ki jih boste testirali.
• Izključite tretje osebe, za katere nimate pravic.
• Testiranje opravite v obdobju z nizkim prometom.
• Omejite operacije, ki spreminjajo podatke, na testne uporabnike in testne podatke, če je mogoče.
• Pripravite varnostne kopije in dostopne podatke, da se vrnete v primeru napake.

Če se pripravlja nova spletna stran, ne odlašajte s preverjanjem varnosti med prehodom domene, DNS in gostovanja. Pred objavo je treba izvesti varnostno preverjanje, skupaj s koraki, kot so vprašanje domene in Linux gostovanje.

2. Izdelajte zemljevid vhodov aplikacije

SQL Injection se običajno pojavi na mestih, kjer uporabnik pošilja podatke. Zato najprej natančno zamejite površino. Zapišite naslednja področja: URL parametri, POST obrazci, iskalna polja, filtri kategorij, parametri razvrščanja, polja za košarico in naročila, uporabniški profili, obrazci za komentarje, seznami upravljalskih plošč, JSON API telesa, HTTP glave in piškotki. Za vsak vnos zapišite pričakovani tip podatkov. Na primer, ali je id numeričen, ali je slug besedilo, ali je datum v določenem formatu, ali se razvrščanje izbira le iz dovoljenih stolpcev?

3. Vklopite beleženje in varnostno kopiranje

Med testiranjem aplikacijski dnevniki, dnevniki dostopa spletnega strežnika in dnevniki napak v bazi podatkov zagotavljajo dragocene dokaze. Vendar pa je napaka, da v proizvodnji prikazujete podrobne napake v bazi podatkov uporabnikom. Pravilna praksa je, da uporabniku prikažete splošno sporočilo o napaki ter podrobnosti zapišete v varni dnevnik. Pred testiranjem naredite posodobljeno varnostno kopijo. Na kritičnih straneh je treba ločeno shraniti varnostne kopije datotek, varnostne kopije baze podatkov in varnostne kopije konfiguracij. Na strani Hostragons lahko preverite svoj načrt varnostnega kopiranja glede na infrastrukturo, ki jo uporabljate, skupaj z Varnostno kopiranje gostovanja.

Ročno testiranje SQL Injection ranljivosti: korak za korakom kontrolni seznam

Naslednji koraki temeljijo na neškodljivem opazovanju in logiki preverjanja. Cilj ni pridobivanje podatkov, temveč ugotoviti, ali vnos moti logiko poizvedbe. Pri vsakem testiranju najprej zabeležite normalno vedenje, nato pa opazujte razliko v odgovorih le z majhnimi in povratnimi spremembami.

Korak 1: Uporabite normalen odgovor kot referenco

Izberite stran s podrobnostmi o izdelku, iskalni obrazec ali zaslon za filtriranje uporabnikov. Zabeležite HTTP statusno kodo strani, čas odgovora, število zapisov, naslov strani in sporočilo, ki se prikaže na zaslonu. Na primer, če stran s produktom vrne 200, se odpre v 120 ms in prikaže en izdelek, to postane vaša referenca. Brez reference lahko vsak upočasnitev ali napaka pomotoma pomeni ranljivost.

Korak 2: Preverite nezdružljivost tipov in preproste napake pri razčlenjevanju

Kaj se zgodi, ko pošljete besedilno vrednost na numerično pričakovano polje, neobičajne posebne znake na besedilno pričakovano polje ali različne formate na polje, ki pričakuje datum? Varnostna aplikacija bodisi zavrne vnos bodisi vrne nadzorovano napako. Tvegana aplikacija lahko prikaže sporočilo o napaki v bazi podatkov, spremeni število zapisov ali pokvari strukturo strani. Ključno točko tukaj predstavlja vsebina sporočila o napaki. Če vidite sintaktične napake SQL, imena tabel, imena stolpcev, imena gonilnikov ali dele poizvedb, to kaže na uhajanje informacij, ki jih je treba popraviti, tudi če ni prišlo do injekcije.

Korak 3: Opazujte razlike v logičnih odgovorih

Nekatere ranljivosti ne povzročajo neposrednih napak; le rezultati, ki jih prikazuje stran, se spremenijo. Na primer, če se v normalnih pogojih prikaže 3 izdelke, lahko majhna sprememba logike povzroči, da se število rezultatov nepričakovano poveča ali zmanjša na nič. V tej fazi beležite le, ali obstajajo razlike v odgovorih, ne da bi poskušali pridobiti podatke. V varnih sistemih se uporabniški vnos obravnava kot parameter, zato posebni znaki ne spremenijo logike poizvedbe; preprosto postanejo del iskanega besedila.

Korak 4: Preučite sporočila o napakah in HTTP kode

SQL Injection ni vedno očitna napaka, ki se prikaže na zaslonu. Včasih se lahko prikaže kot napaka 500, prazna bela stran, druga usmeritev, nepričakovani odgovor 403 ali dolgotrajna zahteva. Če se v dnevnikih spletnega strežnika za isto zahtevo pojavi izjema na ravni aplikacije, je treba preučiti ustrezen del kode. Še posebej lahko zadnje izjave predstavljajo signal tveganja: napaka baze podatkov, sintaksa SQL, neznan stolpec, neobdeljena navedba, izjema PDO, napaka MySQL, napaka PostgreSQL ali napake pri poizvedbah ORM. Te podrobnosti morajo biti v proizvodnji skrite pred uporabniki.

Korak 5: Ne pozabite na API in AJAX končne točke

Na sodobnih straneh se mnoge poizvedbe izvajajo v ozadju prek API končnih točk namesto na vidni strani. Odprite razdelek Network v orodjih za razvijalce brskalnika in preglejte JSON zahteve, končne točke filtriranja in AJAX klice upravljalske plošče. Enaka pravila varnosti veljajo tudi za API: preveriti je treba tip podatkov, uporabiti je treba seznam dovoljenih vrednosti, uporabljati je treba poizvedbe s parametri in poenostaviti izhod napak. Za širše kontrole varnosti API je koristno povezati Varnost API.

Korak 6: Preizkusite nadzorne mehanizme skupaj z varnostjo SQL

SQL Injection ni le v zvezi s pisanjem poizvedb; pomemben je tudi dizajn pravic. Če uporabnik lahko dostopa do drugih naročil, ko spremenite id parameter, ko bi moral videti le svoja lastna naročila, to morda ni neposredna injekcija, a predstavlja resno luknjo v nadzoru dostopa. Varnostna aplikacija mora pridobiti id uporabnika iz strežnikove seje in se ne sme zanašati na vrednost id, ki jo pošlje stranka. Ta kontrola je še posebej kritična v sistemih, kot so uporabniški paneli, računi, podporni zahtevki in članstva.

Kako interpretirati ugotovitve ročnega testiranja?

Za ugotovitev, ali je ugotovitev resnična ranljivost, poiščite vsaj dva dokaza: razliko v odgovorih in zapis v dnevniku. En sam napaka 500 ne pomeni nujno SQL Injection; to je lahko tudi posledica napake pri dovoljenju datotek, omejitve pomnilnika ali konflikta vtičnikov. Vendar pa, če napaka v bazi podatkov skupaj z uporabniškim vnosom kaže na isto točko, mora biti prioriteta visoka.

Načini zapiranja SQL Injection ranljivosti

Trajna rešitev ni le namestitev enega varnostnega vtičnika. Prava rešitev je ploskovna: varna koda, omejen uporabniški račun baze podatkov, trdna uprava napak, posodobljena infrastruktura, spremljanje in redno testiranje morajo biti hkrati izvedeni.

1. Uporaba poizvedb s parametri in pripravljenih izjav

Najosnovnejša obramba je, da uporabniški vnos ne združujemo s SQL besedilom. V primeru PHP PDO je varen pristop naslednji: s `prepare` ustvarimo šablono poizvedbe, uporabniški podatki se v fazi `execute` posredujejo kot parameter. Na primer: `$stmt = $pdo->prepare('SELECT id, title FROM posts WHERE slug = ?'); $stmt->execute([$slug]);`. Na ta način bazni sistem obravnava vnos kot podatke in ne kot ukaz.

Tudi pri uporabi ORM bodite previdni. Standardni graditelj poizvedb v Laravelu, Symfonyju, Djangou ali podobnih okvirih je v večini primerov varen; vendar pa se ob pisanju surove poizvedbe tveganje ponovno pojavi. Če je surova SQL nujna, je treba uporabiti vezavo parametrov in ne izvajati združevanja nizov.

2. Uporabite preverjanje vnosa in seznam dovoljenih vrednosti

Poizvedbe s parametri so glavna obramba; vendar pa je validacija drugi močan sloj. Polje id naj bo le pozitivno celo število, datum v formatu ISO, e-poštno polje pa mora ustrezati formatu e-pošte, parametra razvrščanja pa naj se izbirata le iz dovoljenih stolpcev. Še posebej pri poljih, kot je `order by`, kjer določamo ime stolpca ali smer, vezava parametrov morda ne bo zadoščala. V tem primeru uporabite seznam dovoljenih vrednosti: na primer, razvrščanje naj bo le po price, created_at in title; smer pa naj bo omejena z asc ali desc.

3. Omejite pravice uporabnika baze podatkov

Uporabniški račun spletne aplikacije ne sme biti administrator, ki lahko počne vse. Na večini strani ima aplikacijski račun le potrebna dovoljenja za SELECT, INSERT, UPDATE in DELETE; dovoljenja, kot so DROP, ALTER, CREATE, pa so v proizvodnji onemogočena. Za poročanje se lahko uporabi ločen uporabnik samo za branje, za vzdrževanje pa ločen administrativni račun. Tako se tudi v primeru ranljivosti področje vpliva zmanjša.

4. Upravite napake na varen način

V proizvodnem okolju izklopite podroben prikaz napak. Uporabniku posredujte splošno sporočilo: operacija trenutno ni mogoča. Podrobne izjeme, informacije o poizvedbah, poti do datotek in sled stack morajo biti dostopne le v omejenih dnevnikih. Dnevniki morajo biti redno prečiščeni, občutljivi podatki morajo biti maskirani in dostop do njih mora biti zaprt za nepooblaščene uporabnike.

5. Uporabite WAF, posodobljene različice in plast gostovanja

Web Application Firewall zagotavlja dodatno plast zaščite pred zlonamernimi vzorci; ne nadomešča pa napačno napisanega kode. PHP, Node.js, Python paketi, CMS jedro, teme in vtičniki morajo biti posodobljeni. Stare različice lahko vsebujejo znane ranljivosti SQL Injection in pomanjkljivosti pri upravljanju napak. Za webmasterje, ki uporabljajo WordPress, je varnost WordPressa vodnik dobra dopolnitev glede izbire vtičnikov in discipline posodabljanja.

Na strani gostovanja je pomembna struktura izoliranih računov, posodobljena različica baze podatkov, redno varnostno kopiranje, varne pravice do datotek in uporaba SSL. SSL ne zapre ranljivosti SQL Injection, zagotavlja pa zaščito podatkov uporabnikov med prenosom po omrežju. Še posebej je uporaba SSL certifikat osnovna zahteva na straneh, ki vključujejo prijavo, plačila in uporabniške panele.

6. Opravite pregled varne kode in ponovno testirajte

Po popravku ponovno izvedite iste ročne teste. Pričakovani rezultat je: posebni znaki ne smejo spremeniti logike poizvedbe, napake ne smejo uporabniku nuditi podrobnosti, v dnevnikih ne sme biti neobvladanih napak v bazi podatkov in kontrole pravic ne smejo biti kršene. Pri pregledu kode iščite mesta, kjer se SQL oblikuje s povezovanjem nizov. V velikih projektih je že preprosto iskanje koristno: lahko preučite datoteke, ki vsebujejo besede SELECT, WHERE, ORDER BY, raw, query, exec.

Praktična varnostna rutina za webmasterje

Varnost SQL Injection ni enkratna kontrola, temveč redni vzdrževalni postopek. Vsak mesec preverite posodobitve CMS in vtičnikov. Na tri mesece enkrat ročno preglejte kritične obrazce in API končne točke. Po večjih spremembah kode ponovno preglejte poizvedbe v bazi podatkov. Za vsako novo razvito funkcionalnost si zastavite naslednjih 5 vprašanj: Ali to polje sprejema uporabniški vnos? Ali je tip podatkov preverjen? Ali je poizvedba s parametri? Ali napaka prikazuje podrobnosti uporabniku? Ali je pravica uporabniškega računa za to operacijo res potrebna?

Poleg tega testirajte, ali so varnostne kopije obnovljive. Mnoge strani mislijo, da izdelujejo varnostne kopije, vendar se pogosto ne preizkuša postopek ponovnega vračanja, kar vodi do težav v kriznih trenutkih. Varnostno gostovanje, trdna varnostna kopiranja in disciplinirano razvijanje kode skupaj močno zmanjšajo tveganje SQL Injection.

Pogoste napake

• Zanašanje le na preverjanje JavaScript na strani odjemalca. Napadalec ne potrebuje brskalnika; preverjanje na strani strežnika je nujno.
• Meniti, da je čiščenje enojnih narekovajev dovolj. Sodobna obramba je poizvedba s parametri, ne pa čiščenje znakov.
• Meniti, da je upravna plošča varna. Upravljalske plošče prav tako sprejemajo uporabniške vnose in morajo biti testirane.
• Meniti, da so vse poizvedbe v ORM samodejno varne. Surove poizvedbe in dinamična polja razvrščanja lahko predstavljajo tveganje.
• Da bi uporabniškemu računu baze podatkov dodelili preveč pravic. Uporabiti je treba načelo minimalnih pravic.
• Pustiti podroben prikaz napak odprt v produkcijskem okolju. To lahko predstavlja zemljevid za napadalca.

Povzetek: Prednostne naloge testiranja in zapiranja

Pogosto zastavljena vprašanja

Ali je ročno testiranje SQL Injection ranljivosti zakonito?

Zakonito je le na vaših sistemih ali v projektih, za katere imate pisno dovoljenje. Nepooblaščeni poskusi na tretjih straneh niso zakoniti in etični. Obseg testiranja, časovni okvir in metode morajo biti vnaprej jasno določeni.

Ali uporaba WAF sama po sebi odpravlja tveganje SQL Injection?

Ne. WAF je dodatna plast zaščite, vendar ne odpravi napačno napisanih poizvedb. Trajna rešitev vključuje poizvedbe s parametri, preverjanje vnosa, varno upravljanje napak in načelo minimalnih pravic.

Kje se najpogosteje pojavljajo SQL Injection ranljivosti na WordPress straneh?

Ponavadi izhajajo iz neposodobljenih vtičnikov, nezanesljivih tem, po meri napisanih kratkih kod in napačno obdelanih obrazcev. Jedro, teme in vtičniki morajo biti posodobljeni; neuporabljeni vtičniki morajo biti odstranjeni.

Ali sta SQL Injection in ranljivost nadzora dostopa isto?

Ne. SQL Injection pomeni spremembo logike poizvedbe s strani uporabniškega vnosa. Ranljivost nadzora dostopa pa pomeni, da ima uporabnik dostop do virov, ki jih ne bi smel videti. Vendar se lahko obe ranljivosti skupaj pojavita na istem zaslonu in ju je treba testirati skupaj.

Kako lahko potrdim, da sem zaprl ranljivost?

Po popravku ponovno izvedite teste z istimi vnosi. Rezultati se ne smejo spremeniti, podrobne napake v bazi podatkov se ne smejo prikazati, v dnevnikih ne sme biti neobvladanih SQL napak in nadzori pravic morajo delovati pravilno. Na kritičnih sistemih se priporoča neodvisen pregled kode ali testiranje varnosti.

Zaključek

Postopek ročnega testiranja SQL Injection ranljivosti ni tehnična luksuz za webmasterje, temveč redna vzdrževalna odgovornost. S pravilnim pristopom k testiranju lahko odkrijete ranljive vnose in trajno rešitev s poizvedbami s parametri ter pravilnim avtoriziranjem. Med gostovanjem vaše strani na infrastrukturnem sistemu Hostragons upoštevajte posodobljeno gostovanje, SSL, varnostno kopiranje in varnostne plasti, kar povečuje dolgoživost. Če želite, lahko brez pritiska prodaje preučite rešitve Hostragons za gostovanje in varnost vaše obstoječe strani.