Insecure Direct Object Reference (IDOR)
A simples, mas amplamente encontrada, vulnerabilidade Insecure Direct Object Reference acontece quando um identificador é usado para acesso a um dado interno cujo acesso a ele não possui políticas de segurança aplicadas de forma adequada.
Em termos menos técnicos, quando um usuário qualquer pode visualizar dados diversos a que ele não deveria ter acesso simplesmente mudando o ID de referência a estes dados.
A OWASP, já tão conhecida pelos leitores do blog, categorizou a vulnerabilidade como a quarta mais comum entre o Top 10 de 2013. Já em 2017, ela foi incorporada na categoria A5: Broken Access Control, o que faz todo sentido.
A vulnerabilidade é utilizada normalmente para enumeração de dados da aplicação, mas pode conceder acesso a recursos e procedimentos não autorizados caso a aplicação não possua controles de acesso efetivos a áreas restritas.
Como funciona:
A forma mais comum de referenciar dados em uma aplicação é utilizando IDs. Os IDs podem ser implementados para referenciar um usuário, um produto, uma transação, uma notícia, etc. Normalmente, este tipo de dado pode ser encontrado diretamente na URL que se está acessado, por exemplo:
https://www.exemplo.com.br/user.php?id=346
https://www.exemplo.com.br/transacao.php?id=2020195354
https://www.exemplo.com.br/produto.php?id=135
https://www.exemplo.com.br/noticia.php?id=20
Manipulando a numeração do ID destas URLs devemos conseguir acesso a outros dados da aplicação DE ACORDO COM AS POLÍTICAS DE ACESSO IMPLEMENTADAS.
Por exemplo:
Em portais de notícias, trocar o ID da URL de notícias de 20 para 21 não apresenta qualquer tipo de vulnerabilidade, visto que todos tem acesso a visualizar as notícias do portal.
Imagine que uma área de assinantes é implementada e a notícia 21 só pode ser acessada por assinantes.
Caso um usuário normal, sem assinatura, conseguir acesso a essa notícia simplesmente alterando a URL a vulnerabilidade se evidencia.
Em casos ainda mais críticos, alterar o campo ID de usuário, como no primeiro exemplo citado, e conseguir acesso aos dados de outra pessoa torna a vulnerabilidade ainda mais crítica.
Para não ficarmos apenas na teoria eis um exemplo real da vulnerabilidade, por motivos óbvios, suprimimos os dados da aplicação:
A primeira requisição foi realizada obtendo dados do nosso usuário teste a uma aplicação real:
Já nesta segunda requisição, a manipulação do ID do usuário retornou dados de uma outra pessoa existente na plataforma.
Neste caso, com o uso de um ID de numeração simples a implementação de um controle efetivo de acesso aos dados impediria o acesso não autorizado aos dados de outro usuário pela manipulação do ID na requisição.
Lembramos que nem sempre a referência a um objeto se dá por números.
Os impactos desta vulnerabilidade vão além da enumeração de dados. Existem casos onde operações de deleção de usuários, modificação de informações e outras operações são realizadas internamente na aplicação por meio de requisições utilizando este mecanismo. Algumas páginas de administração também podem utilizar este meio de identificação para serem acessadas e em casos sem um controle efetivo de acesso pode possibilitar que atacantes realizem ações não autorizadas.
Mitigação
Como muito foi falado no artigo, a implementação correta de meios de controle de acesso são suficientes para impedir o acesso a informações sensíveis.
Estes controles devem levar em consideração os dados e recursos que cada usuário, com seus respectivos privilégios, devem ter acesso dentro da aplicação.
Também é aconselhado a utilização de Hashes para identificação do recurso ao invés de numeração.
Por exemplo:
www.exemplo.com.br/usuario.php?id=1354
Poderia receber um hash baseado em alguma informação do usuário
www.exemplo.com.br/usuario.php?id=684ff997e59f38d9fe7620280889ed13
Conclusão
A vulnerabilidade é simples e bastante recorrente e por isso pode ser encontrada entre as Top 10 vulnerabilidades da OWASP. A sua mitigação por meio de implementação de outros tipos de identificadores difíceis de serem "adivinhados" é relativamente simples, mas a mitigação por meio de controle de acesso pode não ser. Em ambientes complexos com vários recursos disponíveis pode tornar difícil a delimitação dos privilégios e dados a que todos os usuários devem ter acesso, e mesmo que isto esteja bem desenhado, a falha humana pode existir e um desenvolvedor esquecer de limitar o nível de acesso a alguma parte da aplicação.
Você já conseguiu acesso a algum recurso em uma página que não deveria ter acesso? Conta pra gente....
E para você que tem uma página na internet, mas não sabe se seus níveis de acesso estão bem implementados e suscetíveis a este ataque, realizamos este tipo de verificação entre nossos produtos (Pentest, blindagem,...). Para saber mais, entre em contato conosco (https://www.siteblindado.com/contato/).
Referências:
https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
https://owasp.org/www-chapter-ghana/assets/slides/IDOR.pdf
https://portswigger.net/web-security/access-control/idor
https://www.acunetix.com/blog/web-security-zone/what-are-insecure-direct-object-references/
Em termos menos técnicos, quando um usuário qualquer pode visualizar dados diversos a que ele não deveria ter acesso simplesmente mudando o ID de referência a estes dados.
A OWASP, já tão conhecida pelos leitores do blog, categorizou a vulnerabilidade como a quarta mais comum entre o Top 10 de 2013. Já em 2017, ela foi incorporada na categoria A5: Broken Access Control, o que faz todo sentido.
A vulnerabilidade é utilizada normalmente para enumeração de dados da aplicação, mas pode conceder acesso a recursos e procedimentos não autorizados caso a aplicação não possua controles de acesso efetivos a áreas restritas.
Como funciona:
A forma mais comum de referenciar dados em uma aplicação é utilizando IDs. Os IDs podem ser implementados para referenciar um usuário, um produto, uma transação, uma notícia, etc. Normalmente, este tipo de dado pode ser encontrado diretamente na URL que se está acessado, por exemplo:
https://www.exemplo.com.br/user.php?id=346
https://www.exemplo.com.br/transacao.php?id=2020195354
https://www.exemplo.com.br/produto.php?id=135
https://www.exemplo.com.br/noticia.php?id=20
Manipulando a numeração do ID destas URLs devemos conseguir acesso a outros dados da aplicação DE ACORDO COM AS POLÍTICAS DE ACESSO IMPLEMENTADAS.
Por exemplo:
Em portais de notícias, trocar o ID da URL de notícias de 20 para 21 não apresenta qualquer tipo de vulnerabilidade, visto que todos tem acesso a visualizar as notícias do portal.
Imagine que uma área de assinantes é implementada e a notícia 21 só pode ser acessada por assinantes.
Caso um usuário normal, sem assinatura, conseguir acesso a essa notícia simplesmente alterando a URL a vulnerabilidade se evidencia.
Em casos ainda mais críticos, alterar o campo ID de usuário, como no primeiro exemplo citado, e conseguir acesso aos dados de outra pessoa torna a vulnerabilidade ainda mais crítica.
Para não ficarmos apenas na teoria eis um exemplo real da vulnerabilidade, por motivos óbvios, suprimimos os dados da aplicação:
A primeira requisição foi realizada obtendo dados do nosso usuário teste a uma aplicação real:
Já nesta segunda requisição, a manipulação do ID do usuário retornou dados de uma outra pessoa existente na plataforma.
Neste caso, com o uso de um ID de numeração simples a implementação de um controle efetivo de acesso aos dados impediria o acesso não autorizado aos dados de outro usuário pela manipulação do ID na requisição.
Lembramos que nem sempre a referência a um objeto se dá por números.
Os impactos desta vulnerabilidade vão além da enumeração de dados. Existem casos onde operações de deleção de usuários, modificação de informações e outras operações são realizadas internamente na aplicação por meio de requisições utilizando este mecanismo. Algumas páginas de administração também podem utilizar este meio de identificação para serem acessadas e em casos sem um controle efetivo de acesso pode possibilitar que atacantes realizem ações não autorizadas.
Mitigação
Como muito foi falado no artigo, a implementação correta de meios de controle de acesso são suficientes para impedir o acesso a informações sensíveis.
Estes controles devem levar em consideração os dados e recursos que cada usuário, com seus respectivos privilégios, devem ter acesso dentro da aplicação.
Também é aconselhado a utilização de Hashes para identificação do recurso ao invés de numeração.
Por exemplo:
www.exemplo.com.br/usuario.php?id=1354
Poderia receber um hash baseado em alguma informação do usuário
www.exemplo.com.br/usuario.php?id=684ff997e59f38d9fe7620280889ed13
Conclusão
A vulnerabilidade é simples e bastante recorrente e por isso pode ser encontrada entre as Top 10 vulnerabilidades da OWASP. A sua mitigação por meio de implementação de outros tipos de identificadores difíceis de serem "adivinhados" é relativamente simples, mas a mitigação por meio de controle de acesso pode não ser. Em ambientes complexos com vários recursos disponíveis pode tornar difícil a delimitação dos privilégios e dados a que todos os usuários devem ter acesso, e mesmo que isto esteja bem desenhado, a falha humana pode existir e um desenvolvedor esquecer de limitar o nível de acesso a alguma parte da aplicação.
Você já conseguiu acesso a algum recurso em uma página que não deveria ter acesso? Conta pra gente....
E para você que tem uma página na internet, mas não sabe se seus níveis de acesso estão bem implementados e suscetíveis a este ataque, realizamos este tipo de verificação entre nossos produtos (Pentest, blindagem,...). Para saber mais, entre em contato conosco (https://www.siteblindado.com/contato/).
Referências:
https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
https://owasp.org/www-chapter-ghana/assets/slides/IDOR.pdf
https://portswigger.net/web-security/access-control/idor
https://www.acunetix.com/blog/web-security-zone/what-are-insecure-direct-object-references/
0 comentários: