SQL injekzioaren eragina
SQL injekzio (SQLi) erasotzaile bati aplikazio batek bere datu-baseari [S1] egiten dizkion kontsultak oztopatzeko aukera ematen dio. Eragin nagusiak datu sentikorretarako baimenik gabeko sarbidea da, hala nola, erabiltzaileen pasahitzak, kreditu-txartelen xehetasunak eta informazio pertsonala [S1].
Datu-lapurretaz haratago, erasotzaileek datu-baseen erregistroak alda ditzakete sarritan, eta ondorioz aplikazioen portaeran aldaketa iraunkorrak edo datuak galtzea [S1]. Larritasun handiko kasuetan, SQLi eskala daiteke back-end azpiegitura arriskuan jartzeko, zerbitzuaren ukapeneko erasoak gaitzeko edo erakundearen sistemetan atzeko ate iraunkor bat eskaintzeko [S1][S2].
Arrazoia: Sarreraren kudeaketa ez segurua
SQL injekzioaren kausa [S2] SQL komando batean erabiltzen diren elementu berezien neutralizazio desegokia da. Aplikazio batek SQL kontsultak eraikitzen dituenean gertatzen da kanpoko eraginpeko sarrerak zuzenean [S1][S2] kontsulta-katean kateatzen dituenean.
Sarrera kontsulta-egituratik behar bezala isolatuta ez dagoenez, datu-basearen interpretatzaileak erabiltzailearen sarreraren zatiak SQL kode gisa exekutatu ditzake, [S2] datu literal gisa tratatu beharrean. Ahultasun hau kontsulta baten hainbat ataletan ager daiteke, besteak beste, SELECT adierazpenak, INSERT balioak edo UPDATE adierazpenak [S1].
Hormigoizko konponketak eta aringarriak
Erabili Parametrizatutako Kontsultak
SQL injekzioa ekiditeko modurik eraginkorrena kontsulta parametrizatuak erabiltzea da, prestatutako instrukzioak [S1] bezala ere ezagutzen direnak. Kateak kateatu beharrean, garatzaileek [S2] datuak eta kodea bereiztea behartzen duten mekanismo egituratuak erabili behar dituzte.
Pribilegio txikienaren printzipioa
Aplikazioek datu-basera konektatu behar dute beren zereginetarako behar diren pribilegio txikienekin [S2]. Web-aplikazioko kontu batek ez luke administrazio-pribilegiorik izan behar eta bere funtziorako beharrezkoak diren taula edo eragiketa zehatzetara mugatu behar da [S2].
Sarrera baliozkotzea eta kodetzea
Parametrizazioaren ordezkoa ez den arren, sarreraren baliozkotzeak defentsa sakona eskaintzen du [S2]. Aplikazioek onartze-onartze-estrategia erabili behar dute, sarrerak espero diren mota, luzera eta formatuekin bat datozela egiaztatuz.
FixVibe probak nola egiten dituen
FixVibe dagoeneko estaltzen du SQL injekzioa active.sqli eskaner modulu itxiaren bidez. Azterketa aktiboak domeinuaren jabetza egiaztatu eta egiaztatzen ondoren bakarrik egiten dira. Egiaztapenak jatorri bereko GET amaiera-puntuak arakatzen ditu kontsulta-parametroekin, oinarrizko erantzuna ezartzen du, SQL-ren berariazko anomalia boolearrak bilatzen ditu eta aurkikuntza baten berri ematen du atzerapen-luzera anitzetan denbora-berrespena egin ondoren. Biltegiko eskaneatzeek ere oinarrizko arrazoia lehenago harrapatzen laguntzen dute code.web-app-risk-checklist-backfill bidez, txantiloiaren interpolazioarekin eraikitako SQL dei gordinak markatzen dituena.