Ĉi tiu artikolo traktos la bonkonatajn oauth-vulnerabilidades. Legantoj ankaŭ lernos kiel efektivigi sekuran kaj sekuran rajtigon en la retejo.
OAuth estas fidinda protokolo, sed ĝia grado de sekureco plejparte dependas de la konscio pri retejaj programistoj kiam efektivigas rajtigon. Ĉi tio faras ĉi tiun temon ekstreme grava por informaj sekurecaj profesiuloj. Ili bezonas doni altan nivelon de protekto de kontoj pri siaj uzantoj. Estas tempo konatiĝi kun efikaj praktikantoj, kiuj helpos redukti la danĝeron de kompatinda vendado de OAuth.
EnkondukoProtokolo de OAuth 2.0 estas nuntempe vaste uzata en diversaj aplikaĵoj. Uzante ĝin, konvena uzantinterfaco disponeblas, pli facila aŭtentokontrolo kaj rajtigo kompare kun tradiciaj metodoj por eniri la salutnomon kaj pasvorton. Kun taŭga kaj pensema efektivigo, la protokolo de OAuth estos pli sekura ol tradicia rajtigo, ĉar uzantoj ne bezonas dividi siajn kontadajn datumojn per tria aplikaĵo por aliri specifan rimedon. Uzantoj ofte preferas ensaluti per siaj kontoj de Google, Facebook aŭ LinkedIn, anstataŭ krei novan konton ĉiufoje kiam vi bezonas registriĝi pri iu retejo. Tiel, la protokolo de OAuth ege simpligas niajn vivojn.
Enerale, popularaj provizantoj de OAuth estas tre fidindaj. Ensalutu per Google aŭ Facebook-konto inspiras certan senton de sekureco, kaj ĝi estas ĝusta. La protokolo estas zorge testita de spertuloj. Ĉiuj disponeblaj vulnerabilidades estas ĉiam rapide korektitaj de la programisto teamo. Tamen, indas noti, ke la sento de kompleta sekureco povas esti falsa.
OAuth Service Provizantoj lasis aplikaĵajn programistojn multajn kialojn por aserti la sekurecon de iliaj programoj. Fakte, la komence protektita servo OAuth, malĝuste efektivigita en la procezo de ĝia instalado, povas iĝi facila celo por entruduloj. Tia maltrankvilo kondukos al la ŝtelo de personaj datumoj de uzantoj.
Poste, vi devas konsideri la plej oftajn vundeblojn renkontitaj en triaj aplikoj, kiuj efektivigas protokolon de OAuth por rajtigi siajn uzantojn. Oni devas memori, ke la protokolo mem estas sekura kaj fidinda. Nur post malĝusta efektivigo, ĝi fariĝas vundebla al hacker-atakoj.
Ŝtela ŝtelo de oauth uzanta la ribelulonKiam la apliko petas rajtigon nome de la uzanto ĉe la OAuth-servilo, persono ricevas la kodon por eniri kaj resendi al la servilo por sia posta ĉeko. Se dum la laboro la uzanto estos redirektita al alia paĝo, la kodo videblas en la "referedor" kaplinio de la HTTP-peto. Tiel, la kodo falos sur la eksteran retejon, kiu minacas la uzanto-datumojn registritajn en la OAuth-servilo.
Noto: La header-kaploko estas HTTP-konsulto, ĝi transdonas la URL-gastiganton, de kiu la peto estas sendita.
Por moligi la konsekvencojn de ĉi tiu vundebleco, la ellaboranto devas certigi, ke ĝia ttt-aplikaĵo ne enhavas iujn HTML-injektojn. Se la injektoj estis detektitaj, la atakanto povas facile agordi la bildan etikedon al sia retservilo kaj trovi manieron redirekti la uzanton pri ĝi. Tiel, li ricevos la okazon ŝteli la kodon de la "referedor" kaplinio de la HTTP-peto.
Ŝtelo de oauth tockey per la parametro de redirect_uriLa apliko komencas la rajtigan procezon sendante peton al la OAuth-servilo:
https://www.example.com/signin/authorize?[...]&dredirect_uri=httpps://demo.example.com/logucesful.
La konsulto ĉiam enhavas la parametron "redirect_uri" uzata de la OAuth-servilo por sendi al la aplikaĵo post kiam la uzanto donis sian konsenton. Se la valoro de ĉi tiu parametro ne estas kontrolata aŭ ne kontrolita, la atakanto povas facile ŝanĝi ĝin kaj redirekti la peton al ĝia retejo, kie ĝi uzas specialan programon por prilabori la ĵeton kaj aliri aliron al limigita rimedo.
https://www.example.com/signin/authorize?[...]&redirect_uri=httpps://localhost.evil.com.
Foje similaj URL-oj estas blokitaj. La atakanto povas redirekti la ricevitajn datumojn pri la Open URL, tiel:
https://www.example.com/oauth20_authorize.srf?[...
Aŭ ĉi tio:
https://www.example.com/oauth2/Authorize?
Kiam vi efektivigas OAUT-ojn, vi neniam povas inkluzivi tutajn domajnojn en la blanka listo. Nur kelkaj URL-oj estu aldonitaj al "redirect_uri" ne redirektis peton por malfermi alidirektilon.
Falsado de transversaj petojForgeso de interparola peto povas okazi kiam atakanto sukcesas fari la viktimon klaki sur lian ligilon kaj, tiel, por generi peton, ke li ne generos. Malfeliĉo de transversaj petoj estas kutime mildigita per la CSRF-token, kiu estas asociita kun la uzanto-sesio. I helpas la peton kontroli la personon de persono, kiu sendis la peton. La "ŝtata" parametro en la OAuth-protokolo servas kiel CSRF-signo.
Indas vidi, kiel la CSRF-atako efektivigas OAuth kaj ĉar la "ŝtata" parametro povas esti uzata por mildigi la efikojn de vundebleco.
Hacker malfermas ttt-aplikaĵon kaj lanĉas la rajtigan procezon por aliri la servan provizanton per OAuth. La apliko petas servan provizanton aliri, kiu devas esti provizita. Hacker estos redirektita al la serva provizanto retejo, kie vi kutime devas eniri vian salutnomon kaj pasvorton por rajtigi aliron. Anstataŭe, la hacker kaptas kaj malhelpas ĉi tiun peton kaj ŝparas ĝian URL. Hacker iel igas la viktimon malfermi ĉi tiun URL. Se la viktimo eniris la sistemon de provizanto per sia konto, tiam ĝiaj akreditaĵoj estos uzataj por eldoni rajtigan kodon. La rajtiga kodo interŝanĝas aliron al la aliro. Nun la hacker-konto en la aplikaĵo estas rajtigita. I povas aliri la konton de la viktimo.
Do, kiel mi povas malhelpi ĉi tiun situacion per la "ŝtata" parametro?
La apliko devas krei valoron, kiu iel baziĝas sur la fonto-konto (ekzemple, uzu la uzantan sesion hash-ŝlosilon). Ne gravas kio ĝi estas, la ĉefa afero estas, ke la valoro estas unika kaj generita per privata informo pri la origina uzanto. I estas asignita al la "ŝtata" parametro.
Ĉi tiu valoro estas transdonita al la serva provizanto kiam redirektas. Nun la hacker invitas la viktimon malfermi la URL, kiun li retenis.
La rajtiga kodo estas eldonita kaj resendita al la kliento en la sesio kune kun la "ŝtata" parametro.
La kliento generas parametran valoron bazitan sur sesia informo kaj komparas ĝin kun la "ŝtata" valoro, kiu estis sendita reen de la rajtiga peto al la serva provizanto. Ĉi tiu valoro ne kongruas kun la "ŝtato" parametro en la konsulto, ĉar ĝi estis generita nur surbaze de informoj pri la nuna sesio. Rezulte, la akirita valoro ne estas akceptita de la sistemo.
Aliaj vundeblecoj detektitaj kiam efektivigado de OAuth inkludas la kapablon plenumi xss (inter-reteja skripto) uzante la parametron "redirect_uri", la OAuth-privata ŝlosila agordo (la ŝlosilo foje povas esti ricevita kiam malkonstrui moveblan aplikaĵon) kaj rajtiga kodo regulo de malobservo (kiam La rajtiga kodo povas esti uzata pli ol unufoje por eldoni plurajn alirajn signojn). Ĉi tiuj vundeblecoj estas malpli oftaj ol tiuj priskribitaj supre, sed ĝi ne malpliigas ilin. La ellaboranto devas scii ĉiujn necesajn praktikojn por certigi fidindan funkciadon de ĝia retejo.
La aŭtoro de la artikolo tradukita: Simon Saliba.
GRAVA! Informoj nur por akademiaj celoj. Bonvolu plenumi leĝaron kaj ne apliki ĉi tiun informon pri kontraŭleĝaj celoj.
Pli interesa materialo pri Cisoclub.ru. Abonu nin: Facebook | Vk | Twitter | Instagram | Telegramo | Zen | Messenger | ICQ New | YouTube | Pulso.