Pavasara atlaide –€10 visiem moduļu kursiem Apskatīt →
Programmas Mācību ceļš Sertifikācija Dibinātājs Uzņēmumiem Simulatori Blogs
← Atpakaļ uz blogu
Blogs

SQL injekcija (SQLi) iesācējiem — kā uzbrucēji apiet autentifikāciju

2026. gada 18. marts · 3 min lasīšana · Madars Balodis

Iedomājies sistēmu kā seifu ar dubulto atslēgu — tev vajag gan e-pastu, gan paroli, lai to atvērtu. Bet kas notiek, ja atslēgas caurumā var iebāzt nevis atslēgu, bet instrukciju, kas liek seifam ignorēt paroli un atvērties jebkurā gadījumā?

Tieši tā strādā SQL injekcija (SQLi). Tā ir ievainojamība, kurā uzbrucējs izmanto datu ievades laukus (kā pieteikšanās formu), lai nosūtītu komandas pa tiešo uz datubāzi.

Šajā rakstā aplūkosim klasisko autentifikācijas apiešanu (authentication bypass) un to, kāpēc moderna kodēšana no tās mūs pasargā.

Kas ir SQL?

Vairums tīmekļa lapu (interneta veikali, forumi, sociālie tīkli) savus datus glabā relāciju datubāzēs, piemēram, MySQL, PostgreSQL vai SQL Server. Serveri komunicē ar šīm datubāzēm, izmantojot SQL (Structured Query Language) valodu.

Kad tu ievadi savu e-pastu un paroli pieteikšanās formā, serveris izpilda aptuveni šādu vaicājumu:

SELECT * FROM users WHERE email = 'tavs_epasts' AND password = 'tava_parole';

Serveris saka datubāzei: “Apskaties, vai tabulā users eksistē kāds lietotājs, kuram sakrīt gan e-pasts, gan parole. Ja ir — ielaid viņu!”

Ja e-pasts vai parole ir nepareiza, datubāze atbild ar nulli rezultātiem, un serveris parāda kļūdu: “Nepareizs e-pasts vai parole.”

Kā notiek SQL injekcija?

Problēma rodas tad, kad serveris paņem tavu ievadīto tekstu un akli salīmē to kopā ar savu komandu (string concatenation), neveicot nekādu filtrēšanu.

Kāds izskatīsies SQL vaicājums, ja e-pasta laukā mēs ievadīsim ko šādu? admin@epasts.lv' OR 1=1 --

Apskatīsim, kas notiek, kad serveris ieliek mūsu ievadi savā kodā:

-- Oriģinālais, paredzētais pieprasījums serverī
SELECT * FROM users WHERE email = 'IEVADE' AND password = 'tava_parole';

-- Servera pieprasījums ar mūsu ĻAUNPRĀTĪGO ievadi e-pasta laukā:
SELECT * FROM users WHERE email = 'admin@epasts.lv' OR 1=1 --' AND password = 'tava_parole';

Sadalo šo teikumu daļās, mēs redzam uzbrucēja ģenialitāti:

  1. Pirmā pēdiņa ' pēc .lv aizver e-pasta stringu.
  2. OR pievieno alternatīvu nosacījumu.
  3. 1=1 vienmēr ir PATIESA (TRUE) paziņojums. Viens vienmēr ir vienāds ar viens.
  4. -- divas svītriņas MySQL un citās SQL datubāzēs apzīmē komentāra sākumu. Datubāze pilnībā ignorē visu, kas seko pēc tām (šajā gadījumā — paroles pārbaudi).

Patiesībā datubāze tagad izlasa šo: “Apskaties lietotāju tabulu. Vai e-pasts ir admin, VAI 1 ir vienāds ar 1? Lieliski, 1 ir vienāds ar 1! Paroli pat nepārbadi.”

Tā kā 1=1 vienmēr izpildās veiksmīgi, datubāze atgriež pirmo lietotāju tabulā (parasti tas ir administrators, kam ir ID=1), un uzbrucējs ir iekšā sistēmā. Bez paroles.

Pamēģini Pats! (Legāli un droši)

Lai saprastu, kā tas strādā “dzīvajā”, mēs esam pievienojuši jaunu SQLi interaktīvo simulatoru.

Ieej mūsu simulatorā un:

  1. Mēģini reģistrēties kā parasts lietotājs un aplūko, kā backend serveris veido vaicājumus aizkulisēs.
  2. Ievadi pēdiņu ' un vēro, kā datubāze “salūzt”, rādot sintakses kļūdu.
  3. Veic klasisko ' OR 1=1 -- injekciju un apiet formālo admin paneli!

Tas notiek tieši tavā pārlūkprogrammmā — absolūti drošā vidē bez riska ko sabojāt.

Aizsardzība: Kā mēs sevi pasargājam?

Agrāk šāda ievainojamība mājoja gandrīz katrā trešajā vietnē. Šodien klasiskā SQLi ir retāk sastopama modernās aplikācijās, bet tā joprojām ir biežākā kļūda vecākās (legacy) sistēmās vai mājasdarbos.

Kā to salabot? Nekad nelīmē lietotāja ievadi tieši SQL vaicājumā!

Standarta aizsardzība ir Sagatavotie pieprasījumi (Prepared Statements / Parameterized Queries).

Izmantojot Prepared Statements, serveris vispirms nosūta datubāzei SQL koda struktūru, atstājot tukšas vietas parametriem. Datubāze nokompilē šo komandu. Tikai pēc tam serveris nosūta parametrus (lietotāja e-pastu un paroli).

Izmantojot šo pieeju, ja uzbrucējs nosūta ' OR 1=1 --, datubāze to neiztulko kā SQL komandu. Tā vienkārši meklē lietotāju, kura e-pasta adrese burtiski ir "admin@epasts.lv' OR 1=1 --". Šāds lietotājs, protams, neeksistē, un uzbrukums izgāžas.

Gandrīz visi mūsdienīgie ORM (Prisma, Drizzle, Eloquent, Hibernate) to izmanto automātiski visos vaicājumos!

Likumība (Kā vienmēr)

Tāpat kā skenējot serverus ar Nikto, mēģināt SQL injekcijas dzīvās vietnēs, kurām tu neesi īpašnieks (vai kurām neesi saņēmis rakstisku atļauju) ir krimināli sodāms pārkāpums. Tā ir tieša uzlaušana. Vienmēr trenējies tam paradzētos simulatoros, laboratorijās vai legālā “Bug Bounty” formātā.

Vēlies iemācīties vēl vairāk par to kā web aplikācijas tiek uzbruktas un aizsargātas? Apskati mūsu Kiberdrošības Speciālista kursu, kur tu mācīsies visu to — savām rokām reālās laboratorijās.

SQLiweb drošībaiesācējiemievainojamības