Identification and authentication failures

Identifikazio eta autentifikazio akatsak

2025(e)ko urtarrilaren 20(a) Celia Catalán

Identifikazioa, autentifikazioa edo baimena?

Lehenik eta behin, identifikazioaren eta autentifikazioaren arteko desberdintasuna ulertu behar dugu:

ID: Prozesua da identitate bat ematen dena; erabiltzaile edo sistema batek nor den adierazten du.
Autentifikazioa: Identitate bat egiaztatzeko prozesua da. Erabiltzaile edo sistema bat identifikatzen denean, nor den adierazten du; autentifikatzen denean, berak dioen pertsona dela egiaztatzen da.

Nahiz eta ezagunenak diren akatsak autentifikazioan egon, izan ere, han egiten dira erabiltzaileen identitatea egiaztatzeko segurtasun kontrolak, identifikazio prozesuan ere akatsak daude, informazioaren segurtasunean eragina izan dezaketenak. Adibide batzuk hauek dira:

Identifikazio okerra edo ezagutzen ez dena: Erabiltzaile batek erabiltzaile izena edo ID ez erregistratu bat sartu badu sisteman, identifikazio prozesua huts egiten du, sarrera horri lotutako identitaterik ez delako aurkitzen.

Identitate bikoitza: Sistema batzuetan, bi kontu egon daitezke erabiltzaile izen antzekoak edo ID oso antzekoak dituztenak, eta horrek konfusioa sortzen du identifikazioak zein erabiltzaileari egiten dion erreferentzia zehazteko.

Bestalde, garrantzitsua da autentifikazioaren eta baimenen arteko desberdintasuna ulertzea, antzekoak diruditen arren, prozesu desberdinak baitira. Autentifikazioak, azaldu dugun bezala, erabiltzaile edo sistema baten identitatea egiaztatzen du, baimenak, aldiz, erabiltzaile edo sistema horrek zein ekintza edo baliabide eskuratzeko baimena duen zehazten du.

Autentifikazio faktoreak

Autentifikazio faktore nagusi hiru daude, printzipio sinpleetan oinarrituta: erabiltzaileak badakiena, erabiltzaileak duena eta erabiltzaileak daena.

Ezer erabiltzaileak badaki: adibidez, pasahitz bat edo segurtasun galderaren erantzun bat.

Ezer erabiltzaileak du: fisiko objektu bat edo segurtasun token bat bezala.

Ezer erabiltzaileak da: biometriko datu gisa (atzamar-orratz) edo portaera-patroi gisa.

Nahiz eta pasahitzak autentifikazio mekanismo ohikoena izan, sistema bakoitzak erabiltzailearen identitatea egiaztatzeko faktore desberdinak eskatzen ditu. Gaur egun, mekanismo anitz daude: datu biometrikoetan oinarritutakoak (smartphoneen desblokeoa bezalakoak) eta hardware zehatzak erabiltzen dituztenak (gordetako gailuak, adibidez). Gainera, gero eta ohikoagoa da autentifikazio multifaktoriala erabiltzea, adibidez, pasahitzak segurtasun tokenekin konbinatuz.

Hau mekanismo desberdinen panorama anitzak malgutasun handiagoa eskaintzen du eta sistemaren segurtasun orokorra hobetzen du. Hala ere, konplexitate berriak eta erasotzaileek aprobetxatu ditzaketen ahultasun posibleak ere sorrarazten ditu.

Hurrengoan, autentifikazio prozesuarekin lotutako ahultasun mota desberdinak aztertuko ditugu, eragindako mekanismoaren arabera taldekatuz. Ahultasun hauetan jarriko dugu arreta, izan ere, segurtasun akats gehienak arlo honetan agertzen dira.

Pasahitz oinarritutako autentifikazioa

Erabiltzaile eta pasahitz bakarrik erabiltzen dituzten sistemek pasahitzari fidatzen diote erabiltzailearen identitatearen froga gisa. Honek esan nahi du erasotzaile batek erabiltzaile baten kredentzialak lortzen baditu, autentifikazio prozesua osorik konprometitu dezakeela. Mekanismo hau ahultzeko hainbat erasotako mota daude:

Indar gordina

Indarrezko erasoei buruzko prozesua probak eta akatsak dira, non erasotzaileak etengabe kredentzial desberdinak sartzen dituen —ausaz, arauak jarraituz edo hitzen hiztegiak erabiliz— erabiltzaile legitimo baten kredentzialak aurkitzeko.

Erabiltzailearen pasahitza aurkitu aurretik, erabiltzaile izenik ez badago ezagutzen, erabiltzaileen enumerazioa egin behar da. Web aplikazio batean erabiltzaile izen baliodunak identifikatzeko hainbat metodo daude.

Lehenengoa zerbitzariaren erantzunean oinarritzen da. Aplikazioan erregistratutako erabiltzaile bat sartzean, ez existitzen den erabiltzaile bat sartzean lortzen dugun erantzunetik desberdina den erantzuna jasotzen dugu. Prozesu hau automatizatzeko, BurpSuiteko Intruder bezalako tresnak erabil ditzakegu, web eskaera batean parametroei indarrezko erasotzeak egiteko hitz-dizionarioak edo karaktere eta zenbaki sekuentziak sortzeko arauak erabiliz. Hurrengo adibidean, sartutako hitzetako bat gainerakoen tamaina desberdineko erantzuna itzultzen duela ikusten dugu:

'Eskaera honen erantzunean egiaztatu dugu plataformak pasahitza ez dela baliogarria adierazten duela, sartutako erabiltzailea ez dela baliogarria dioten gainerako erantzunen aldean:'

Ez da beti hain argi; batzuetan programaren akats subtilak ikusi behar ditugu. Hurrengo kasuan, antzeko egoera bat behatzen dugu. Erantzun guztiak tamaina desberdinekoak izan arren eta erabiltzailea edo pasahitza baliogabeak direla adierazten dutela, erantzunaren programazioan akats ortografiko txiki bat dago. Akats honek, erabiltzaile existitzen denean, erantzunean aldaketa txiki bat sortzen du:

Erantzun zuzena:

Erantzun okerra:

Beste metodo bat, erantzuna beti bera denean, erantzun denbora adierazle gisa erabiltzea da. Pasahitz oso luze bat sartzen badugu, eta zerbitzariak erabiltzailea asmatu arte soilik prozesatzen badu, litekeena da karaktere kate hain luze bat prozesatzen saiatzean denbora gehiago irabaztea. Adibide honetan, erabiltzaile desberdinekin probatzen dugu beti pasahitz oso luze bat erabiliz:

Erabiltzaileen zenbatzeko teknika asko daude. Interesatuta bazaude, bisitatu dezakezu OWASP-en "Insecure Design" ahultasunari buruzko gure argitalpena.

IP blokeoak saihestea

Saio-hasierako murrizketekin topo egitea posible da. Murrizketa ohikoena IP murrizketa da, non zerbitzariak aldi baterako blokeatzen dituen saio-hasierako saiakerak helbide IP zehatz batetik. Hala ere, blokeo hau saihesteko metodoak daude. Adibidez, X-Forwarded-For bezalako buruak erabiltzea, zerbitzariak prozesatzen badu, IP blokeoa saihestera eraman dezake.

Beste kasu batzuetan, blokeoa zenbait saiakera egin ondoren gertatu daiteke, baina saioa ondo hasi denean berriro hasiko da. Adibidez, IPa 3 saiakera bakoitzean blokeatzen dela detektatzen badugu, kredentzialen hiztegi bat erabil dezakegu eta erabiltzaile legitimo baten kredentzialak (erabiltzaile baten kredentzialak izan behar ditugu) hiztegiaren 2 sarrera bakoitzean txertatu. Metodo honekin, blokeoa saihestu dezakegu eta gure hiztegiko sarrera guztiak probatu.

Halaber, badaude kasuak non autentifikazio-eschemaren enumerazioa edo saihestea HTTP eskaera bakar batekin egin daitekeen, horrela saio-hasiera saiakeren errepikapena saihestuz. Adibidez, saioa hasteko JSON bat bidaltzean, balio bakar baten ordez pasahitzen array bat bidaltzen badugu, zerbitzariak JSON hori behar bezala prozesatu dezake eta erabiltzailearen egiazko kredentzialak ezagutzen ez baditugu ere, saioa hasteko aukera emango digu.

Erabiltzaile kontuaren blokeoa saihestea

Kontuaren blokeoa segurtasun mekanismo bat da. IP blokeatzearekin alderatuta, metodo honek kontua blokeatzen du saio hasierako saiakera faltsu ugari ondoren. Hala ere, sistema soilik kontu existitzen blokeatzen badu, hau erabiltzaileen enumerazio batera eramango du, nahi gabe. Adibidez, izen erabiltzaile desberdinekin saio hasierako saiakera errepikatuan, kontu jakin bat blokeatzen dela ohartzen gara bosgarren saiakera faltsuaren ondoren:

Horrela, erabiltzaile baten zerrenda lortzen dugu web aplikazioaren saio-panelan.

Oinarrizko sarbide autentifikazioa

Nahiz eta metodo hau oso zaharra den, oraindik posible da sistema ahul hau erabiltzen duten zerbitzariak aurkitzea. Autentifikazio mekanismo honek erabiltzaile izena eta pasahitza lotzea, Base64-en kodifikatzea, eta baimena (Authorization) goiburuan sartzea dakar eskaera bakoitzean:

Metodo hau bereziki arriskutsua da. Web orriak HSTS ezartzen ez badu, eraso bat egiten duen erasotzaile batek bitarteko gisa, burua harrapatu dezake. Hori dekodifikatzean, erabiltzailearen kredentzialak lortuko lituzke.

Aniztasun faktorearen autentifikazioa

Pasahitzetan oinarritutako autentifikazio metodoek segurtasun guztia parametro bakar batean jartzen dute: erabiltzaileak dakiena.

Kontrastean, autentifikazio multifaktorialak gutxienez faktore gehigarri bat sartzen du. Adibide ohiko bat bi faktoreko autentifikazioa (2FA) da, erabiltzaileak dakiena (pasahitza) eta zerbait duena (email bidez bidalitako erabilera bakarreko kodea) eskatzen dituena. Hala ere, beste konbinazio batzuk ere badaude, adibidez, hatz-markak —zerbait bera— edo autentifikazio aplikazioak, hala nola Microsoft Authenticator, email bidez bidalitako kodea ordezkatzen duen mugikorretarako aplikazioa.

Bikoitz autentifikazio faktorearen saihestea

Egoera sinpleena gertatzen da sistema erabiltzailea autentifikatuta kontsideratzen duenean lehen faktorea sartu ondoren, bigarren bat eskatu arren. Adibidez, erabiltzaile baten pasahitza ezagutzen badugu eta autentifikatuta dauden erabiltzaileentzat gordetako direktorio edo baliabideei buruzko informazioa badugu, segurtasun-tokena eman gabe zuzenean sar gaitezke. Honek bigarren autentifikazio-faktorearen inplementazio txarra agerian jartzen du, izan ere, sistema autentifikatuta kontsideratu behar lituzke prozesu osoa osatu duten erabiltzaileak bakarrik.

Aldez aurreko mugimendua ezarpen akatsagatik

Aurreko kasuarekin antzekoa, hemen erabiltzaileak sarbidea lortzeko egin behar dituen prozesu guztien egiaztapenean arazo bat dagoela ikusten dugu. Nahiz eta nahasgarria iruditu, hurrengo adibideak argi azaltzen du.

Bi faktoreko autentifikazioa (2FA) duen web bat kontuan hartu dezagun. Erabiltzailearen izena eta pasahitza sartu ondoren, aplikazioak segurtasun-token bat eskatzen du identitatea baieztatzeko. GET eskaera bat egiten da /login2-ra, zerbitzariak erabiltzailearen emailera tokena bidaltzeko. Zerbitzariak token hau eskaeraren Cookie goiburuan adierazitako erabiltzaileari bidaltzen dio:

Horrela, gure erabiltzaile izena biktimarenarekin ordezkatzen badugu, zerbitzariak sarbide-tokena biktimaren erabiltzailearen posta elektronikora bidaliko du:

"Behin token hau biktimaren emailera iristen denean, erasotzaileak bere erabiltzaile kredentzialekin saioa hasi dezake eta tokena sartzeko prozesura pasa. Tokena sartzerakoan, Cookie goiburua berriro aldatzen badu biktimaren erabiltzaile izena sartzeko eta segurtasun tokenaren aurka indarrez jotzen badu, emailera bidalitako segurtasun tokena aurkitu dezake eta honekin biktimaren erabiltzaileari sarbidea lortu."

Kasuan honetan, zerbitzariak autentifikazio prozesuaren bigarren pausoa soilik egiaztatzen du, hau da, segurtasun-tokena. Tokena baliozkoa bada eta erabiltzailearen Cookie goiburuan bidalitakoarekin bat badator, zerbitzariak sarbidea ematen du. Hala ere, ez du lehen pausuan emandako kredentzialak (hala nola, erabiltzaile izena eta pasahitza) sarbidea eskatzen den erabiltzailearekin bat datozen egiaztatzen.

Autentifikazio mekanismoetako ahultasunak

Autentifikazio prozesuarekin lotutako ahultasunak ez dira soilik saio-hasieran murrizten. Beste prozedura kritiko batzuetan ere aurki daitezke, hala nola pasahitza aldatzea, posta elektronikoaren helbidea eguneratzea edo saioaren iraunkortasuna kudeatzea, azpimarratuko dugun bezala.

"Nire autentifikazioa mantendu" aukera

Web orri askotan, saioa hasi orduko, nabigatzailea itxi eta berriro ireki arren, saioa aktibo mantentzeko aukera eskaintzen da. Funtzionalitate hau cookie iraunkor baten bidez ezartzen da, saio cookie baten antzekoa, baina iraupen luzeagoa du (gutxienez denbora jakin baterako). Praktika hau oso ohikoa den arren, aplikazioaren segurtasuna arriskuan egon daiteke token hau nola diseinatuta eta kudeatuta dagoen arabera.

Hurrengo adibidean, saioa hasi eta saioa mantentzeko aukera hautatzean, honako cookie hauek agertzen direla ikusten dugu:

Lehen cookie-a aktiboa den saioari dagokio, bigarrena, aldiz, aurretik aipatutako cookie iraunkorra da. Token hau saioa hasi duen erabiltzailearentzat soilik eskuragarri egon beharko litzateke. Hala ere, aztertzean, nahiko aurreikustekoa dela ikusi dugu, izan ere, Base64-en kodifikatuta dago eta erabiltzailearen izena eta bere pasahitzaren MD5 hash-a ditu:

Tokenaren egitura ezagututa, posible da indar brutuko erasoa saiatzea baliozko token bat sortzeko eta erabiltzailearen kontura sartzeko. Horretarako, BurpSuiteko Intruder erabiliko dugu cookie iraunkorrari dagokion parametroaren fuzzing egiteko. Lehenengo pausoa izango da pasahitz guztiak beren MD5 hash-ean bihurtzea:

MD5 hash zerrenda sortu ondoren, gure erasoarentzako hiztegi gisa erabiliko dugu. Hala ere, horren aurretik, hiztegiaren post-prozesamendu bat egin behar da: biktimaren erabiltzaile izena : jarrita gehituko dugu, eta ondoren, kate osoa Base64-era bihurtuko dugu. Ondoren, Intruder-rekin eraso egiten dugu, biktimaren profila sarbide arrakastatsua lortzeko aukera emango diguna sortutako cookie iraunkorretako bat erabiliz.

Cookie lapurreta XSS bidez

Ezin da zerbitzariak blokeatu gaitu, hainbat token probatzean eskaera gehiegi egiten baditugu, baina muga hori saihesteko beste metodo batzuk daude. Cookie anitz probatu beharrean, erabiltzaile baten sesio cookiea lapurtzen saiatzea izan daiteke. Tokena erabiltzailea:hash[pasahitza] bezalako esquema batean badago, aurreko kasuan bezala, hash-a indar brutuz deszifratzen saiatuko gara hashcat bezalako tresnak erabiliz. Baina nola lortu dezakegu erabiltzaile baten cookiea? Hori XSS erasoa erabiliz lortzen da, hurrengo adibidean azaltzen den bezala.

Blogetako baten iruzkin atala JavaScript kode injezio baten aurrean ahul dela iruditzen da. Orrialde hau beste erabiltzaileentzat eskuragarri dagoenez, kode gaiztoa injeztatuz, gure biktimak iruzkin atala sar dezake eta JavaScript kodea exekutatu dezake konturatu gabe. Saio cookiea lapurtzeko, lehenik eskaerak jasotzeko itxaroten duen zerbitzari bat konfiguratzen dugu, eta ondoren iruzkinetan hurrengo kodea injeztatzen dugu:

Horrela, biktima, objektu hori i kargatzeko saiatzean, gure zerbitzariari eskaera bat egingo dio bere saio cookieak eskaeran txertatuz. Ondoren, informazio hau gure zerbitzarian jasoko dugu, hurrengo irudian ikusten dugun bezala:

Berriro behatzen dugu Base64-en kodifikatuta dagoen testu-katea dela, hurrengo formatuan:

"Zerbitzariak eskaera asko egiten ditugunean blokeatzen gaituenez, hash hau crackeatu dezakegu hashcat erabiliz rockyou.txt bezalako hiztegi bat erabiliz:"

Irudian ikusten dugun bezala, hash-a apurtu dugu eta biktimaren pasahitza lortu dugu.

Pasahitzaren aldaketan errorea

Pasahitzaren aldaketa prozesuaren logikan akatsak identifikatzea posible da, batez ere erabiltzaile batek bere pasahitza ahazten duenean eta posta elektronikoz aldaketa bat eskatzen duenean. Kasu honetan, pasahitza ahaztu duen erabiltzailearen lotutako postara esteka bat bidaltzen da, pasahitza berria aldatzeko aukera emanez. Hala ere, estekan klik egiterakoan egiten den eskaerak hurrengo parametroak ditu gorputzean:

Ikusten dugun bezala, erabiltzailea adierazten duen parametro bat dago, eta hau erabiltzaileak alda dezake. Gure erabiltzailearen ordez, biktimaren erabiltzaile izena idazten badugu, biktimaren pasahitza aldatzea lortzen dugu bere pasahitz eguneratua ezagutzen ez dugula:

Pasahitz aldaketa pozoitzea

Hau ulertzeko ahultasuna, lehenik eta behin pasahitzaren aldaketa prozesua nola funtzionatzen duen azaltzea funtsezkoa da. Oro har, erabiltzaile batek bere pasahitza ahazten duenean, zerbitzariak lotura bat bidaltzen du lotutako posta elektronikora, pasahitza berrezartzeko orri batera bideratzen duena. Erabiltzaileak bere kontura sartu ezin duenez, ez du saio-tokensik erabil dezake identitatea egiaztatzeko. Horregatik, zerbitzariak maiz erabilera bakarreko token bat sortzen du eta token hau pasahitzaren aldaketa orrira bideratzen duen loturan txertatzen du. Token honen segurtasuna erabiltzaileak bere posta elektronikora sarbidea duen bakarrik lotura eta, beraz, tokenera sar daitekeela oinarritzen da, eta, behin erabilita, tokenak bere balioa galtzen du.

Hala ere, sistema hau konprometitzeko aukera bat dago. Pasahitzaren aldaketa lotura sortzean, zerbitzariak URLan host eta tokenaren parametroa barne hartu behar ditu:

Host beti bera izan behar da, webgune legitiimora dagokiona. Hala ere, kasu batzuetan, zerbitzariak URLaren hosta eskaeraren Host goiburuko balioaren arabera zehazten du, bezeroak "emaila bidali" botoian klik egiten duenean, eta goiburu hori erasotzaile batek manipulatu dezake. Horrela, aktore gaizto batek zerbitzaria engainatu dezake biktimari esteka gaizto bat duen email bat bidaltzeko.

Eguna egiteko, erasotzaileak "pasahitza ahaztu dut" botoian klik egin behar du eta biktimaren erabiltzaile izena berea ordezkatu. Ondoren, proxy tresna bat erabiliz, BurpSuite adibidez, eskaera atzeman eta Host burua aldatzen du, zerbitzariaren hosta bere kontrolpeko zerbitzari baten URLarekin ordezkatuz:

Horrela, zerbitzariak biktimaren posta elektronikora pasahitza aldatzeko esteka bat bidaliko du, token temporala barne. Hala ere, esteka horren hosta erasotzaileari dagokio. Biktimak esteka horretan klik egiten badu, erasotzailearen zerbitzariari eskaera bat bidaliko dio, honek eskaera atzeman eta token temporala harrapatuko du. Horrela, erasotzaileak biktimaren pasahitza alda dezake eta bere erabiltzaile kontua eskuratu.

"Ezin da estandarrak ez diren buruak onartzen dituzten zerbitzariak aurkitu, eta testuinguru honetan, Host burua lotura sortzeko erabiltzean, zerbitzariak X-Forwarded-Host bezalako buruak erabil ditzake:"

Nola prebenitu autentifikazio erasoak

Autentifikazio mekanismoak babestea funtsezkoa da webgune bat eta erabiltzaileen datuak arriskuan jar ditzaketen ahultasunak saihesteko. Hona hemen neurri garrantzitsuenak:

Arreta kredentzialekin: Inoiz ez bidali saio datuak konexio ez enkriptatuen bidez. Inplementatu HTTPS eta automatikoki birbideratu HTTP eskaerak. Auditu gunea erabiltzaile izenak edo posta elektronikoak agerian ez uzteko.
Erabiltzaileen menpe ez egon: Erabiltzaileek segurtasun-politika zorrotzak saihesten dituzte. Pasahitz tradizionalen politikak ezartzea baino, pasahitzen indarraz denbora errealean feedbacka ematen duten pasahitz egiaztatzaileak erabiltzea eraginkorragoa da, adibidez zxcvbn liburutegia.
Erabiltzaile izenen enumerazioa saihestea: Errore mezu orokorren bidez, erabiltzaile baten existentziari buruzko pista ematea saihestu, erantzun denborak eta HTTP kode berdinak erabiliz.
Indarrezko erasoei aurre egiteko babesa: IP helbide bakoitzeko saio hasierako saiakuntzen kopuruan muga ezarri eta hainbat saiakuntza oker egin ondoren CAPTCHA erabili. Honek erasotzaileek indarrezko erasoei modu eraginkorrean aurre egitea zailtzen du.
Logika egiaztapena: Autentifikazio logika arretaz aztertu behar da akatsik edo posible diren saihespenik ez dagoela ziurtatzeko, horiek ustiatu daitezkeenak.
Gehigarri funtzioen arreta: Pasahitzak berreskuratzeko funtzioak ere ahulak dira, beraz, nagusiki saioa hasi bezain segurua izan behar dute.
Multifaktore autentifikazioa (2FA): 2FA aplikazio edo gailu espezifikoak erabiliz ezartzea SMS edo posta bidezko kodeen bidalketaren antzeko metodoak baino seguruagoa da. 2FA logika auditatu, saihestu ez dadin.