Home Arrow Icon Knowledge base Arrow Icon Global Arrow Icon Kokie yra dažniausi „Laravel“ programų saugumo pažeidžiamumas


Kokie yra dažniausi „Laravel“ programų saugumo pažeidžiamumas


Labiausiai paplitę „Laravel“ programų saugumo pažeidžiamumas apima įvairias grėsmes, būdingas žiniatinklio programoms, atsižvelgiant į konkrečius aspektus, susijusius su „Laravel“ architektūra ir funkcijomis. Žemiau yra išsamus šių pažeidžiamumų paaiškinimas, rekomendacijos ir praktika jas sušvelninti.

SQL injekcija
SQL injekcija įvyksta tada, kai vartotojo įvestis įtraukiami į duomenų bazės užklausas be tinkamos sanitarijos ar parametrų nustatymo, leisdami užpuolikams manipuliuoti užklausomis, kad būtų galima patekti ar keisti duomenis kenksmingai. „Laravel“ šią riziką efektyviai sušvelnina, naudodama iškalbingą ORM ir užklausų kūrimą, kuri pagal numatytuosius nustatymus taiko parametrizuotas užklausas. Tačiau netinkamai naudojant neapdorotas užklausas, pavyzdžiui, sujungti vartotojo įvestis tiesiai į SQL komandas be įrišimo, gali būti atskleista SQL injekcija. Norėdami užkirsti kelią SQL injekcijai, visada naudokite „Laravel“ parametrų surišimo galimybes ir venkite vartotojo įvesties sujungimo į neapdorotas užklausas.

Scenarijus skersai (XSS)
XSS pažeidžiamumas atsiranda, kai užpuolikai įbrėžia kenkėjiškus scenarijus į tinklalapius, kuriuos žiūri kiti vartotojai. Tai gali sukelti sesijos užgrobimą, panieką ar nukreipti vartotojus į kenksmingus svetaines. „Laravel“ ašmenų šablonų variklis išeikvoja išėjimus pagal numatytuosius nustatymus, naudojant dvigubų garbanotų petnešų sintaksę, o tai žymiai sumažina XSS riziką. Kūrėjai turi vengti naudoti `{!! !!} `sintaksė nepatikimam turiniui be tinkamos sanitarijos. Be to, norint sumažinti atakos paviršių, susijusį su XSS, labai svarbu patvirtinti ir dezaktyvuoti visą vartotojo įvestį.

Kryžminės užklausų užklausa (CSRF)
CSRF užpuola autentifikuotus vartotojus, kad vartotojai pateiktų kenkėjiškų užklausų žiniatinklio programai, todėl reikia atlikti nenumatytus veiksmus. „Laravel“ turi įmontuotą CSRF apsaugą, kuri apima kiekvienos aktyvios vartotojo sesijos ženklo generavimą. Kūrėjai privalo užtikrinti, kad formose būtų šis prieigos raktas per „@csrf“ direktyvą arba „csrf_field“ () „pagalbininko funkciją“. API turėtų patikrinti CSRF žetonus, kad gautų valstybės keičiančias užklausas, kad būtų išvengta neteisėtų veiksmų per suklastotas užklausas.

Masinių užduočių pažeidžiamumas
Masinis priskyrimas įvyksta, kai užpuolikas manipuliuoja modelio savybėmis, įtraukdamas netikėtus parametrus į užklausos naudingą apkrovą, dėl ko neteisėtai pakeitė jautrius atributus, tokius kaip vartotojo vaidmenys ar leidimai. „Laravel“ siūlo „$ užpildomus“ ir „$ saugomus“ savybes modeliams, skirtais apibrėžti, kurie atributai yra priskiriami masinei priskyrimui. Tinkamai naudojant šias savybes apsaugo nuo kritinių laukų, tokių kaip „IS_Admin“, nesiseka neteisėti vartotojai. Venkite apeiti šias apsaugos priemones tokiais metodais, kaip „forffill“ arba „futmocreate“, nebent būtina ir saugu.

Nesaugus autentifikavimas
Silpni autentifikavimo mechanizmai kelia „Laravel“ programas, kurioms gresia žiaurios jėgos priepuoliai, sesijos užgrobimas ir įgaliojimų įdaras. Naudojant įmontuotą „Laravel“ autentifikavimo sistemą, užtikrinama saugus slaptažodžio maišas per „BCrypt“ pagal numatytuosius nustatymus. Papildomos apsaugos priemonės apima greičio apribojimą prisijungimo maršrutuose, naudojant „Laravel“ droselio tarpinę programinę įrangą, įgalinant daugiafaktoriaus autentifikavimą (2FA) ir naudojant trumpalaikius žetonus su atnaujinimo galimybėmis API autentifikacijoje, kad būtų galima apriboti netinkamą žetonų naudojimą.

Nesaugūs failų įkėlimai
Failų įkėlimo pažeidžiamumai gali leisti užpuolikams įkelti kenksmingus scenarijus ar failus, kuriuos galima vykdyti serveryje. Prieš apdorodami įkėlimus, „Laravel“ kūrėjai turi griežtai patvirtinti failų tipus ir dydžius, pavyzdžiui, apribodami konkrečius MIME tipus (`JPG“, „PNG“, „PDF“ ir kt.) Ir dydžio ribas. Įkelti failai turėtų būti laikomi ne žiniatinklio šaknyje arba saugiai valdomi, naudojant „Laravel“ saugyklos fasadą, kad būtų galima apriboti tiesioginę interneto prieigą. Tai sumažina savavališko kodo vykdymo riziką ir neteisėtą prieigą prie failų.

Neužtikrinti API galiniai taškai
API gali atskleisti jautrią funkcionalumą ar duomenis, jei galiniai taškai nėra tinkamai patvirtinti ar leidžiami. „Laravel“ teikia patikimus API saugumo įrankius, įskaitant „Laravel Passport“ ir „Sanctum“, kad būtų galima saugiai valdyti autentifikavimą ir leidimą. Įvertinkite API užklausas ir patvirtinant vartotojo leidimus kiekvienoje užklausoje, sumažinama piktnaudžiavimo rizika arba duomenų nutekėjimas per API.

Neskelbtini duomenų ekspozicija
Seliesųjų duomenų atskleidimas klaidų pranešimais, žurnalais ar URL parametrais yra įprasta saugumo trūkumas. „Laravel“ programos turėtų išjungti derinimo informaciją gamybos aplinkoje, nustatydami failą „App_debug = false“. Neskelbtina informacija, pavyzdžiui, slaptažodžiai ar žetonai, turi būti užšifruota tiek tranzito metu (naudojant HTTPS), tiek poilsiui, pasinaudojant „Laravel“ kriptos fasadu. Aplinkos kintamieji ir jautrūs konfigūracijos failai niekada neturėtų būti įsipareigoję versijų valdymo saugykloms. Be to, venkite registravimo neskelbtinų duomenų, tokių kaip kreditinės kortelės numeriai ar slaptažodžiai.

Nesaugūs užsiėmimai ir slapukai
Netinkamas sesijos valdymas gali sukelti sesijų užgrobimą ar fiksavimo atakas. „Laravel“ palaiko saugius, tik HTTP slapukus, skirtus sesijoms saugoti, įgalinant „session_secure_cookie = true“ gamybos aplinkoje. Regeneruojant sesijos ID prisijungus, pagerina saugumą, užkertant kelią seanso fiksavimui. Sesijose turėtų būti naudojamas šifravimas, o jautrūs slapukai turėtų turėti „saugus“ ir „httponly“ vėliavas, skirtas apsaugoti jas nuo perėmimo ir scenarijų.

Neribotas URL nukreipia
Atidaryti peradresavimai atsiranda, kai programa nukreipia vartotojus į išorinius URL, pagrįstus neįvertintu vartotojo įvestimi. Užpuoliai gali tai panaudoti nukreipti vartotojus į kenksmingus svetaines, palengvindami sukčiavimo apsimetimo atakas. „Laravel“ peradresavimas ()-> numatytas () `metodas padeda tai sušvelninti, užtikrinant, kad peradresavimas įvyks tik į vidinius, numatytus URL. Kūrėjai visada turėtų patvirtinti peradresavimo URL ir vengti savavališko peradresavimo į išorinius domenus, nebent tai būtų aiškiai reikalinga ir saugiai kontroliuojami.

Nepakankamas įvesties patvirtinimas
Nepavykus patvirtinti ar dezinfekuoti vartotojo įvesties, daugelį programų dalių gali būti parodyta injekcija ir neteisėti veiksmai. „Laravel“ įmontuoti patvirtinimo mechanizmai visada turėtų būti naudojami serverio pusėje, net jei kliento patvirtinimas yra vietoje. Naudojant patvirtinimo taisykles, užtikrinama, kad duomenys atitinka numatomus formatus ir tipus, užkertant kelią atakoms, tokioms kaip SQL injekcija ar XSS. Įvestis niekada neturėtų būti aklai pasitikima, ypač dirbant su masinėmis priskyrimais ar neapdorotomis užklausomis.

Nesaugus priklausomybės valdymas
„Laravel“ programos priklauso nuo trečiųjų šalių paketų ir priklausomybių, kurios gali sukelti pažeidžiamumus, jei nebus tinkamai valdomos. Saugumui labai svarbu išlaikyti „Laravel“, PHP ir visas priklausomybes. Kūrėjai turėtų naudoti kompozitorių, kad valdytų priklausomybes ir vykdyti saugos auditą, naudodamiesi tokiais įrankiais kaip „Kompozitoriaus auditas“, kad nustatytų pažeidžiamus paketus. Reikėtų naudoti tik patikimus paketus, o priklausomybės turėtų būti pritvirtintos prie konkrečių saugių versijų, kad netyčia išvengtumėte naujos rizikos.

Nesaugios tiesioginės objekto nuorodos (IDOR)
IDOR pažeidžiamumas leidžia užpuolikams manipuliuoti nuorodomis į vidinius objektus, tokius kaip duomenų bazės ID, norint pasiekti ar modifikuoti neteisėtus duomenis. „Laravel“ kūrėjai turėtų įgyvendinti griežtą autorizacijos politiką, naudodami „Laravel“ politikos klases ir tarpinę programinę įrangą, kad patikrintų vartotojo leidimus prieš suteikdami prieigą prie neskelbtinų išteklių. Netiesioginės nuorodos, tokios kaip maišos ar UUID, o ne duomenų bazės ID, taip pat gali sumažinti riziką. Maršruto modelio įrišimas kartu su autorizacijos patikrinimais padeda išvengti tiesioginio objekto nuorodos išnaudojimo.

Kelias važiuoja
„Pathal Traversal“ atakos apima failų kelio įvestis manipuliavimu, kad būtų galima pasiekti failus už numatytų katalogų ribų, potencialiai atskleidžiant neskelbtinus sistemos failus. „Laravel“ programų tvarkymas Failų atsisiuntimai turėtų dezinfekuoti failų kelio įvestis, naudojant PHP funkcijas, tokias kaip `basename ()`, kad būtų galima pašalinti katalogų apvažiavimo sekas (`../`). Venkite vartotojo įvesties tiesiogiai, kad būtų galima tiesiogiai failų keliams ir griežtai patvirtinkite failų pavadinimus, kad būtų išvengta neteisėtos prieigos failo.

Netinkamas klaidų tvarkymas
Išsamių klaidų pranešimų ar krūvos pėdsakų ekspozicija galutiniams vartotojams gali nutekėti jautrią sistemą ir padėti užpuolikams išnaudoti pažeidžiamumus. „Laravel“ klaidų tvarkymas turėtų būti sukonfigūruotas taip, kad būtų rodomos išsamios klaidos tik gamybos aplinkoje. Vartotojai turėtų pamatyti bendrus klaidų pranešimus, o išsamius žurnalus turėtų būti apriboti serverio failai, kuriuos galima rasti tik administratoriai.

Šifravimo trūkumas
Duomenys, perduodami ar saugomi be šifravimo, gali būti perimti ar pasiekti neteisėtų šalių. „Laravel“ palaiko HTTP per tarpinę programinę įrangą ir serverio konfigūraciją saugiai perduoti duomenis. Neskelbtini duomenys, saugomi duomenų bazėse ar failuose, turėtų būti užšifruoti naudojant „Laravel“ kriptos fasadą ar kitus pramonės standartinius šifravimo metodus, kad apsaugotų konfidencialumą.

Nesaugus kryžminio kilmės išteklių dalijimasis (CORS)
Netinkama CORS antraščių konfigūracija gali atskleisti API nepageidaujamas kryžminio kilmės užklausas, dėl kurių duomenų nutekėjimas ar neteisėti veiksmai. „Laravel“ teikia tarpinę programinę įrangą CORS politikai sukonfigūruoti, kuri turi būti nustatyta taip, kad būtų galima apriboti leistiną kilmę, metodus ir antraštes, atsižvelgiant į taikymo poreikius, o ne leisti visas kilmes beatodairiškai.

Apsaugos klaidingas konfigūracijos
Numatytasis ar netinkamas „Laravel“ konfigūracijos parametrai gali sukelti pažeidžiamumą. Pavyzdžiai yra įjungimas derinimo režime gamyboje, numatytosios duomenų bazės kredencialai arba netinkami failų leidimai. Norint užtikrinti saugią konfigūraciją, būtina reguliarus „.env“ konfigūracijos parametrų, failų leidimų ir serverio aplinkos peržiūra ir peržiūra.

Brutalios jėgos išpuoliai
Neautentifikuotus galinius taškus ar silpnąsias prisijungimo sistemas galima išnaudoti brutalios jėgos bandymais atspėti kredencialus. „Laravel“ įmontuota droselio tarpinė programinė įranga riboja prisijungimo bandymų skaičių iš vieno IP ar paskyros, sumažindamas žiaurios jėgos atakų riziką. Sąskaitos lokauto politikos įgyvendinimas ir „Captchas“ naudojimas jautriomis formomis gali dar labiau sustiprinti gynybą.

Nepakankamas registravimas ir stebėjimas
Nepavyko registruoti saugiai susijusių įvykių ar stebėti įtartinos veiklos žurnalus, trukdančius aptikti ir reaguoti į juos. „Laravel“ palaiko tvirtą registravimo infrastruktūrą, kurią galima sukonfigūruoti taip, kad registruotų autentifikavimo gedimus, vartotojo leidimų pakeitimus ir kitus neskelbtinus veiksmus. Integruojant „Laravel“ žurnalus su stebėjimo ir įspėjimo sistemomis, galima laiku reaguoti į įvykius.

Apibendrinant galima pasakyti, kad „Laravel“ programos, aprūpintos daugybe įmontuotų saugumo funkcijų, išlieka pažeidžiamos, jei nepaisoma bendro saugumo praktikos. Norint apsisaugoti nuo labiausiai paplitusių pažeidžiamumų, būtinas tinkamas įvesties patvirtinimas, saugus autentifikavimas, saugus vartotojo duomenų tvarkymas, kruopštus konfigūracija ir priklausomybės valdymas. Kūrėjai turėtų pasitelkti „Laravel“ vietinius saugumo mechanizmus ir laikytis saugios kodavimo praktikos, kad sukurtų atsparias programas, kurios apsaugo neskelbtinus duomenis ir išlaikytų vartotojo pasitikėjimą.

Šie pažeidžiamumai ir sprendimai yra plačiai dokumentuoti ir sudaro pagrindines „Laravel“ plėtros saugumo žinias.