NoSQL Injekzioa (NoSQLi): Nola funtzionatzen duten eta nola defendatu

NoSQL injezioak (NoSQLi)

NoSQL datu-baseak datu biltegiratzeko sistemak dira, helburuarekin diseinatuta informazio ez-egituratu (edo erdi-egituratu) handiak kudeatzeko, tradiziozko modeloaren (SQL edo Egituratutako Galdera Hizkuntza) datu-baseek kudeatzen duten informazioaren aldean.

NoSQL datu-base mota ohikoenak

Informazioaren erabilera desberdinen arabera, datu-baseak honela sailkatzen dira:

• Dokumentuen Datu-baseak: Informazioa JSON dokumentu gisa gordetzen da -JavaScript Object Notation, datuen serializazio eta trukerako formatu arina- edo BSON -Binary JSON, JSON formatu binarioa, testu formatuan baino binarioan kodatutako formatu bat. Kategoria honetan, CouchDB (JSON) edo MongoDB (BSON) nabarmentzen dira.

• Gako-balio datu-baseak: Datuak gako-balio pare gisa gordetzen dira. Hori dela eta, Redis edo DynamoDB erreferenteak dira.

• Grafodatuen datu-baseak: Informazioa datuen arteko harremanen modelatzea lehentasunez erabiltzen delako ezaugarritzen dira. Horrelakoetarako gehien erabiltzen direnak Neo4j edo ArangoDB dira.

• Kolonetan formatutako datu-baseak: Informazioa kolonetan formatuan gordetzea lehentasuna du. Honi buruzko adibideak Apache Cassandra edo HBase izango lirateke.

NoSQL Injekzioa (NoSQLi) zer da?

NoSQL motako injekzioa, erasotzaile batek NoSQL motako kontsultak manipulatzen dituenean gertatzen da, erabiltzaileen sarrerak edo parametroak oker balioztatzen direnean aprobetxatuz, horrela, funtzionalitatean sortu diren zehaztutakoak ez diren aginduak exekutatzeko aukera emanez, SQL motako injekzioen kasuan bezala. Estruktura hauen eta errelaziozko modeloen arteko alde nagusia da hemen ez dela lan egingo errenkadetan eta zutabeetan antolatutako taula estrukturekin, aurreko atalean ikusi den bezala, ezta SQL hizkuntzarekin, baizik eta NoSQL kudeaketa sistemaren hizkuntza espezifikoekin (JSON, BSON, CQL, etab.). Oro har, formatu desberdinekin interaktuatuko da, normalean kontsulta dinamikoen erabileraren bidez, rigidoagoak ez direnak, aplikazioan dagoen ahultasuna ustiatzeko informazioa manipulatzeko aukera ematen dutenak.

NoSQLi erasotzearen adibideak NoSQL DBMS desberdinetan

Hurrengoan, datu-baseen kudeaketa sistemetan edo erabiltzen diren NoSQL datu-baseen kudeatzaileetan oinarrituta, ustiapen eszenatoki posibleak aztertuko dira.

1. MongoDB

MongoDB JSON erabiltzen du kontsultak egiteko. JSON dokumentua gordetzean, bere BSON (binar) formatura bihurtuko da. Kredentzialak egiaztatzeko kontsulta tipiko bat honakoa izan daiteke:

db.users.find({ username: "admin", password: "Passw0rd!"});

Oinarrizko erasoa

Sarrera sanitizatu ez bada, erasotzaile batek bidali dezake:

{ "erabiltzaile_izena": { "$ne": null }, "pasahitza": { "$ne": null } }

Hau kontsulta sortzen du:

db.users.find({ username: { $ne: null }, password: { $ne: null } })

Horrela, emaitzak kredentzialen balidazioa saihestuko du eta erasotzaileak sistemara sartuko da, antzeko moduan nola SQLi tradizional batekin saihestu daitezkeen formulario baten autentifikazio mekanismoak klasiko injezioarekin ' OR 1=1 -- edo antzeko.

Ohartu, db.users.findOne erabiliz, datu-baseko lehen erabiltzailea berreskuratuko litzateke, normalean administratzailea izaten dena.

2. Redis

Redis giltza-balio datu-basea da, GET eta SET bezalako aginduak ahalbidetzen dituena. Eraso tipiko batek giltzen manipulazioa barne har dezake, berreskuratu nahi den informazio desberdina lortzeko.

Suposatu dezagun aplikazio batek giltzak kontsultatzen dituela:

GET erabiltzailea:admin

Oinarrizko erasoa

Eragile batek inyectatu dezake:

GET erabiltzailea:*

Wildcard '*' erabiliz, patroiarekin bat datozen gako guztiak itzuliko dira eta, beraz, aplikazioaren erabiltzaile guztiak zerrendatuko dira.

3. Apache Cassandra

Cassandra CQL (Cassandra Query Language) erabiltzen du, SQL-ri antzekoa, baina bere zutabeen modelora egokituta. Horregatik, agian, sistema hauen inguruko NoSQLi erasoei buruzkoak tradizionalak diren SQLi-ri gehiago irudikatzen zaizkie, post honetan aztertutako gainerakoak baino.

"Erabiltzaileak bilatzeko kontsulta tipikoa izan daiteke:"

SELECT * FROM users WHERE username = 'admin' AND password = 'Passw0rd!';

Oinarrizko erasoa

Horrela, erasotzaile batek inyectatu dezake:

' EDO '1'='1

 Horrek sortuko luke:

SELECT * FROM users WHERE username = '**' OR '1'='1**' AND password = ''

... modu honetan sistema osoaren erabiltzaile guztietara sartuz.

4. Neo4j

Neo4j-k Cypher erabiltzen du kontsulta hizkuntza gisa. Nodoak bilatzeko kontsulta tipiko bat izan daiteke:

MATCH (u:User {username: 'admin', password: 'Passw0rd!'}) RETURN u;

Oinarrizko erasoa

Eragile batek inyectatu dezake:

MATCH (u) RETURN u //

... eta, ondorioz, datu-baseko nodo guztiak itzuli daitezke.

 

Obfuskatze eta saiheste teknikak

Web aplikazioen sukurri (WAF) bezalako detekzio sistemek injekzio arruntak blokeatzen dituzte. Hala ere, erasotzaileek teknikak aurreratuak erabil ditzakete horiek saihesteko, SQLi erasoei eta beste injekzio mota batzuei ikusi zaien bezala. SQL datu-baseei antzera, baina datu-base mota honi aplikatuta, hurrengo teknikak erabil daitezke:

1. Kodetzea

Karaktere bereziak kodifikatzeak WAFek susmagarriak diren patroiak detektatzea saihesten lagun dezake.

Hexadecimal kodifikazioa

Karaktereak hexadezimalean irudikatzea:

{ "$ne": null } → %7B%20%22%24ne%22%3A%20null%20%7D

Base64 kodeketa

Payload osoa base64-en kodifikatu (eta ondoren bezeroan dekodifikatu):

{ "$ne": null } → eyAiJG5lIjogbnVsbCB9Cg==

2. Iruzkinak

Teknika honek iruzkinak sartzea dakar detekzio arauak saihesteko. Adibidez, Neo4j-n, aurretik ikusi den kodea injetatu daiteke erabiltzaile guztiak berreskuratzeko, baina aurretik iruzkin bat sartuz:

MATCH /* loquesea */ (u) RETURN u

3. Kateamendua

Konkatenazioa (+) erabiliz, SQLi-n gertatzen zen bezala, katea zatitu daiteke payload-a bereizteko eta, horrela, detekzio zuzenak saihesteko. Adibidez, MongoDB-ren kasuan:

{ "username": { "$n" + "e": null } }

4. Kontrol karakteren edo Unicode espazioen erabilera (ikusezinak diren karaktereak)

Batzuetan, benetan kontsulta aldatzen ez duten karaktere batzuk erabiliz, injezioetan WAFen detekzio-patroiak apurtzeko erabil daitezke. Adibidez, Redis-en ikusi den kasuan, izar (*) erabiltzeari aurre egin aurretik, "zulo zabaleko" karaktere Unicode-a (unicode karaktere 200B) txertatzea.

LORTU erabiltzailea:\\u200B*

Prebentzio neurriak

1. Balidazioa eta garbiketa

• «Balioztapen estuena erabiltzea zerbitzari aldean.»

• Ezohiko karaktereak edo egitura ezohikoak baztertzea funtzionalitate zehatz bat gauzatzeko. Hobe da jasotzeko espero diren balioen bidez mugatzea, balio "irekien" bidez baino, erasotzaile batek aprobetxatu ditzakeen edo ihes-funtzioak osatu gabe geratu daitezkeen balioen bidez. Azken kasu honetan, eta beharrezkoa bada, lehendik dauden liburutegiak eta funtzionalitateak erabiltzea. Beti bilatu behar da "errutza berriro asmatu ez" horretan.

2. Liburutegi seguruen erabilera

Seguru operadoreak erabiltzea ezartzea. Adibidez, $eq erabiltzea, MongoDB-n:

db.users.find({ username: { $eq: "admin" }, password: { $eq: "Passw0rd!" } });

Horrela, kontsulta dinamiko "irekiak" eraikitzeko saihestuko litzateke. Hori kontuan hartu beharko litzateke ere adierazpen erregularrak erabiltzen diren kasuetan.

3. Gutxieneko Pribilegioen Printzipioa edo erabiltzailearen baimenak mugatzea.

Betiko gomendatzen da langile erabiltzailearen baimenak mugatzea, informazioari soilik sarbidea izateko, beharrezkoa dena, eta beste inorentzat ez, dagoeneko aipatutako datu-basearen esparrura mugatuta.

4. WAF (Web Application Firewall) erabilera

WAF-a NoSQLi-ren patroi espezifikoak blokeatzeko erabili beharko litzateke, baina inoiz ahaztu gabe garapen segururako praktika onak jarraitu behar direla, patroi horiek saihesteak aplikazioaren aurkako eraso arrakastatsu batean amaitu ez dezan. 

Ondorioa

NoSQL datu-baseak lehiakortasun abantaila eskaintzen dutelako, malgutasunari, eskalagarritasunari eta informazio bolumen handien kudeaketari dagokionez, erasotzeko azalera berriak irekitzen dira, SQLi tradizionalekin antzeko metodoekin, NoSQLi kasu. Eraso tradizional hauetatik desberdina, hemen informazioaren egitura ezaren natura aprobetxatzen da, normalean JSON/BSON fitxategien manipulazioaren bidez.

Oso garrantzitsua da, garatzaileek, sistemaren administratzaileek eta datu-baseen administratzaileek, segurtasun maila anitzeko hurbilketa bat egin dezatela, sarrera parametroen balidazio eta garbiketa egokia (erabiltzen diren kudeaketa sistemetara egokituta) hasi eta, liburutegi seguruen erabilera eta sistema eta baimenetan egoki (eta mugatua) den konfigurazioa izan arte.

Gainera, erasotzaileen erabilitako ihes teknikak konprimitzea eta segurtasun probak periodikoki egiteak mehatxu mota honen aurkako defentsak hobetzen lagundu dezake.

Azkenik, NoSQLi-k SQLi-rekin antzekotasunak partekatzen dituen arren, erabilitako NoSQL hizkuntzen eta egiturek diferentziak eskatuko dituzte, sistema hauek hainbat erasotatik babesteko hurbilpen desberdin eta bakarrak beharrezkoak izango direlarik.

Roberto Trigo, Zibersegurtasuneko aholkularia Zerolynx-en.