SQL un PL/SQL injekcijas

Moto:
‘Why, what can be worse than cutting our throats?’ she asked, with pretty, naive surprise.
‘Cutting our purses,’ he answered. ‘Man is so made these days that his capacity for living is determined by the money he possesses.’
– Kā, kas tad var būt vēl ļaunāk kā laupīt mums dzīvību? – viņa jautāja diezgan naivā pārsteigumā.
– Nolaupīt mūsu makus, – viņš atbildēja. – Mūsu dienās cilvēks ir izveidojies tā, ka viņa spēju dzīvot nosaka nauda, kas viņam pieder.
The Sea-Wolf, Jack London.

Neba nu tā, ka es šim citātam pilnīgi piekristu, vēl jo vairāk tāpēc, ka Vilks Larsens ar savu filozofiju diezgan slikti beidza (starp citu saistošs stāsts, iesaku izlasīt). Taču savi maki (dati) ir jāaizsargā, jo citādi kāds tos atnāks un paņems tādā vai citādā veidā. Viens no veidiem, kā makus atstāt vaļā, ir atstāt caurumu, lai Jūsu aplikācijās varētu veikt SQL injekcijas.

Šis raksts galvenokārt ir domāts programmētājiem, kas raksta kodu, nevis lauzējiem, kas cenšas to uzlauzt. Šajā rakstā esošos piemērus bez īpašas piepūles var atrast simtiem vietās internetā, tāpēc nevajadzētu uzskatīt šo par iedrošinājumu “sliktajiem“, bet par aicinājumu “labajiem” neatstāt durvis puspievērtas, ja mājā iekšā vērtīgas lietas.

Visi turpmākie piemēri būs balstīti tikai uz Oracle SQL un PL/SQL. Tai pašā laikā šai rakstā demonstrētās tehnikas nebūt nav ierobežotas tikai ar šo konkrēto SQL implementāciju un programmēšanas valodu.

Kas tas ir?

SQL injekcijas rezultātā datubāzē tiek izpildīts pavisam cits SQL teikums, nevis tas, kas sākotnēji domāts. Tas var būt gan datu atlases (SELECT) gadījumā, gan arī, piemēram, datu koriģēšanas (UPDATE) gadījumā. Parasti “cits” nozīmē vai nu sensitīvu datu iegūšanu (SELECT gadījumā), vai nesankcionētu datu koriģēšanu, vai arī nesankcionētu tiesību piekļuves iegūšanu.

Kad tas notiek?

Parastākais un izplatītākais gadījums ir tad, kad programmētājs neuzmanīgi veido SQL vaicājumu un konkatenē to kopā kā tekstu. Līdz ar to potenciāli ir apdraudēts jebkurš koda gabals jebkurā programmēšanas valodā, kurā programmētājs “lipina” kopā SQL teikumus kā teksta virknes.

SQL injekcija Select vaicājumā nesankcionētai datu ieguvei

Visiem turpmākajiem piemēriem mēs lietosim šādas 2 tabulas,  kas simbolizēs visiem pieejamo informāciju un slepeno informāciju.

CREATE TABLE publiska (
  id NUMBER,
  dati VARCHAR2(100));
CREATE TABLE slepena (
  id NUMBER,
  dati VARCHAR2(100));
INSERT INTO publiska VALUES (1, 'publiska info');
INSERT INTO slepena VALUES (1, 'slepena info');
commit;

Refkursori ir ērts un parocīgs veids, kā no Oracle atdot datus izsaucošajai videi. Lai tā būtu .NET, PHP vai jebkas cits. Protams, ja to dara nekorekti, tad var iedzīvoties pamatīgās nepatikšanās. Skatamies piemēru, ko var pilnībā izpildīt no SQL*Plusa, bet tikpat labi izsaukums var tikt veikts no jebkuras citas vides.

Piemērs 1. Ievainojamas SQL funkcijas izveides piemērs.

CREATE OR REPLACE FUNCTION f_slikta (
  in_filtrs IN VARCHAR2)
RETURN sys_refcursor IS
  rcur sys_refcursor;
BEGIN
  OPEN rcur FOR 'SELECT *
                 FROM publiska
                 WHERE dati LIKE ''' || in_filtrs || '''';
  RETURN rcur;
END;
/

Piemērs 2. Ievainojamās SQL funkcijas sākotnēji paredzētais izsaukums.

SQL> variable cv refcursor
SQL> exec :cv := f_slikta('pub%')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ---------------
         1 publiska info

Viss kārtībā, vai ne? Dabūjām apmēram to, ko vēlējāmies? Taču paskatamies, kas notiek ar speciālu virkni.

Piemērs 3. Ievainojamās SQL funkcijas izsaukums izmantojot speciālu virkni – SQL injekcija.

SQL> exec :cv := f_slikta(''' UNION ALL SELECT * FROM slepena -- ')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- -------------
         1 slepena info

Slepenā info vairs nav nekāds noslēpums! Kā tad tas notika? Tātad ir vairākas lietas, kas nepieciešamas:

• tiekam vaļā no iepriekšējā vaicājuma rezultāta vienkārši LIKE salīdzināšanas mainīgā vietā padodot 3 apostrofus, kas SQL teikumā pārvērtīsies par vienu un gala rezultātā iegūstam šādu salīdzināšanu LIKE ” . Protams šis solis nebūt nav obligāts, galu galā jau publiskā info mūs arī briesmīgi netraucēja.
• Izmantojot kopas operatoru UNION ALL lasam datus no slepenās tabulas.
• Beigās izmantojam vienrindas komentāru, lai aizkomentētu pēdējo fiksēto apostrofu, kas ir ielikts funkcijas refcursora veidošanas izteiksmē.

Ja vēl joprojām nav skaidrs kā tas īsti notika, tad varam modificēt funkciju un izdrukāt (piemēram, izmantotojot dbms_output.put_line) ārā SQL teikumu. Tad mēs iegūtu šādu izpildīto SQL teikumu:

SELECT * FROM publiska
WHERE dati LIKE '' UNION ALL SELECT * FROM slepena -- '

Select vaicājums bez injekcijas iespējas

Redzam, ka ir slikti, ko darīt, lai būtu labāk? Atceramies, ka visa ļaunuma sakne slēpjas apstāklī, ka mums tika konkatenētas kopā teksta virknes, kur viena bija lietotāja iedotā. No tā var izvairīties lietojot bind mainīgos. Šajā gadījumā mainīgais tik tiešām būs tikai mainīgais, nevis kaut kāda teksta virkne, kuru lietotājs var uzdot kā vien vēlas un kas maina SQL teikuma jēgu un sākotnējo mērķi. Tātad veidojam labo funkciju.

Piemērs 4. NEIevainojamas SQL funkcijas izveides piemērs.

CREATE OR REPLACE FUNCTION f_laba (
  in_filtrs IN VARCHAR2)
RETURN sys_refcursor IS
  rcur sys_refcursor;
BEGIN
  OPEN rcur FOR 'SELECT *
                 FROM publiska
                 WHERE dati LIKE :y' USING in_filtrs;
  RETURN rcur;
END;
/

Skatamies, kas notiks ar iepriekšējiem izsaukumiem.

Piemērs 5. NEIevainojamās SQL funkcijas sākotnēji paredzētais izsaukums.

SQL> variable cv refcursor
SQL> exec :cv := f_laba('pub%')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ---------------
         1 publiska info

Kā redzams nekas vismaz šoreiz rezultātā nav mainījies.

Piemērs 6. NEIevainojamās SQL funkcijas izsaukums izmantojot speciālu virkni – SQL injekcijas mēģinājums.

SQL> exec :cv := f_laba(''' UNION ALL SELECT * FROM slepena -- ')
PL/SQL procedure successfully completed.
SQL> print cv
no rows selected

Nu re – nekas netika atrasts, kā jau sākumā bija cerēts. Pie tam šim variantam arī no ātradarbības viedokļa ir papildus bonusi – nelietojot bind mainīgos shared pool (atmiņas apgabals, kur tiek glabāti izpildītie SQL teikumi un to izpildes plāni) tiek pārpludināts ar ļoti līdzīgiem SQL teikumiem, kas atšķiras tikai par konstantes tiesu (t.i. katram mainīgajam savs SQL teikums). Ja lieto bind mainīgos, tad šādu problēmu nav.

Tātad redzam, ka pirmajā gadījumā tika atgriezts vēlamais rezultāts un arī otrajā gadījuma tika atgriezts vēlamais rezultāts, jo tikai un vienīgi tabulā publiska tika meklēta kaut kāda simbolu virkne, kura bija pagadījusies tāda diezgan speciāla un to nevarēja atrast.

SQL injekcija Select vaicājumā nesankcionētai jebkādai darbībai

Ja nu gadījumā Jūs iepriekšējais piemērs pilnībā nepārliecināja – sak mēs godīgi cilvēki, mums nav ko slēpt – tad paskatamies uz nākošo piemēru. Šeit lietotājs Zaglis jau ir iekļuvis sistēmā un viņam ir izveidots lietotāja konts. Atceramies, ka reālajā dzīvē tas var būt kāds no esošajiem noklusētajiem lietotājiem (scott, hr utt), kuram administrators nav nomainījis noklusēto paroli, vai arī parole ir bijusi pietiekami vienkārša un zaglis to ir uzminējis.

Piemērs 7. Zagļa mēģinājums nesankcionēti koriģēt datus.

SQL> create user zaglis identified by zaglis;
User created.
SQL> grant create procedure to zaglis;
Grant succeeded.
SQL> grant create session to zaglis;
Grant succeeded.
SQL> conn zaglis/zaglis
Connected.
SQL> INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS');
INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS')
                  *
ERROR at line 1:
ORA-00942: table or view does not exist

Tātad redzam, ka zaglis ir iekļuvis sistēmā un mēģina pievienot savu “parakstu”, bet viņam tas neizdodas, jo tiesību mehānisms to neļauj. Bet zaglis ir pietiekami gudrs, lai izveidotu savu speciālo funkciju (Savā shēmā!!!), kas viņam šīs tiesības iedos, un iedotu tiesības to izpildīt uzbrukuma mērķim.

Piemērs 8. SQL injekcijas funkcijas izveide un izpilde, kas dod nesankcionētas tiesības.

create or replace function dot_tiesibas return number
authid current_user is
  pragma autonomous_transaction;
begin
  execute immediate 'grant all on slepena to zaglis';
  return 1;
end;
/
SQL> grant execute on dot_tiesibas to gints;
Grant succeeded.
SQL> conn gints/gints
Connected.
SQL> exec :cv := f_slikta(-
> ''' UNION ALL SELECT zaglis.dot_tiesibas, null FROM dual --')
PL/SQL procedure successfully completed.
SQL> print cv
        ID DATI
---------- ------
         1
SQL> conn zaglis/zaglis
Connected.
SQL> INSERT INTO gints.slepena VALUES (2, 'ŠEIT BIJA ZAGLIS');
1 row created.
SQL> commit;
Commit complete.

Redzam, ka zaglis tagad no sava konta var bez problēmām darīt visu ar tabulu slepena. Kā tad tas īsti notika?

Tātad Zaglim savā kontā ir tiesības izveidot procedūras un funkcijas. Zaglis izveido funkciju dot_tiesibas, kurai ir šādas īpašības:

• Tā ir lietotāja definēta funkcija un tādas ir iespējams izsaukt Select vaicājumos;
• Zaglis ir iedevis tiesības lietotājam gints šo funkciju izpildīt, tāpēc lietotājs gints to var izdarīt (pats nemaz to neapzinādamies);
• Select vaicājumā izpildāmās funkcijas nedrīkst veikt izmaiņas datubāzē un/vai ar datubāzes objektiem, ja vien šī funkcija nav izsaukta atsevišķas transakcijas ietvaros – ko arī norāda atslēgas vārdi pragma autonomous_transaction;
• Šī funkcija speciāli ir veidota ar atslēgas vārdiem authid current_user, kas nozīmē to, ka funkcija tiks izpildīta tekošā lietotāja shēmā, nevis kā noklusēti – tā lietotāja shēmā, kas šo funkciju ir izveidojis;
• execute immediate ļauj izpildīt dinamisko SQLu, tai skaitā arī DDL un DCL.

Nākošaja solī Zaglis izpilda ievainojamo funkciju f_slikta ar šoreiz mazliet citādu SQL injekciju, kas lietotāja gints shēmā izsauc zagļa izveidoto funkciju, kas atgriež 1, bet daudz svarīgāk – piešķir visas tiesības uz tabulu slepena lietotājam Zaglis. Tādējādi Zaglis ir nonācis pie sava vēlamā rezultāta.

Līdzīgu mehānismu var izmantot arī citos datu manipulēšanas teikumos (INSERT, UPDATE, DELETE), ja tie tiek konkatenēti kopā kā teksta virknes, nevis tajos tiek korekti izmantoti mainīgie.

Tātad stāsta morāle ir šāda – nevainosim zagli, ja paši rakstam sliktu kodu. Zagļi vienmēr ir bijuši un būs, bet tikai mūsu izvēle ir rakstīt kodu, kuru zagļi var viegli izmantot saviem mērķiem, vai arī rakstīt kodu, kuru šādi izmantot nevar.

Tālākā lasāmviela

SQL injekcijas un cita drošības informācija Oracle datubāzē:

• How to write injection proof PL/SQL – Oracle Whitepaper (paldies Aleksejam par norādi komentārā!);
• Assault on Oracle PL/SQL – Injection – kāda hakera garadarbs, daudz pamatinfo, der arī iesācējiem 🙂 ;
• Avoiding SQL Injection in PL/SQL – oracle dokumentācija;
• DBMS_ASSERT dokumentācija – iebūvētā pakotne ar baru funkcijām, kas ļauj pārbaudīt ievadītos datus, vai tie ir korekti un tur neslēpjas, kas potenciāli bīstams.
• Oracle Security from PeteFinnigan.com – lapa par Oracle drošību;
• Red Database Security – lapa par Oracle drošību;
• Oracle noklusēto paroļu saraksts;
• Oracle paroļu lauzējs.

Informācija par SQL injekcijām (ne tikai Oracle) latviski:

• SQL injekcijas un atbildība;
• tvnet.lv, delfi.lv, 1188.lv, apollo.lv drošības caurumi;
• Valsts iestāžu mājaslapu drošības problēmas;
• Aizsargājam web lietojumus no SQL injekcijām.