SQL-i süstimise mõju
SQL-i süstimine (SQLi) võimaldab ründajal sekkuda päringutesse, mida rakendus oma andmebaasi [S1] teeb. Peamine mõju hõlmab volitamata juurdepääsu tundlikele andmetele, nagu kasutaja paroolid, krediitkaardi andmed ja isiklikud andmed. [S1].
Lisaks andmete vargustele võivad ründajad sageli andmebaasikirjeid muuta või kustutada, mis põhjustab püsivaid muutusi rakenduse käitumises või andmete kadumist. [S1]. Rasketel juhtudel saab SQLi-d eskaleerida, et ohustada taustainfrastruktuuri, võimaldada teenuse keelamise rünnakuid või pakkuda püsivat tagaukse organisatsiooni süsteemidesse [S1][S2].
Algpõhjus: ebaturvaline sisendi käsitlemine
SQL-i sisestamise algpõhjus on SQL-i käsus [S2] kasutatud erielementide vale neutraliseerimine. See juhtub siis, kui rakendus koostab SQL-päringuid, ühendades välise mõjuga sisendi otse päringustringi [S1][S2].
Kuna sisend ei ole päringustruktuurist korralikult eraldatud, võib andmebaasi interpretaator käivitada osa kasutaja sisendist SQL-koodina, mitte käsitleda seda sõnasõnaliste andmetena [S2]. See haavatavus võib avalduda päringu erinevates osades, sealhulgas SELECT avaldustes, INSERT väärtustes või UPDATE lausetes [S1].
Betooniparandused ja leevendused
Kasutage parameetritega päringuid
Kõige tõhusam viis SQL-i süstimise vältimiseks on parameetritega päringute kasutamine, mida nimetatakse ka ettevalmistatud avaldusteks [S1]. Stringide ühendamise asemel peaksid arendajad kasutama struktureeritud mehhanisme, mis jõustavad andmete ja koodi [S2] eraldamise.
Väikseima privileegi põhimõte
Rakendused peaksid ühenduma andmebaasiga, kasutades nende ülesannete täitmiseks vajalikke madalaimaid õigusi [S2]. Veebirakenduse kontol ei tohiks olla administraatoriõigusi ja see peaks piirduma konkreetsete tabelite või toimingutega, mis on selle funktsiooni jaoks vajalikud [S2].
Sisestuse kontrollimine ja kodeerimine
Kuigi sisendi valideerimine ei asenda parameetrite määramist, pakub see [S2] põhjalikku kaitset. Rakendused peaksid kasutama tunnustatud-hea strateegiat, kinnitades, et sisend vastab eeldatavatele tüüpidele, pikkustele ja vormingutele [S2].
Kuidas FixVibe seda testib
FixVibe hõlmab juba SQL-i sisestamist läbi väravaga skannerimooduli active.sqli. Aktiivsed kontrollid käivituvad alles pärast domeeni omandiõiguse kinnitamist ja kinnitamist. Kontroll roomab päringuparameetritega sama päritoluga GET-i lõpp-punktides, loob lähtereaktsiooni, otsib SQL-spetsiifilisi tõeväärtuse kõrvalekaldeid ja teatab leiust alles pärast mitme viivituspikkuse ajastuse kinnitamist. Hoidla kontrollimine aitab ka algpõhjuse varem tuvastada, kasutades code.web-app-risk-checklist-backfill, mis märgib mallide interpoleerimisega loodud töötlemata SQL-i kõned.