Ky artikull do të merret me dobësitë e njohura të OAUT-it. Lexuesit gjithashtu do të mësojnë se si të zbatojnë autorizimin e sigurt dhe të sigurt në aplikacionin Web.
Oauth është një protokoll i besueshëm, por shkalla e sigurisë e saj varet kryesisht nga ndërgjegjësimi i zhvilluesve të uebit gjatë zbatimit të autorizimit. Kjo e bën këtë temë jashtëzakonisht të rëndësishme për profesionistët e sigurisë së informacionit. Ata duhet të ofrojnë një nivel të lartë të mbrojtjes së llogarive të përdoruesve të tyre. Është koha për t'u njohur me praktikuesit efektivë të cilët do të ndihmojnë në zvogëlimin e rrezikut të shitjes së dobët të oauthit.
PrezantimiProtokolli i OAUT 2.0 është përdorur gjerësisht në aplikacione të ndryshme. Duke e përdorur atë, një ndërfaqe e përshtatshme e përdoruesit bëhet e disponueshme, autentifikim dhe autorizim më i lehtë në krahasim me metodat tradicionale për të hyrë në emrin dhe fjalëkalimin. Me zbatimin e duhur dhe të zhytur në mendime, protokolli i OAuth do të jetë më i sigurt se autorizimi tradicional, pasi përdoruesit nuk kanë nevojë të ndajnë të dhënat e tyre të kontabilitetit me një aplikim të palës së tretë për të hyrë në një burim të caktuar. Përdoruesit shpesh preferojnë të hyjnë duke përdorur llogaritë e tyre të Google, Facebook ose Linkedin, në vend që të krijojnë një llogari të re çdo herë që duhet të regjistroheni në ndonjë faqe interneti. Kështu, protokolli i OAuth thjesht e thjeshton jetën tonë.
Në përgjithësi, ofruesit e shërbimeve të njohura të OAUM janë shumë të besueshme. Identifikohu me llogarinë e Google ose Facebook frymëzon një ndjenjë të caktuar të sigurisë, dhe është e saktë. Protokolli është testuar me kujdes nga ekspertët. Të gjitha dobësitë në dispozicion janë gjithmonë të korrigjuara shpejt nga ekipi i zhvilluesit. Megjithatë, vlen të përmendet se ndjenja e sigurisë së plotë mund të jetë e rreme.
Oauth ofruesit e shërbimeve u larguan nga zhvilluesit e aplikacioneve shumë arsye për të luftuar sigurinë e programeve të tyre. Në fakt, shërbimi i mbrojtur fillimisht OAUT, i zbatuar gabimisht në procesin e instalimit të tij, mund të bëhet një objektiv i lehtë për ndërhyrës. Një preokupim i tillë do të çojë në vjedhjen e të dhënave personale të përdoruesve.
Tjetra, ju duhet të konsideroni dobësitë më të zakonshme të hasura në aplikacionet e palëve të treta që zbatojnë protokollin e OAuth për të autorizuar përdoruesit e tyre. Duhet të mbahet mend se vetë protokolli është i sigurt dhe i besueshëm. Vetëm pas zbatimit të gabuar, ai bëhet i prekshëm ndaj sulmeve të hakerëve.
Vjedhjet e oauth tocky duke përdorur header referuesKur aplikacioni kërkon autorizim në emër të përdoruesit në serverin OAUT, një person merr kodin për të hyrë dhe dërguar në server për kontrollin e tij të mëvonshëm. Nëse gjatë punës, përdoruesi do të ridrejtohet në një faqe tjetër, kodi do të shihet në headerin "referues" të kërkesës HTTP. Kështu, kodi do të bjerë në faqen e internetit të jashtme, e cila do të kërcënojë të dhënat e përdoruesit të regjistruar në serverin OAUT.
Shënim: Header Referuesi është një header pyetje http, ajo transmeton hostin URL nga i cili është dërguar kërkesa.
Për të zbutur pasojat e kësaj ndjeshmërie, zhvilluesi duhet të sigurojë që aplikacioni i saj i internetit të mos përmbajë asnjë injeksion HTML. Nëse injeksione janë zbuluar, sulmuesi lehtë mund të vendosë tagun e imazhit në serverin e saj të internetit dhe të gjejë një mënyrë për të përcjellë përdoruesin në të. Kështu, ai do të marrë mundësinë për të vjedhur kodin nga header "referues" i kërkesës HTTP.
Vjedhje e oauth tocky duke përdorur parametrin redirect_uriAplikimi fillon procesin e autorizimit duke dërguar një kërkesë në serverin OAUT:
https://www.example.com/signin/authorize ?[...]&redirect_uri=httpps://Demo.example.com/loginsuccessful.
Pyetja gjithmonë përmban parametrin "Redirect_uri" të përdorur nga serveri OAUT për të dërguar Tokens përsëri në aplikacionin pasi përdoruesi dha pëlqimin e tij. Nëse vlera e këtij parametri nuk është e kontrolluar ose nuk kontrollohet, sulmuesi lehtë mund ta ndryshojë atë dhe të përcjellë kërkesën në faqen e saj të internetit, ku përdor një program të veçantë për përpunimin e shenjës dhe të fitojë qasje në një burim të kufizuar.
https://www.example.com/signin/authorize ?[...]&redirect_uri=httpps://localhost.evil.com.
Ndonjëherë URL të ngjashëm janë të bllokuara. Sulmuesi mund të përcjellë të dhënat e marra në URL të hapur, si kjo:
https://www.example.com/oauth20_authorize.srf ?[ .[&redirect_uri=httpps://account.google.com/backtoouthsubtarget?next=httpset://evil.com.
Ose kjo:
https://www.example.com/oauth2/authorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2Fattacker% 2f.
Kur zbatoni oauth, ju kurrë nuk mund të përfshini domains të tërë në listën e bardhë. Vetëm disa URL duhet të shtohen në "Redirect_uri" jo të ridrejtuar një kërkesë për të hapur përcjelljen.
Falsifikim i Kërkesave KryesoreFalsifikimi i një kërkese intersight mund të ndodhë kur një sulmues arrin të bëjë viktimën të klikojë mbi lidhjen e tij dhe, kështu që të gjenerojë një kërkesë që ai nuk do të gjeneronte. Falsifikimi i kërkesave ndër-line zakonisht zbutet me shenjën CSRF, e cila është e lidhur me seancën e përdoruesit. Ndihmon aplikimin për të kontrolluar personin e një personi që ka dërguar kërkesën. Parametri "shteti" në protokollin e OAuth shërben si shenjë CSRF.
Vlen të shikosh se si është kryer sulmi i CSRF në OAuth dhe si parametri "shteti" mund të përdoret për të zbutur efektet e cenueshmërisë.
Hacker hap një aplikim në internet dhe nis procesin e autorizimit për të hyrë në ofruesin e shërbimit duke përdorur OAuth. Aplikacioni kërkon një ofrues shërbimi për qasje që duhet të sigurohet. Hacker do të ridrejtohet në faqen e internetit të ofruesit të shërbimit, ku zakonisht duhet të futni emrin dhe fjalëkalimin tuaj për të autorizuar qasjen. Në vend të kësaj, haker kap dhe parandalon këtë kërkesë dhe kursen URL-në e saj. Hacker disi shkakton viktimën të hapë këtë URL. Nëse viktima hyri në sistemin e ofruesit të shërbimit duke përdorur llogarinë e tij, atëherë kredencialet e saj do të përdoren për të nxjerrë një kod autorizimi. Kodi i autorizimit shkëmben qasje në token e qasjes. Tani llogaria e hakerëve në aplikacion është e autorizuar. Mund të hyjë në llogarinë e viktimës.
Pra, si mund ta parandaloj këtë situatë duke përdorur parametrin "shteti"?
Aplikimi duhet të krijojë një vlerë që është disi në bazë të llogarisë burimore (për shembull, përdorni çelësin e sesionit të përdoruesve). Nuk është aq e rëndësishme për atë që është, gjëja kryesore është se vlera është unike dhe gjenerohet duke përdorur informacione private në lidhje me përdoruesin origjinal. Ajo është caktuar në parametrin "shteti".
Kjo vlerë transmetohet në ofruesin e shërbimit kur të ridrejtojmë. Tani hakeri fton viktimën për të hapur URL-në, të cilën e mbajti.
Kodi i autorizimit lëshohet dhe kthehet tek klienti në seancën së bashku me parametrin "shteti".
Klienti gjeneron një vlerë të parametrave bazuar në një informacion të sesionit dhe e krahason atë me vlerën "shteti", e cila u kthye nga kërkesa e autorizimit në ofruesin e shërbimit. Kjo vlerë nuk përputhet me parametrin "shteti" në pyetjen, pasi ajo është krijuar vetëm në bazë të informacionit rreth seancës aktuale. Si rezultat, vlera e fituar nuk pranohet nga sistemi.
Vulnerabilities tjera të zbuluara gjatë zbatimit të OAUT-it përfshijnë aftësinë për të kryer XSS (Scripting Cross-site) duke përdorur parametrin "Redirect_uri", vendosja kryesore e çelësit OAuth (çelësi mund të merret ndonjëherë kur të dekompilizojë një aplikim të lëvizshëm) dhe shkeljen e rregullave të kodit të autorizimit (kur Kodi i autorizimit mund të përdoret më shumë se një herë për të lëshuar shenja të shumta të qasjes). Këto dobësi janë më pak të zakonshme se ato të përshkruara më sipër, por nuk i bëjnë ato më pak të rrezikshme. Zhvilluesi duhet të di të gjitha praktikat e nevojshme për të siguruar funksionimin e besueshëm të aplikacionit të saj në internet.
Autori i artikullit të përkthyer: Simon Saliba.
E rëndësishme! Informacion vetëm për qëllime akademike. Ju lutemi të pajtoheni me legjislacionin dhe mos e zbatoni këtë informacion për qëllime të paligjshme.
Materiale më interesante në Cisoclub.ru. Regjistrohu për ne: Facebook | Vk | Twitter | Instagram | Telegram | Zen | Messenger | ICQ New | YouTube | Impuls.