Ja ir kāda lieta, kas kibernoziedzniekiem patīk, tad tie ir dati. Nozagti dati ir ļoti vērtīgi nelegālos tirgos, un piekļuve privātām datu bāzēm var būt lielisks veids, kā ļaunprātīgiem dalībniekiem gūt peļņu no saviem pasākumiem. Viens veids, kā piekļūt privātiem datiem, ir SQL injekcija. Bet kas īsti ir SQL injekcija, kā tā darbojas un vai šādu uzbrukumu var novērst?
Kas ir SQL injekcija?
Programmatūras darbības ir atkarīgas no koda. Kods ir arī valoda, ko mašīnas izmanto darbību veikšanai, un tam var būt daudz veidu (Python, JavaScript, C++ utt.). Bieži vien kibernoziedznieki var uzbrukt upuriem, izmantojot kodu, un SQL injekcijas (vai SQLis) neatšķiras. Tie ļauj ļaunprātīgiem dalībniekiem "injicēt" kaitīgu kodu SQL priekšrakstā.
Vispirms apskatīsim, ko nozīmē SQL.
SQL apzīmē strukturēto vaicājumu valodu. Šī ir cita veida programmēšanas valoda īpaši izmanto, strādājot ar datu bāzēm. SQL, ko 1970. gados izstrādāja IBM, var manipulēt, uzglabāt un izgūt datu bāzes informāciju. Daudzas datu bāzu sakaru sistēmas visā pasaulē izmanto SQL, tāpēc nav pārsteigums, ka draudu dalībnieki ir izstrādājuši veidus, kā to ļaunprātīgi izmantot, lai mērķētu uz datubāzēm.
SQL priekšraksti ir datu bāzes komunikācijas galvenā sastāvdaļa. SQL priekšraksts ir komanda kam ir daudz dažādu formu. Daži maina datus, daži tos izgūst vai dzēš, un daži var mainīt pašas datu bāzes struktūru. Kad notiek SQL injekcija, ļaunprātīgais kods tiek ievadīts SQL priekšrakstā.
Protams, vietnei vai lietojumprogrammai ir jāizmanto SQL programmēšanas valoda, lai būtu iespējama SQL injekcija. Bet kā darbojas šis uzbrukuma vektors?
Pieņemsim, ka jums ir parasta koda rindiņa, ko izmanto lietojumprogramma. Kad kibernoziedznieks ievieto ļaunprātīgu SQL injekciju, tiek pievienota koda rinda, kas var traucēt vaicājumiem, ko pati lietojumprogramma sūta savai datubāzei. To darot, datu bāzi var izmantot tādā veidā, kas ļauj apdraudējuma dalībniekam skatīt datus, kuriem citādi nebūtu piekļuves.
No šejienes kibernoziedznieks varētu nozagt datus, lai tos izmantotu tieši vai pārdod to tumšajā tīmeklī vai citur. Tie var arī mainīt, pievienot vai dzēst datus no mērķa datu bāzes. Atkarībā no SQL injekcijas uzbrukuma pakāpes var tikt nodarīts liels kaitējums. Ja tiek piekļūta maksājumu informācijai, sociālās apdrošināšanas numuriem vai cita veida privātiem datiem, daudzi cilvēki var tikt pakļauti ekspluatācijas riskam.
No otras puses, ja uzbrucējam izdodas būtiski mainīt datu bāzi, var tikt neatgriezeniski zaudēts liels datu apjoms. Kopumā SQL injekcijas var iznīcināt veselas datu bāzes tikai ar vienu uzbrukumu. Lai gan tie pastāv kopš 1998. gada, tie joprojām ir aktuāli un bīstami arī mūsdienās.
Kā atklājis Open Web Application Security Project (OWASP)2021. gadā, pārbaudot lietojumprogrammas šāda uzbrukuma esamībai, tika identificēti 274 000 SQL injekciju gadījumu.
SQL injekcijas veidi
Ir daži dažādi SQL ievadīšanas veidi, no kuriem galvenie trīs ir aklās, joslā un ārpusjoslas injekcijas.
Akla (vai secināma) SQL injekcija notiek, ja lietojumprogrammai vai vietnei uzbrūk injekcija, bet sniegtajās HTTP (hiperteksta pārsūtīšanas protokola) atbildēs nav ietverts rezultāts SQL vaicājums. Citiem vārdiem sakot, kibernoziedzniekam netiek nodoti dati no datubāzes, kurai tika uzbrukts. Tātad, kāda jēga no tā?
Izmantojot aklu SQL injekciju, uzbrucējs nosūta datus uz mērķa serveri un pēc tam var noteikt noteiktas lietas par datu bāzi, izmantojot pašu HTTP atbildes raksturu. Turklāt ar HTTP atbildi saistītie faktori var palīdzēt uzbrucējam izveidot citu, efektīvāku SQL injekciju, lai piekļūtu datubāzei.
Ir divi galvenie aklās SQL injekcijas veidi, kas pazīstami kā laika un Būla ievadīšana. Šie divi varianti pēc savas būtības ir diezgan līdzīgi. Gan Būla, gan uz laiku balstīta SQL injekcija nosūta masīvu ar jā vai nē atbilžu jautājumiem, lai gan pēdējam datu bāzei būs īss brīdis jāgaida, pirms atbild uz vaicājumiem.
Tālāk ir joslas SQL injekcijas. In-band SQL injekcijas ļauj operatoram veikt uzbrukumu un iegūt vēlamo rezultātu, izmantojot to pašu kanālu. Visbiežāk tiek izmantotas joslas SQL injekcijas, jo tās ir visvieglāk izpildāmas, jo tām ir nepieciešams tikai viens kanāls.
Visbeidzot, jums ir ārpusjoslas SQL injekcija. Šī būtībā ir alternatīva joslas SQL injekcijas versija, kurā uzbrucējs nevar veikt uzbrukumu kopumā, izmantojot vienu kanālu. Alternatīvi, uzbrukumam var būt nepieciešams izmantot ārpusjoslas SQL injekciju, ja mērķa serveris vienkārši nav pietiekami ātrs, lai nodrošinātu rezultātus.
Šie faktori padara procesu nedaudz sarežģītāku, tas nozīmē, ka tam ir jāpaļaujas uz noteiktām funkcijām, lai mērķētā datubāzē būtu aktīvi, lai gūtu panākumus. Piemēram, platformai, kurai tiek uzbrukts, ir jābūt ieejas sanitārijas trūkumam. Šī iemesla dēļ joslas SQL injekcijas ir daudz izplatītākas nekā ārpusjoslas SQL injekcijas. Bet tie joprojām notiek.
Vai var izvairīties no SQL injekcijām?
SQL injekcijas vairāk uztrauc uzņēmumus un organizācijas, nevis parastās personas. Taču ir lietas, ko šie potenciālie mērķi var darīt, lai samazinātu iespēju tikt trāpītiem no šāda uzbrukuma.
Ievades tīrīšana ir galvenā izplatītā prakse, lai izvairītos no SQL injekcijas. Šis ir filtrēšanas process, kas skenē un attīra ievadi no bīstamām rakstzīmēm. Ja SQL kods tiek apstrādāts pirms tīrīšanas, SQL injekcijas iespēja, protams, palielināsies.
Turklāt parametrizētie vaicājumi var palīdzēt izvairīties no SQL injekcijām. Tie ir vaicājumi, kuru izpildei nepieciešams vismaz viens parametrs. Parametru piemērošana apgrūtina kibernoziedznieku veiksmīgu SQL injekcijas uzbrukumu veikšanu.
Taču nav droša veida, kā novērst SQL ievadīšanu. Tāpat kā daudzu kiberuzbrukumu gadījumā, ir gandrīz neiespējami nodrošināt, lai jūsu ierīces un sistēmas būtu pilnībā hermētiskas. Runājot par SQL injekcijām, labākais, ko varat darīt, ir sanitizēt visas ievades un izveidot parametrizētus vaicājumus.
SQL injekcijas ir novecojušas, taču joprojām ir drauds
Lai gan SQL injekcijas pastāv jau vairāk nekā 20 gadus, tās joprojām rada risku daudzām vietnēm un lietojumprogrammām. Tāpēc ir ieteicams paturēt prātā šo uzbrukuma veidu un veikt nepieciešamās darbības, lai mēģinātu to novērst, jo nākotnē tas var apdraudēt jūsu datubāzes.
