A01:2021 - Broken Access Control

A01:2021 - Apurtutako Sarbide Kontrola

Celia Catalán


Webgune bateko sarbide-kontrolak erabiltzaile bati baliabide jakin batera sartzeko edo ekintza jakin bat egiteko baimena duen definitzen du. Kontrol hori horizontalki eta bertikalki egin daiteke:

  • Sarbide-kontrol bertikala: pribilegiorik gabeko erabiltzaile batek ezingo lituzke administratzaile erabiltzaile baten baliabideetara sartu.
  • Sarbide-kontrol horizontala: erabiltzaile batek, adibidez, banku-webgune batean, bere txartelak eta kontuak sar ditzake, baina ez beste erabiltzaileenak.

Nola galtzen da sarbide-kontrol hori?

Kontrol horrek behar bezala funtziona dezan, segurtasun neurriak ondo ezarri behar dira, eta ez da beti horrela izaten. Konfigurazio txarrak, softwarearen bertsio zaurgarriak edo segurtasun-diseinu txarrak sarbide-kontrol txarra eragin dezakete, eta horrela informazioaren konfidentzialtasuna, osotasuna eta erabilgarritasuna urratzen dira.

Sarbide-kontrola bertikal edo horizontal gisa sailkatzen dugun bezala, ahultasun horiek pribilegio bertikalak igotzea edo mugimendu horizontala eragin dezakete.


Pribilegio bertikalak igotzea

Pribilegioen igoera bertikala gertatzen da erasotzaile batek ahultasun bat baliatzen duenean bere sarbide-maila pribilegio baxuko erabiltzaile batetik (adibidez, erabiltzaile estandarra) rol pribilegiatuago batera igotzeko, hala nola administratzailea. Beste era batera esanda, sarbide-maila handiagoak dituzten erabiltzaileentzat soilik gorde behar diren funtzionalitate edo datuen kontrola lortzen duzu, aplikazioaren segurtasuna arriskuan jarriz. Hona hemen pribilegioak handitzearen adibide batzuk:
  • Administrazio panelera baimenik gabeko sarbidea.
  • Plataformaren erabiltzaile baten rola aldatzea.
  • Administratzailearen funtzionalitateetarako sarbidea (erabiltzaile bat ezabatu, erabiltzaile baten pasahitza aldatu...).

Mugimendu horizontala

Mugimendu horizontala sistemako erabiltzaile-kontu baterako sarbidea duen erasotzaile batek antzeko pribilegioak dituzten beste erabiltzaile-kontu batzuetarako sarbidea lortzen duenean gertatzen da. Mugimendu horizontal hori zuzenean erabiltzaile-kontu batera sar zaitezkeen edo pribilegiorik gabeko erabiltzaile horren funtzionalitate edo datuetara sartzeko gai bazara gertatzen da.

Mugimendu bertikala ez bezala, non erasotzaileak sistemaren barruan baimen handiagoak lortzen dituen, mugimendu horizontalak pribilegiorik gabeko beste kontu batzuk arriskuan jartzen ditu aplikazioan eraso-bektore berriak ezagutzeko. Hauek dira mugimendu horizontal horren adibide batzuk:

  • Sistemaren beste erabiltzaile baten kredentzialak aurkitzea.
  • Erabiltzaile-profilaren sarbide-kontrola aurreikus daitekeen ID batean oinarrituta.
  • Beste sistemaren erabiltzaileen fitxategietara sarbidea.


Eskala horizontaletik eskalatze bertikalera

Bi mugimendu mota hauek bereizten ditugula egia den arren, ohikoak dira pribilegioen igoera bertikala eragiten duten mugimendu horizontalen kasuak. Hau gertatzen da erasotzaile batek, mugimendu horizontaleko tekniken bidez, administrazio-pribilegioak dituen sistema-erabiltzaile baten sarbidea lortzen duenean. Adibidez, erasotzaile batek URLan erabiltzailearen IDa aldatzen badu beste erabiltzaile baten profilera sartzeko, mugimendu horizontal bat egingo luke. Hala ere, teknika hau erabiliz webgunearen erabiltzaile administratzaile batean sartzen zara azkenean.

Modu honetan ikusten dugu ez dela hain erraza pribilegioen igoera zer den eta zer den mugimendu horizontala antzematea, izan ere, egindako teknikaren edo erasoaren araberakoa ez da hainbeste, esandakoan lortutako emaitzaren arabera baizik. erasoa egin da.

Sarbide-kontrolaren ahuleziak

Aurreko atalean azaldu dugunez, pribilegioak igotzeko erasoen eta mugimendu horizontaleko erasoen artean erasoak sailkatzeko zailtasuna dela eta, atal honetan eraso desberdinak, nola egin eta lor daitekeen emaitza azaltzeari eutsiko diogu.


IDOR (objektu zuzeneko erreferentzia ez segurua)

IDOR sarbide-kontrolaren azpikategoria bat da, non erabiltzaileak alda daitezkeen parametroak erabiltzen diren baliabideak sartzeko. Adibide bat erabiltzailearen profileko botoi bat izango litzateke txataren historia deskargatzeko.

Botoi honek example.txt fitxategi bati eskaera egiten dio, baina parametro hau proxy baten bidez alda daiteke, beste erabiltzaile batzuen txat-historia atzitu ahal izateko.
Adibide honetan, gure erabiltzailearen txat-historia deskargatzen saiatzean, eskaera proxy batekin atzemanez, 2.txt fitxategi bati kontsulta egiten diola ikusiko dugu. GET eskaera honen ondoren erantzun hau lortzen dugu:


Hala ere, parametro hau aldagarria da, beraz, 2.txt hau 1.txt-rekin ordezkatzen badugu beste erabiltzaile baten txat-historia lortuko dugu, eta bertan bere pasahitza aurki dezakegu:


Babestu gabeko funtzionaltasuna

Oso eraso sinplea da eta zerbitzariaren sarbide-kontrol falta ia erabatekoa eskatzen du. Administratzaile baten baliabideak ezkutatuta dauden, baina babestuta ez dauden web-orriak aurki daitezke. Kasu horretan, baliabide hauek modu ezberdinetan aurki ditzakegu:

  1. Metodo bat robots.txt fitxategira atzitzea da. Fitxategi hau web orriaren erroan eskuragarri egon ohi da eta Google-k, Microsoft-eko bot-ek bisitatzeko baimena duten zein baliabide eta direktorioei buruzko informazioa dauka... Askotan ezkutuko edo administrazio-direktorioak aurki ditzakegu Disallow etiketapean, eta horrela kokapena agerian uzten dugu. Administrazio panelak edo fitxategi sentikorrenak:
  2. Ezkutuko direktorio mota hauek aurkitzeko beste iturri bat JavaScript kodea bera da. Ohikoa da programazio-lengoaia honen funtzioetan fitxategi eta direktorio sentikorren erreferentziak aurkitzea, hurrengo irudian ikusten dugun bezala:


Berriz ere, iturri hauetan aurki dezakegun informazioaren garrantzia izan arren, direktorio eta baliabide horietara pribilegiorik gabeko erabiltzaile gisa sartu nahi badugu, sarbide-kontrolik eza ezinbestekoa da.

Parametroetan oinarritutako sarbide-kontrola

Badaude beste kasu batzuetan erabiltzailearen baimenak erabiltzaileak alda ditzakeen gordetako balioetan oinarritzen diren, hala nola ezkutuko eremu batean, cookie bat edo aurrez zehaztutako balio batean kontsultak egiterakoan.

Adibide honetan, erabiltzailearen baimenak erabiltzailearen esku daude, nabigatzailean false balioa duen cookie bat erabiltzen baita. Cookie horren balioa aldatuz soilik baliabide sentikorrak atzi ditzakegu administratzaile-erabiltzailearen beharrik gabe:



Hurrengo adibidean beste kasu bat ikus dezakegu. Gure erabiltzailearekin posta elektronikoaren aldaketa bat egiterakoan, egindako eskaera eta proxy batekin lortutako erantzuna atzematen badugu, POST eskaeran, gure mezu elektroniko berria JSON formatuan bidaltzen ari garela ikusten dugu eta honako informazio hau jasotzen dugu, gainera, JSON formatua:


Goiko irudian ikusten den bezala, mezu elektronikoa aldatzean JSON erantzunean 1 balio duen roleid parametro bat jasotzen dugu. Eskaera egiterakoan, mezu elektronikoa soilik bidali beharrean 2 balio duen roleid parametro bat ere bidaltzen dugu, zerbitzariak balio hau itzultzen digula ikusten dugu, gure erabiltzailearen pribilegioak aldatu direla adieraziz:


Horrela, espero ez zuen zerbitzariari parametro bat bidaliz, gure erabiltzailearen pribilegioak aldatzea lortu genuen, erabiltzaile pribilegiatu bihurtuz.

Konfigurazio txarra

Konfigurazio txarreko kasuetan, URLaren arabera eskaerak mugatzen dituzten webguneak aurki daitezke, adibidez, erabiltzaileak URLra POST bat egin ez dezan. /admin/ezabatu. Hala ere, webgune honek URL berridazketa goiburuak erabiltzeko aukera ematen badigu, hala nola, X-Original-URL edo X-Rewrite-URL bezalako segurtasun-kontrol hauek saihestu ditzakegu.

Kasu honetan ikusten dugunez, URLra sartzeko mugatuta gaude /admin/delete?username=carlos, carlos erabiltzailea ezabatzeko aukera emango liguke. Baina orriaren root URLa sartuz, X-Original-URL goiburua erabiliz URL hori berridazteko, ikusiko dugu URL horretara sarbide-kontrol hau saihesteko gai garela:


Beste kasu batzuetan, orria prozesatzen duen metodoetan malgua bada, metodoaren eta URLaren arabera mugatuta badago, metodoa alda dezakegu eta horrela sarbide-kontrola saihestu. Adibide honetan, Carlos erabiltzailearen baimenak pribilegiorik gabeko erabiltzaile batekin aldatzen saiatzean, aldaketa hori egiteko baimenik ez dugula ikusten dugu:


Hala ere, web-orriaren malgutasuna dela eta, eskaera hori bera GET formatuan egin dezakegu, zerbitzariak zuzen prozesatzen du baina ez du sarbide-kontrola aplikatzen, beraz, segurtasun-kontrola saihestea lortzen dugu:


URLekin bat datozen desadostasunak

Karaktere kateak erabiliz URL batzuetarako sarbidea mugatzen duten orrialdeak ere badaude, baina ondoren URL berarekin "antzeko" emaitzak esleitzen dituzten barnean.

Adibidez, URL bat maiuskulaz idazten duzunean /ADMIN./EZABATZAILEA barnera birbideratzen du /admin/deleteuser, baina, karaktere-kate bera ez denez, sarbide-kontrola ez da aplikatzen. Udaberrian, adibidez, fitxategi batera sartzeko URL bat sartzean (luzapena duena), fitxategi hori aurkitzen ez bada, baliabide horretara ebazten da, baina luzapenik gabe, eta horrek kontrolaren saihespena ekar dezake. sarbidea:

/admin/deleteUser.anything → /admin/deleteUser

Kontuan izan behar da birbideratze hori lehenespenez gaituta dagoela 5.3 bertsioaren aurreko Spring bertsioetan.

Urrats anitzeko prozesua sarbide-kontrolik gabe

Ekintza jakin bat egiteko eskaera bat baino gehiago edo urrats bat baino gehiago dagoenean, hala nola erabiltzaile bat ezabatzea, baliteke eskaeraren bat behar bezala babestuta egotea bigarren edo hirugarren urratsak zaurgarriak diren bitartean.

Adibide honetan argi ikusten dugu erabiltzailearen pribilegioak handitzeko prozesu anitz hau. Pribilegiorik gabeko erabiltzaile batekin pribilegioak aldatzeko hasierako eskaera egitean, zerbitzariaren erantzuna jasoko dugu ekintza hori egiteko baimenik ez dugula adieraziz:




Hala ere, pribilegioak igotzeko prozesuarekin erabiltzaile pribilegiatu batekin jarraituko bagenu, berrespen-orri bat ikusiko genuke ekintza hori egin nahi dugula ziur gauden galdetuz.

Eskaera hau atzematen eta pribilegiorik gabeko erabiltzailearen cookiearekin eskaera bera egiten saiatzen bagara, ikusiko dugu ekintza hau egiteko aukera ematen duela, segurtasun kontrola alde batera utzita:




Garrantzitsua da kontuan izan behar dela askotan erabiltzaile administratzaile baten funtzionalitateak zeintzuk diren aldez aurretik ezagutzea mota honetako erasoak egin ahal izateko. Kasu honetan, erabiltzaile arrunt gisa ez genuke inoiz berrespen orri honetara sartu ahal izango, prozesua hasieratik blokeatuko luke eta.

Ahultasun hauek askoz errazago detektatzen dira aldez aurretik administratzaile erabiltzaile bat baduzu haien funtzioak aztertzeko. Hori dela eta, web-ikuskaritzetan ezinbestekoa izan ohi da bai pribilegiorik gabeko erabiltzailea eta baita pribilegiatua izatea ere.

Sarbide-kontrola Erreferentziaren goiburuan oinarrituta

Batzuetan, esaterako, azpiorrietarako sarbidea mugatzeko /admin/deleteUser, Erreferentearen goiburua egiaztatzen da URL nagusia /admin duen ikusteko. Modu honetan, zerbitzaria erabiltzailea goi-mailako erabiltzaile baten direktorio esklusibo batetik datorrela egiaztatzen saiatzen da. Hala ere, erabiltzaileak alda dezakeenez, sarbide-kontrol hori haustea ekar dezake.

Hurrengo kasuan, horixe ikusten dugu zehazki. Erreferentzian adieraziz eskaera aldez aurretik URL /admin-etik datorrena dela adieraziz (nahiz eta hori egia ez izan), sistemak erabiltzaile-baimenak aldatzea ahalbidetzen du pribilegiorik gabeko erabiltzaile-cookie bat erabiliz, web zerbitzariak soilik egiaztatzen duelako. Erreferentearen goiburua:


Mugimendu horizontalaren adibide sinpleak

Azkenik, mugimendu horizontaleko teknika erraz batzuk aurkezten ditugu. Oso errepikatzen den kasua normalean erabiltzailearen profilera sarbidea izan ohi da URLan bertan dagoen identifikatzaile baten bidez. Identifikatzaile hau aldatuz gero, beste erabiltzaileen profiletara sar gaitezke:


Hori ekiditeko, ohikoa da identifikatzaile hauek ausaz banatzea, asmatu ezin daitezen. Baina noizean behin identifikatzaile horren erreferentziak aurki daitezke webgunean nonbait.
Adibide honetan, Carlosek argitaratutako blog batera arakatzean, bere erabiltzaile-identifikatzailea blogaren URLan bertan aurkitzen dela ikus dezakegu:


Nahiko ohikoa den beste kasu bat birzuzenbideetan informazioa aurkitzea da. Baliabide batera sartu ezin dugunean, hala nola administratzaile panelera, zerbitzariak 302 kodea itzultzen du gu birbideratzeko, adibidez, orriaren errora. Hala ere, zenbaitetan, zerbitzariaren erantzuna atzematen badugu, birbideratzeko erantzunaren gorputzean bertan aurkitu dezakegu sartu nahi genuen baliabidearen HTML kode guztia:


Erremediazioa

Eraso hauek guztiak posible dira webgunearen sarbide-kontrol eskasa dela eta. Hori dela eta, sarbide-kontrol zuzena ezartzerakoan, printzipio hauek jarraitzea gomendatzen da:
  • Ez fidatu lausotzeaz soilik sarbide-kontrolerako.
  • Baliabide bat publikoki eskuragarri izateko xedea ez bada, lehenespenez ukatu baliabide horretarako sarbidea.
  • Ahal izanez gero, erabili sarbidea kontrolatzeko mekanismo bakarra aplikazio osorako.
  • Kode mailan, deklaratu baliabide bakoitzerako baimendutako sarbidea eta ukatu sarbidea lehenespenez.
  • Ikuskatu eta probatu sarbide-kontrolak behar bezala funtzionatzen dutela ziurtatzeko.
Itzuli blogera

Utzi iruzkin bat

Kontuan izan iruzkinak argitaratu aurretik onartu behar direla.