Autorização de nível de objeto, quebrado.

Dando continuação a vulnerabilidades em API.

Uma das vulnerabilidades mais prevalentes em APIs é a autorização de nível de objeto quebrado. As vulnerabilidades de ANOQ ocorrem quando um provedor de API permite que um consumidor de API acesse recursos que não estão autorizados a acessar. Se um endpoint de API não tiver controles de acesso em nível de objeto, ele não realizará verificações para garantir que os usuários possam acessar apenas seus próprios recursos.

Quando esses controles estiverem ausentes, o usuário A poderá solicitar com êxito os recursos do Usuário B.

As APIs usam algum tipo de valor, como nomes ou números, para identificar vários objetos. Quando descobrimos esses IDs de objeto, devemos testar para ver se podemos interagir com os recursos de outros usuários quando não autenticados ou autenticados como um usuário diferente. Por exemplo, imagine que estamos autorizados a acessar apenas o usuário Cloud Strife. Enviaríamos uma solicitação GET inicial para https:// exemplo.com/ api/v3/ users?id=5501 e receberíamos a seguinte resposta:

__________________________________________________________________

{

“id”: “5501”,

“first_name”: “Nuvem”,

“last_name”: “Conflito”,

“link”:”https://www.exemplo.com/user/strife.buster.97",

“name”: “Conflito na Nuvem”,

“dob”: “1997–01–31”,

“username”: “strife.buster.97”

}

___________________________________________________________________

Isso não representa nenhum problema, pois estamos autorizados a acessar as informações do Cloud. No entanto, se conseguirmos acessar as informações de outro usuário, haverá um grande problema de autorização.

Nessa situação, podemos verificar esses problemas usando outro número de identificação próximo ao ID do Cloud de 5501. Digamos que possamos obter informações sobre outro usuário enviando uma solicitação para https://exemplo.com/ api/ v3/ users?id=5502 e recebendo a seguinte resposta:

_______________________________________________________________

{

“id”: “5502”,

“first_name”: “Zack”,

“last_name”: “Justo”,

“link”:”https://www.exemplo.com/user/shinra-number-1",

“name”: “Zack Fair”,

“dob”: “2007–09–13”

“username”: “shinra-number-1”

}

_________________

Os IDs não indicam necessariamente que você encontrou uma falha. Para que o aplicativo seja vulnerável, ele deve falhar ao verificar se um determinado usuário só pode acessar seus próprios recursos.

Em geral, você pode testar falhas entendendo como os recursos de uma API são estruturados e tentando acessar recursos que você não deveria conseguir. Ao detectar padrões nos caminhos e parâmetros da API, você poderá prever outros recursos em potencial. Os elementos no textos seguintes nas seguintes solicitações de API devem chamar sua atenção, observe:

___________________________________________________________________

GET /api/resource/1

GET /user/account/find?user_id=15

POST /empresa/conta/Apple/saldo

POST /admin/pwreset/account/90

_____________________________________________________________

Nesses casos, você provavelmente pode adivinhar outros recursos em potencial, como o seguinte, alterando os valores:

_____________________________________________________________

GET /api/resource/3

GET /user/account/find?user_id=23

POST /empresa/conta/Google/saldo

POST /admin/pwreset/account/111

________________________________________________________________

Nesse exemplo simples, você executou um ataque simplesmente substituindo os números, ex: de 15 para 23. Se você conseguir acessar informações que não deveria ter autorização para acessar, você descobriu uma vulnerabilidade de Autorização de nível de objeto quebrado.

ESPERO QUE TENHAM GOSTADO, E FIQUEM AVONTADE PARA ME SEGUIR NAS REDES SOCIAIS. Estou no Instagram como @diego_o.santoss. https://www.instagram.com/invites/contact/?i=c8d7p6azzkvj&utm_content=gva5bro