Este artigo xestionará as coñecidas vulnerabilidades de OAuth. Os lectores tamén aprenderán a implementar a autorización segura e segura na aplicación web.
OAuth é un protocolo fiable, pero o seu grao de seguridade depende en gran medida da conciencia dos desenvolvedores web ao implementar a autorización. Isto fai que este tema sexa moi importante para profesionais de seguridade da información. Necesitan proporcionar un alto nivel de protección de contas dos seus usuarios. É hora de familiarizarse con practicantes efectivos que axudarán a reducir o perigo de pobres de venda de OAuth.
IntroduciónO protocolo de OAuth 2.0 é actualmente amplamente utilizado en varias aplicacións. Usalo, unha interface de usuario conveniente está dispoñible, máis fácil de autenticación e autorización en comparación cos métodos tradicionais para introducir o nome de usuario e o contrasinal. Coa implementación adecuada e reflexiva, o protocolo de OAuth será máis seguro que a autorización tradicional, xa que os usuarios non necesitan compartir os seus datos de contabilidade cunha aplicación de terceiros para acceder a un recurso específico. Os usuarios a miúdo prefiren iniciar sesión usando as súas contas de Google, Facebook ou LinkedIn, no canto de crear unha nova conta cada vez que precisa rexistrarse nalgún sitio web. Así, o protocolo de OAuth simplifica moito a nosa vida.
En xeral, os populares provedores de servizos de OAuth son moi fiables. Inicie sesión con Google ou a conta de Facebook inspira un certo sentido de seguridade e é correcto. O protocolo é probado coidadosamente por expertos. Todas as vulnerabilidades dispoñibles sempre están corrixidas rapidamente polo equipo de desenvolvedores. Non obstante, vale a pena notar que a sensación de seguridade completa pode ser falsa.
Os provedores de servizos de OAuth deixaron aos desenvolvedores de aplicacións moitos motivos para afrontar a seguridade dos seus programas. De feito, o servizo OAuth protexido inicialmente, incorrectamente implementado no proceso da súa instalación, pode converterse nun destino fácil para os intrusos. Esa preocupación levará ao roubo de datos persoais dos usuarios.
A continuación, debes considerar as vulnerabilidades máis comúns atopadas en aplicacións de terceiros que implementan o protocolo de OAuth para autorizar aos seus usuarios. Cómpre lembrar que o propio protocolo é seguro e fiable. Só despois da implementación incorrecta, faise vulnerable aos ataques de hackers.
Oauth Tockey roubo usando o encabezado do referenteCando a solicitude solicita a autorización en nome do usuario no OAuth Server, unha persoa recibe o código para ingresar e enviar de volta ao servidor para o seu control posterior. Se durante o traballo o usuario será redirixido a outra páxina, o código verase no encabezado "Referer" da solicitude HTTP. Deste xeito, o código caerá no sitio web externo, que ameazará os datos do usuario rexistrados no servidor OAuth.
Nota: o encabezado do referer é un encabezado de consulta HTTP, transmite o servidor URL desde o que se envía a solicitude.
Para suavizar as consecuencias desta vulnerabilidade, o desarrollador debe asegurarse de que a súa aplicación web non contén inxeccións HTML. Se se detectaron as inxeccións, o atacante pode configurar facilmente a etiqueta de imaxe no seu servidor web e atopar un xeito de redireccionar o usuario nel. Deste xeito, terá a oportunidade de roubar o código do encabezado "Referer" da solicitude HTTP.
Oauth tockey roubo usando o parámetro redirect_uriA aplicación inicia o proceso de autorización enviando unha solicitude ao servidor OAuth:
https://www.example.com/signin/authorize? up....]&redirect_uri=htppps://demo.example.com/loginsuccessful.
A consulta sempre contén o parámetro "redirect_uri" usado polo servidor OAuth para enviar tokens á aplicación despois de que o usuario deu o seu consentimento. Se o valor deste parámetro non está controlado ou non está marcado, o atacante pode facilmente cambialo e redireccionar a solicitude ao seu sitio web, onde usa un programa especial para procesar o token e acceder a un recurso limitado.
https://www.example.com/signin/authorize? up....]&redirect_uri=htppps://localhost.evil.com.
Ás veces están bloqueados URLs similares. O atacante pode redireccionar os datos recibidos sobre o URL aberto, así:
https://www.example.com/oauth20_authorize.srf? up.úrx ion_.[&redirect_uri=htppps://accounts.google.com/backtouthsubtarget?next=httpset://evil.com.
Ou este:
https://www.example.com/auth2/Authorize? [...]% irect_uri = https% 3a% 2F% 2fApps.facebook.com% 2Fattacker% 2F.
Ao implementar OAuth, nunca pode incluír dominios enteiros na lista branca. Só se deben engadir algúns URL a "redirect_uri" non redirixido unha solicitude para abrir redirección.
Falsificación de solicitudes de transversalA falsificación dunha solicitude de interese pode ocorrer cando un atacante consegue facer a vítima para facer clic na súa ligazón e, así, xerar unha solicitude de que non ía xerar. A falsificación das solicitudes de liña transversal adoita ser suavizada co token CSRF, que está asociado coa sesión de usuario. Axuda á solicitude a comprobar a persoa dunha persoa que enviou a solicitude. O parámetro "Estado" no protocolo de OAuth serve como token CSRF.
Paga a pena ver como se realiza o ataque CSRF en OAuth e como o parámetro "Estado" pode usarse para mitigar os efectos da vulnerabilidade.
Hacker abre unha aplicación web e lanza o proceso de autorización para acceder ao fornecedor de servizos usando OAuth. A solicitude solicita que un fornecedor de servizos poida acceder a que hai que proporcionar. Hacker será redirixido ao sitio web do fornecedor de servizos, onde adoita ter que introducir o seu nome de usuario e contrasinal para autorizar o acceso. Pola contra, o hacker colle e impide esta solicitude e salva a súa URL. O hacker dalgún xeito fai que a vítima abra esta URL. Se a vítima entrou no sistema do fornecedor de servizos usando a súa conta, entón as súas credenciais usaranse para emitir un código de autorización. O código de autorización intercambia o acceso ao token de acceso. Agora a conta de hacker na aplicación está autorizada. Pode acceder á conta da vítima.
Entón, como podo evitar esta situación usando o parámetro "Estado"?
A aplicación debe crear un valor que estea baseado na conta de orixe (por exemplo, use a chave de hash de sesión de usuario). Non é tan importante o que é, o principal é que o valor é único e xerado usando información privada sobre o usuario orixinal. Está asignado ao parámetro "Estado".
Este valor transmítese ao fornecedor de servizos ao redireccionar. Agora o hacker invita á vítima a abrir a URL, que conservou.
O código de autorización emítese e envíase de novo ao cliente na sesión xunto co parámetro "Estado".
O cliente xera un valor de parámetro baseado nunha información de sesión e compárao co valor "Estado", que foi enviado desde a solicitude de autorización ao fornecedor de servizos. Este valor non coincide co parámetro "Estado" da consulta, xa que se xerou só en función da información sobre a sesión actual. Como resultado, o sistema obtido non é aceptado polo sistema.
Outras vulnerabilidades detectadas ao implementar OAuth inclúen a capacidade de realizar XSS (scripting de sitio web) usando o parámetro "redirect_uri", a configuración de clave privada de OAuth (a clave pode obterse ás veces cando se descompila unha aplicación móbil) e a violación da regra do código de autorización O código de autorización pode ser usado máis dunha vez para emitir múltiples tokens de acceso). Estas vulnerabilidades son menos comúns que os descritos anteriormente, pero non os fai menos perigosos. O desarrollador debería coñecer todas as prácticas necesarias para garantir o funcionamento fiable da súa aplicación web.
O autor do artigo traducido: Simon Saliba.
Importante! Información exclusivamente para fins académicos. Por favor, cumpra a lexislación e non aplique esta información con fins ilegais.
Material máis interesante sobre CISOCLUB.RU. Subscríbete a Estados Unidos: Facebook | VK | Twitter | Instagram | Telegram | Zen | Mensaxeiro | ICQ Novo | YouTube | Pulse.