Aquest article tractarà les conegudes vulnerabilitats OAUTH. Els lectors també aprendran a implementar una autorització segura i segura a l'aplicació web.
Oauth és un protocol fiable, però el seu grau de seguretat depèn en gran mesura de la consciència dels desenvolupadors web a l'hora d'implementar l'autorització. Això fa que aquest tema sigui extremadament important per als professionals de la seguretat de la informació. Han de proporcionar un alt nivell de protecció de comptes dels seus usuaris. És hora de conèixer els professionals efectius que ajudaran a reduir el perill de pobres venent OAUTH.
PresentacióEl protocol OAUTH 2.0 s'utilitza actualment àmpliament en diverses aplicacions. Utilitzant-lo, una interfície d'usuari convenient està disponible, més fàcil d'autenticació i autorització en comparació amb els mètodes tradicionals per introduir el nom d'usuari i la contrasenya. Amb una implementació adequada i reflexiva, el protocol OAUT serà més segur que l'autorització tradicional, ja que els usuaris no necessiten compartir les seves dades de comptabilitat amb una aplicació de tercers per accedir a un recurs específic. Els usuaris sovint prefereixen iniciar sessió utilitzant els seus comptes de Google, Facebook o LinkedIn, en lloc de crear un compte nou cada vegada que necessiteu registrar-vos en algun lloc web. Per tant, el protocol OAuth simplifica enormement les nostres vides.
En general, els proveïdors de serveis populars de OAUTH són molt fiables. Inicieu sessió amb Google o el compte de Facebook inspira un cert sentit de seguretat i és correcte. El protocol està provat acuradament per experts. Totes les vulnerabilitats disponibles sempre es corregeixen ràpidament per l'equip de desenvolupadors. No obstant això, val la pena assenyalar que la sensació de seguretat completa pot ser falsa.
Els proveïdors de serveis OAUTH van deixar als desenvolupadors d'aplicacions moltes raons per contendre la seguretat dels seus programes. De fet, el servei OAuth inicialment protegit, implementat incorrectament en el procés de la seva instal·lació, es pot convertir en un objectiu fàcil per als intrusos. Aquesta preocupació conduirà al robatori de dades personals dels usuaris.
A continuació, haureu de considerar les vulnerabilitats més habituals trobades en aplicacions de tercers que implementin un protocol OAuth per autoritzar els seus usuaris. Cal recordar que el propi protocol és segur i fiable. Només després de la implementació incorrecta, es fa vulnerable als atacs de pirates informàtics.
OAUTH TOCKEY THOOFT utilitzant la capçalera de referènciaQuan l'aplicació sol·licita l'autorització en nom de l'usuari al servidor OAUTH, una persona rep el codi per introduir i enviar al servidor per a la seva posterior comprovació. Si durant el treball es redirigirà l'usuari a una altra pàgina, el codi es veurà a la capçalera "Referer" de la sol·licitud HTTP. Per tant, el codi caurà en el lloc web extern, que amenaçarà les dades d'usuari registrades al servidor OAUTH.
Nota: la capçalera de referència és una capçalera de consulta HTTP, transmet l'amfitrió d'URL des del qual s'envia la sol·licitud.
Per suavitzar les conseqüències d'aquesta vulnerabilitat, el desenvolupador ha d'assegurar-se que la seva aplicació web no conté cap injecció HTML. Si es van detectar les injeccions, l'atacant pot establir fàcilment l'etiqueta d'imatge al seu servidor web i trobar una manera de redirigir l'usuari. Per tant, obtindrà l'oportunitat de robar el codi de la capçalera "Referer" de la sol·licitud HTTP.
OAUTH TOCKEY THOOFT utilitzant el paràmetre Redirect_uriL'aplicació inicia el procés d'autorització enviant una sol·licitud al servidor OAuth:
https://www.example.com/signin/authorize?[...]?Tredirect_uri=httpps://demo.example.com/loginsuccessful.
La consulta conté sempre el paràmetre "Redirect_uri" utilitzat pel servidor OAuth per enviar fitxes de tornada a l'aplicació després que l'usuari va donar el seu consentiment. Si el valor d'aquest paràmetre no està controlat o no controlat, l'atacant pot canviar-lo fàcilment i redirigir la sol·licitud al seu lloc web, on utilitza un programa especial per processar el testimoni i accedir a un recurs limitat.
https://www.example.com/signin/authorize?[...]?redirect_uri=httpps://localhost.evil.com.
De vegades es bloquegen URL similars. L'atacant pot redirigir les dades rebudes a l'URL obert, així:
https://www.example.com/oauth20_authorize.srf?1.[&redirect_uri=httpps://accounts.google.com/backTouthsubtarget?next=httpset://evil.com.
O això:
https://www.example.com/oauth2/Authorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2FATTACKER% 2F.
Quan implementeu OAUT, no podeu incloure dominis sencers a la llista blanca. Només cal afegir unes poques URL a "redirect_uri" que no es redirigeix una sol·licitud per obrir la redirecció.
Falsa de les sol·licituds de línia creuadaEs pot produir una falsificació d'una petició de creuer quan un atacant aconsegueix fer que la víctima faci clic al seu enllaç i, per tant, per generar una sol·licitud que no anava a generar. La falsificació de les sol·licituds de línia creuada sol suavitzar-se amb el testimoni CSRF, que està associat a la sessió d'usuari. Ajuda a l'aplicació per comprovar la persona d'una persona que va enviar la sol·licitud. El paràmetre "Estat" del protocol OAUTH serveix com a testimoni de CSRF.
Val la pena veure com es realitza l'atac de la CSRF a Oauth i, com es pot utilitzar el paràmetre "Estat" per mitigar els efectes de la vulnerabilitat.
Hacker obre una aplicació web i llança el procés d'autorització per accedir al proveïdor de serveis mitjançant OAUTH. L'aplicació sol·licita un proveïdor de serveis a l'accés que cal proporcionar. Hacker es redirigirà al lloc web del proveïdor de serveis, on normalment necessiteu introduir el vostre nom d'usuari i contrasenya per autoritzar l'accés. En canvi, el hacker captura i impedeix aquesta sol·licitud i salva la seva URL. Hacker d'alguna manera fa que la víctima obrirà aquest URL. Si la víctima va entrar al sistema del proveïdor de serveis mitjançant el seu compte, llavors les seves credencials s'utilitzaran per emetre un codi d'autorització. El codi d'autorització intercanvia accés al testimoni d'accés. Ara s'autoritza el compte hacker de l'aplicació. Pot accedir al compte de la víctima.
Per tant, com puc evitar aquesta situació mitjançant el paràmetre "Estat"?
L'aplicació ha de crear un valor que s'associa d'alguna manera en el compte d'origen (per exemple, utilitzeu la tecla Hash de sessió d'usuari). No és tan important el que és, el més important és que el valor és únic i generat mitjançant informació privada sobre l'usuari original. Està assignat al paràmetre "Estat".
Aquest valor es transmet al proveïdor de serveis quan es redirigeix. Ara, el hacker convida a la víctima a obrir l'URL, que va conservar.
El codi d'autorització s'emet i s'envia de nou al client a la sessió juntament amb el paràmetre "Estat".
El client genera un valor de paràmetre basat en una informació de sessió i la compara amb el valor "Estat", que es va enviar de nou de la sol·licitud d'autorització al proveïdor de serveis. Aquest valor no coincideix amb el paràmetre "Estat" de la consulta, ja que s'ha generat només a partir de la informació sobre la sessió actual. Com a resultat, el sistema obtingut no accepta el valor obtingut.
Altres vulnerabilitats detectades en la implementació d'OAUT inclouen la possibilitat de realitzar XSS (scripting de lloc transversal) utilitzant el paràmetre "Redirect_uri", la configuració de la clau privada OAUTH (de vegades es pot obtenir la clau quan es descompiureu una aplicació mòbil) i la regla de l'autorització de la infracció de la norma (quan El codi d'autorització es pot utilitzar més d'una vegada per emetre múltiples fitxes d'accés). Aquestes vulnerabilitats són menys comunes que les descrites anteriorment, però no les fa menys perilloses. El desenvolupador ha de conèixer totes les pràctiques necessàries per garantir un funcionament fiable de la seva aplicació web.
L'autor de l'article traduït: Simon Saliba.
Important! Informació únicament per a finalitats acadèmiques. Si us plau, compleixi amb la legislació i no apliqueu aquesta informació amb finalitats il·legals.
Material més interessant a Cisoclub.ru. Subscriviu-nos a nosaltres: Facebook | Vk | Twitter | Instagram | Telegrama | Zen | Missatgera ICQ NOU | Youtube | Pols.