DAST segurtasun proben erorketa

Erakunde askok hainbat iturritako datuak biltzen dituzte, hala nola erabiltzaileak, eta gero datu-lakuetan gordetzen dituzte. Datuak dena dira egun, datu pila handi bat denbora laburrean prozesatzeko gaitasuna baita.

Datuen erabilera beti APIen bidez egiten da. APIek aplikazioaren osagai guztiak elkarrekin mantentzen dituzte eta edozein bezero motarentzat eskuragarri bihurtzen dituzte, erabiltzaile bat bezala.

Jakina, APIak ez ziren bakarrik etorri. Arkitektura monolitiko tradizionalak beste batzuei eman die lekua, mikrozerbitzuei bezala. Dena modularra da egun. Mikrozerbitzuek edozein aplikazio modular eta konposagarri bihurtzen dute eskalagarritasun hobea, malgutasun handiagoa eta merkaturatzeko denbora laburragoa lortzeko.

APIekin konbinatutako mikrozerbitzuak softwarearen garapenaren etorkizunekotzat hartzen dira. Hain da egia, non OWASPek 2019an kaleratu zuen bere OWASP TOP 10 ezagunaren APIra egokitutako bertsioa. Beraz, agertoki honetan, aplikazioen segurtasuna softwarea egiteko modu berri horretara egokitu eta hari jarraitu behar zaio.

Azken hamarkadan, aplikazioen segurtasuna ere eboluzionatu egin da segurtasun proba automatizatu eta espezializatu batzuen moduan. Hala ere, badirudi segurtasun-kontrolen bilakaera atzeratuta dagoela, eta hori da Dynamic Application Security Testing (DAST) kasua.

DAST, tipo jatorra

DAST kutxa beltzaren tresna "nahiko" automatiko gisa atera zen web-aplikazioen ahultasun zehatzak aurkitzeko garaian, teknika ia bakarrak SAST azterketa eta eskuzko petesting ziren garaian. DASTak pentester-ari laguntzeko promesarekin sortu ziren, eta SAST tresnetako hutsune batzuk betetzeko, hala nola, positibo faltsuak murriztea eta eskaneatzeko denbora murriztea.

Exekutatzen den prozesua oso erraza izan zen: aurrez zehaztutako arau-multzo batzuetatik, HTTP eskaerak bidaltzen ditu web-aplikaziora eta erantzunetan zenbait kate zaintzen ditu ahultasunik dagoen ikusteko. Beste era batera esanda, DAST pentester bat simulatzen saiatzen da.

Esan beharrik ez dago pare bat eragozpen nagusi daudela: 

• Positibo faltsuak. Zenbait positibo faltsuk eskaneatu ondoren berrikuspen labur bat beharko lukete, triage deritzona. Triatze horrek zibersegurtasuneko analista baten begi adituak beharko lituzke askotan, eta aditu batek ere denbora preziatu bat behar du, eskaneatu ondorengo urratsak moteldu ditzakeena.
• Denbora. Eskaneatzeek denbora behar dute exekutatzen, normalean 30 minututik 2 ordura, edo agian egunak, aplikazioaren tamainaren arabera. Gainera, denbora konfigurazioa zein ona den araberakoa izango da. Zenbat eta konfigurazio hobea izan, orduan eta denbora gutxiago beharko da exekutatzeko. Baina eskaneatu aurretiko konfigurazio on bat konfiguratzea ez da hain erraza eta gehienetan zibersegurtasun aditua behar da.

DAST Software garapenaren atzetik dago

Softwarea garatzeko modua aldatu egin da. DAST gaur egun CI/CD kanalizazio batean integratuta dago, eta CI/CD inguruneetan arintasuna eta abiadura dira oinarriak. Eraikitzeko eta inplementatzeko kanalak ez luke minutu batzuk baino gehiago iraun behar.

Hau ez dirudi DAST-en ezaugarri bat denik. Lehen aipatu den bezala, DAST eskaneek denbora behar dute exekutatzeko, aurkikuntzak berrikusteko eta konfiguratzeko denbora. Baina zulo hauek ez dira bizkortasunaren eta abiaduraren kontrakoak diren bakarrak:

• Aurkikuntza eta arakatzea. DAST-en ezaugarri handietako bat eskaneatzean aplikazioaren ia zati guztiak bilatzeko eta arakatzeko gaitasuna da. URLak berridazteko eta estekak jarraitzeko arau heuristiko batzuk aplikatuz, DAST tresnek web aplikazioen azpidomeinu eta atal asko aurkitu eta arakatu ditzakete. Aurkikuntza prozesu honen beste bertsio bat trafikoa proxy-a eta eskaneatu beharreko amaiera-puntuak biltzea da. Baina garai modernoetan, segurtasuna SDLCn ezkerrera aldatzen ari den bitartean, ezaugarri hauek gabeziatzat har litezke denbora behar delako. Zorionez, urteetan zehar DAST tresna gehienek hainbat formatutan eskaneatu nahi dituzun aplikazioaren amaierako puntuak zehazteko aukera sartu dute.
• Garatzaileek DAST erabiltzen dute. *DevSecOps* paradigma berriaren arabera, garatzaileek beren kabuz erabil ditzakete kanalizazioetan dauden tresna batzuk, segurtasun tresnak adibidez. Honek softwarearen garapen-prozesuari arintasun handiagoa eskaintzea da. Garatzaileek beren kabuz DAST bezalako segurtasun-analisi baten aurkikuntzak berrikus ditzakete, horrek garapen osoa bizkortuko luke. Teorian. Praktikan, garatzaileek positibo faltsu bat dena eta ez dena bereizteko borroka egiten dute, edo segurtasun aditu batek baino denbora gehiago inbertitu behar dute hori egiteko. Eszenatoki honek izugarri murrizten du DevSecOps taldeen positibo faltsuekiko tolerantzia eta segurtasun probetan konfiantza murrizten du.

Azkenik, softwarea bera ere aldatu da. Hasieran esan bezala, APIak eta mikrozerbitzuak oraina eta etorkizuna dira, eta DAST ez dago ondo egokituta:

• DASTek ezin du web frontend batean sortutako eduki dinamikorik aurkitu, eta hori oso ohikoa da gaur egun javascript esparruen erabilera hedatuagatik, Angular, React, Next, JQuery, etab.
• DASTek ezin ditu APIetan ohiko ahultasun mota batzuk hautematen, IDOR/BOLA adibidez, aplikazioaren negozio-logikaren testuingurua behar duelako, erabiltzaile-rolak eta pribilegioak adibidez.
• DAST-ek babes-horma batzuetatik igarotzen ere borrokatzen du, hala nola CSRF-ren aurkako tokenak eta APIetako hainbat autentifikazio/baimen-mekanismo tipiko, hala nola OAuth2, SSO eta faktore anitzeko autentifikazioa. Oztopo horietako batzuk gainditzea posible bada ere, ziur asko eskaneamendua prestatzeko denbora handituko litzateke, eta aplikazio bakoitzak bere konfigurazioa behar du.

Nola egin DAST 2023an eta ez hil nahian?

Une honetan, nahiko tentagarria da DAST alferrikakoa dela pentsatzea, baina ez da hala. Aurreko gabezia asko DAST beste modu batzuetan erabiliz gaindi daitezke:

• Berreskuratu DAST fruta baxua aurkitzeko. Zaurgarritasun batzuk erraz eta azkar aurkitzen dira edozein DAST tresnarentzat eta positibo faltsuen ratio nahiko baxua dute. Adibide batzuk HTTP goiburuak, Cross Site Scripting edo SQLi motaren bat ere ez dira seguruak edo falta direnak.
• Segurtasun-baldintza zehatzetarako proba. Segurtasun-eskakizunen katalogo bat existitzen bada, DAST proba-multzo zehatz bat probatzeko erabil liteke aplikazio askotan balio handiko eskakizun horiek egiaztatzeko.
• Sortu konfigurazio txantiloiak aldez aurretik. Lehen esan bezala, zenbat eta konfigurazio hobea izan, orduan eta denbora gutxiago beharko da exekutatzeko. Ideia polita litzateke denbora pixka bat inbertitzea antzeko ezaugarri edo arkitektura duten aplikazio asko eskaneatzeko erabil daitezkeen konfigurazio batzuk prestatzen. Hau eginez, konfigurazio egoki bakarrarekin, exekuzio-denbora eta positibo faltsuak nabarmen murriztuko lirateke etorkizuneko analisietan.
• Saihestu eskaneaketa osoak. Aplikazio osoa eskaneatzea denbora asko izan daiteke eta CI/CD kanalizazio baten urrats bakoitzak segundo edo minutu batzuk besterik ez ditu behar. Horren ordez, murriztu eskanearen esparrua aplikazioan berriki egindako aldaketetara.
• Elikatu DAST eskaneatzeko API bide zehatzekin. Tresnak onartzen badu (gomendatua), eskatu eskanerrerari eskaneatu nahi dituzun API amaierako puntuak soilik probatzeko, adibidez, aldaketak dituztenak. Honek %100eko eskaneatu estaldura lortzeko aukera emango luke pixkanaka CI/CD prozesua moteldu gabe.
• Exekutatu DAST modu asinkronoan. Eskaneatzea CI/CD urrats batean abiarazten bada eta denbora pixka bat hartuko badu, aukera ona izango litzateke besterik gabe exekutatu amaitu arte itxaron gabe. Geroago, amaitutakoan, dagokion taldeak aurkikuntzak berrikusi edo triage batzuk egin ahal izango lituzke.

Honetaz gain, DAST oraindik tresna oso erabilgarria izaten jarraitzen du edozein pentesterrentzat, aplikazio askotan sarrera-parametro ugari nahasteko gai baita denbora gutxian aurrez zehaztutako arau-multzo batzuekin, ahultasun mota asko aurkitzea ahalbidetzen dutenak, adibidez. injekzioak eta konfigurazio okerrak.

Zer bilatu behar den DAST tresna batean API segurtasun-probak egiteko

DAST edo antzeko tresnak API Segurtasun Probetarako ebaluatzean, zaila izan daiteke zein tresna den aukerarik onena jakitea, beraz, behean erabil ditzakezun irizpide batzuk daude:

• Erraz integratzen da CI/CD kanalizazio batean.
• Eskaneatu nahi den aplikazio mota hautatzeko aukera ematen du: APIa edo web front-endarekin.
• Hainbat API zehaztapen formatu onartzen ditu eskaneatu beharreko API bide zehatzak zehazteko: Postman bildumak, OpenAPI/Swagger, GraphQL introspekzioa, WADL, WSDL, etab.
• Probatu beharreko API mota zehatza hautatzeko aukera ematen du: REST, GraphQL, SOAP.
• Negozio-logikako ahuleziak detektatzeko konfigurazio finak sortzeko aurre eta ondorengo definitzeko gaitasuna eskaintzen du.

Berrikusteko

Softwarea garatzeko modua aldatu egin da, baita softwarea bera ere. Arintasuna eta abiadura edozein SDLCren funtsezko ezaugarriak dira CI/CD kanalizazioak erabiltzearen abantailei esker. APIak edozein software berriren oinarri bihurtu dira, beraz, aplikazio segurua ematea azpiko APIetan ahultasunik ezaren araberakoa da.

APIak oso azkar bermatu behar dira, eta DAST horretarako egokia ez den arren, eskaneaketen konfigurazioa eta kanalizazioetan integratzeko forma alda daitezke APIak hobeto eta azkarrago eskaneatzeko.

AI: Esperantza Berria

Post hau ezin da amaitu Adimen Artifiziala aipatu gabe. Egia esan, edozein segurtasun-irtenbideek AI erabil dezakete DAST-en hutsune asko konpontzeko: aurkikuntza, arakatzea eta URL berridazketa hobetu, eskaera bikoiztuak edo errepikakorrak saihestu, positibo faltsuak gutxitu, negozio-logika konplexuak ahultasun detektatu...

Agian, AI DAST phoenix berpiztuko duen sua bihurtuko da. Zer uste duzu?

Ernesto Rubio, Zibersegurtasuneko analista