Baixado 11 vezes
Carregado porFernando Piancastelli
Segurança em Angular SPA
O documento aborda princípios de segurança em aplicações Angular SPA, ressaltando a importância de proteger inputs, utilizar técnicas de segurança consagradas e integrar autenticação eficiente. Sugere práticas como sanitização de inputs, uso de HTTPS, e armazenamento seguro de dados com local storage, enquanto discute abordagens de autenticação como OAuth e JWT. Além disso, fornece recomendações sobre pacotes e referências úteis para melhorar a segurança em aplicações Angular.
Segurança em Angular SPA
- 1. Segurança em AngularSPA Proteção, autenticação e melhores práticas para Single-Page Apps em Angular Fernando Piancastelli 11/Mai/2017 Meetup Angular BH
- 2. Vamos falar de •Princípios de segurança na web • Técnicas de segurança para principais problemas • Exemplo: Como autenticar o usuário • Exemplo: Como guardar o usuário atual • Pacotes recomendados
- 3. Em primeiro lugar Segurançaem Angular é uma tarefa em conjunta com o servidor Angular roda no cliente – você não tem como garantir 100% a integridade do ambiente Risco pode ser mitigado com princípios consagrados de segurança
- 4. Quais são essesprincípios? • Não confie em inputs • Conheça as técnicas consagradas de arquiteturas seguras • Estabeleça valores padrão (default) seguros • Evite segurança por obscuridade • Segurança deve ser mantida simples • Não confie em retornos de serviços • Não confie em templates gerados por usuários (expr sandbox)
- 5. XSS – CrossSite Scripting Trate qualquer Javascript no cliente como potencialmente quebrável ou injetável Todo input deve ser sanitizado e tratado como texto ao chegar – jamais executado automaticamente Instale ngSanitize Angular já sanitiza automaticamente todo {{ }} e ngBind
- 6. CORS – Limitandoorigens conhecidas Seu backend idealmente deve usar o cabeçalho Acess-Control-Allow-Origin Com a lista de domínios autorizados Não protege contra XSRF, e usado apenas em XHR CORS apenas permite que um servidor autorize outro a ler suas respostas em navegadores
- 7. CSRF– Cross SiteRequest Forgery Garanta que as requisições feitas ao seu servidor/API são feitos por domínios ou clientes autorizados Angular protege automaticamente com o X-XSRF-TOKEN, a partir do momento em que o servidor define o cookie ou sessão É a técnica consagrada contra CSRF, mas outras técnicas de autenticação também protegem naturalmente Proteções contra CSRF podem ser ineficazes ou fúteis em APIs exclusivamente JSON, ou feitas para várias origens de requisição
- 8. Use HTTPS sempre Evitaataques Man in the Middle Certificados SSL para sites praticamente são gratuitos hoje em dia Mesmo imagens e outros arquivos podem ficar seguros usando CDNs como CloudFlare, AWS Cloudfront Tendência dos navegadores é exigir cada vez mais HTTPS via TLS
- 9. Local Storage Bom substitutopara cookies: • Cookies são muito mais limitados em espaço (4kb por cookie) • Maioria dos browsers implementa algum tipo de storage (webstorage, localstorage, WebSQL, indexDB, ...) Dev passa a contar com um banco NoSQL do lado do cliente – novas possibilidades para UX (Rascunhos salvos, sincronia posterior)
- 10. Local Storage • Semprevalide, codifique, e sanitize input e output de local storages • É um input de usuário como outro qualquer, e pode ser um vetor • Não é um local “seguro” para armazenar informações de usuário • Tampouco para objetos que interfiram com lógicas de negócio • Cada browser e OS limita o espaço de uma maneira, não é ilimitado e portanto deve ser levado em consideração
- 11. Segurança por obscuridade Tudoque você fizer no Angular estará disponível e visível Ainda que partes estejam “escondidas” via XHR, elas eventualmente poderão ser lidas pelo cliente Segurança e criptografia não devem ser reinventadas – utilize uma técnica recomendada e conhecida para seu cenário Local Storage igualmente vulnerável
- 12. Autenticação Autenticação vs. Autorização: •Autenticação é identificar unicamente o usuário (ator é quem diz ser quem é) • Autorização é permitir o acesso a um recurso para aquele usuário (ator tem permissão para a ação) Autenticação é a primeira parte do problema
- 13. Autenticação – MelhoresPráticas Use chaves ao invés de senhas Use cabeçalhos HTTP e códigos de status HTTP (401, 402, 403) Qualquer informação conhecida pelo cliente é um vetor: • Segredos mantidos no cliente são inseguros • Código / técnica pode ser analisado • Proteja comunicação confidencial com HTTPS
- 14. Autenticação – MelhoresPráticas Autentique todas as requisições ao servidor/API Evite sessões no servidor (conceito REST) Evite redirecionamentos
- 15. Autenticação - Cenários •Chave com segredo pré-combinado • Login com senha em sessão • Token de identificação • OAuth 1.0 & 2.0 • JWT • Autenticação dois fatores
- 16. Chave com segredopré-combinado Servidor e cliente sabem de antemão qual é o segredo usado na comunicação e autenticação Protege de maneira simples em cenários onde o cliente é muito bem conhecido Só deve ser utilizado em ambientes em que o código é inacessível e, idealmente, é atualizado (softwares compilados) • Não é um bom cenário para Angular
- 17. Login com senhaem sessão Endpoint pré-definido recebe nome de usuário e senha via HTTPS Servidor define a sessão e um cookie identificador Requisições seguintes precisam do cookie para autenticar Funcional para SPAs, mas caindo em desuso, pois é um cenário pouco adequado para clientes não-navegadores
- 18. Token de identificação Endpointpré-definido recebe nome de usuário e senha via HTTPS Cliente recebe um token que identifica e autoriza o usuário Token precisa: • ser aleatório (não pode ser adivinhável) • Idealmente, de conferência rápida pelo servidor, pois estará em todos os requests Cenário adequado para vários domínios e diferentes clientes
- 19. OAuth Servidor e clientesdelegam a identificação para um terceiro (Facebook, Google,...) • Ainda recai para o servidor autenticar o usuário (mapear usuário no terceiro com usuário no servidor) • Ainda recai para o servidor autorizar o usuário (permitir que o usuário acesse) Existem fraquezas na especificação que exigem alta confiança entre servidor e terceiro: • Terceiro envia apenas por HTTPS para endpoint conhecido • Endpoint do servidor precisa estar bem delimitado a origens
- 20. JWT – JavascriptWeb Tokens Um padrão para tokens de identificação O endpoint que autentica retorna um token que funciona, ao mesmo tempo, como autenticador e autorizador (papéis) para o usuário logado Se seguido à risca e bem testado, pode também aceitar tokens de terceiros Considerações: • A especificação é ampla em alguns aspectos, e pode introduzir vulnerabilidades a um servidor que aceite qualquer JWT válido • Para autenticação de um software “fechado”, um esquema com tokens próprios é melhor
- 21.
- 22.
- 23. Obrigado! Fernando Piancastelli CTO naRECTRIX fernando@rectrix.com.br Meetup Angular BH https://www.meetup.com/AngularJS-BH/
Notas do Editor
- #24 No modo Apresentação de Slides, clique na seta para entrar no PowerPoint Getting Started Center.