Seu SaaS pode estar em Perigo (e você nem sabe)!
Na era dos SaaS de fim de semana só no “vibe coding”, mas será que já tem por aí algum “vibe hacking” por ai ?
Aqui no tabnews outros post relacionados como esse Seu SaaS está realmente seguro? que menciona o vídeo do Yuri Dev “Indie Hackers, sua segurança é uma droga 🤦♂️” e podemos ver ele burlando seguranças de alguns SaaS em questão de minutos.
Será que teu SaaS passaria em um teste de segurança?
Não confie em dados dos Front End !
Não sou especialista na área mas creio que é uma das regras mais básicas, todas as validações devem ser refeitas no lado do BackEnd quer seja validações simples como shema de um endpoint ou outras regras de negócio.
Um exemplo bobo
Se front tem algo como
{role == “admin” UserList …} alguém ser facilmente interceptar a requisição e mudar um role de user para admin e ter acesso a página, mas se seu BackEnd não valida se o usuário que está autenticado é de fato um administrador tadam você acabou de vazar todos os email e informações dos seus clientes…
Durante meus estudos deparei com esse vídeo OWASP TOP 10: As Falhas MAIS CRÍTICAS em Aplicações Web que achei bem interessante (recomendo), resumidamente o OWASP, “ou Projeto Aberto de Segurança em Aplicações Web, é uma comunidade online que cria e disponibiliza de forma gratuita artigos, metodologias, documentação, ferramentas e tecnologias no campo da segurança de aplicações web” na lista dos 10 principais riscos de segurança em aplicativos da Web está lá no primeiro lugar “broken access control” ou "controle de acesso quebrado logo" definitivamente isso não pode ser negligenciado.
E então como ter um bom controle de acesso ?
Continuando meu estudos, o RBAC ou Controle de Acesso Baseado em Funções creio que o mais simples de ser implementado, tem suas vantagens e desvantagens, imagina em app de TODO, eu estando autenticado como “user” não me da permissão de adicionar ou ver tarefas de outros usuários , claro isso parece óbvio, e se eu interceptar a requisição e mudar meu próprio ID (claro se eles não tiver no JWT por exemplo)o que acontece? … e seu mudar o ID do Recurso como tabela de tarefas para outro de outro usuário o que acontece ? Pesou no seu app? Lembra “ Não confie em dados dos Front End !”
O ABAC controle de acesso baseado em atributo utiliza uma abordagem baseada em políticas para controle de acesso e creio que é um pouco mais difícil de implementar … você pode pesquisar e estudar mais profundamente sobre cada um deles por sua conta.
Mas no SaaS que estou construindo eu preciso de algo mais robusto e flexível que as permissões podem ser criadas por um vários gestores podem criar diferentes permissões para alguns tipos de recurso similar o CMS Strapi, aqui que descobri e estou me inspirando no mesmo sistema que o discord( documentação oficial) utiliza e achei bem interessante o “BitField Permissions” resumindo é forma representar um conjunto de permissões em um conjunto bits cada bit no corresponde a uma permissão específica, permitindo o armazenamento e a manipulação eficientes dos direitos de acesso e modificação de dado recurso similar a permissão de arquivos.
Por exemplo essa tabela em baixo usamos 8 bits o que esse recurso só pode ter 8 permissões diferentes
| Permissão | Posição Bit | Valor (2^n) | Binário |
|---|---|---|---|
| Ver | 0 | 1 | 00000001 |
| Escrever | 1 | 2 | 00000010 |
| Apagar | 2 | 4 | 00000100 |
| Admin | 3 | 8 | 00001000 |
A permissão de ver é repensando pelo binário 00000001 o que em decimal também é 1 , olha só que interessante! Logo se tem permissão para ler e escrever pela lógica o binário seria 00000011 que é 3 em decimal que é o resultado da soma bit a bit dos dois binários 00000001 e 00000010 (1 + 2 em decimal)
Mas como utilizá isso na prática ?
Você pode salvar uma relação entre um recurso e um o usuário e esse bitfield que representa as permissões deste usuário sobre o arquivo, assim sendo fácil adicionar ou remover permissões.
Imagina listar todos recurso que pode ver creio que poderia ser algo assim
SELECT * FROM recursos WHERE (permissões & 1) = 1;
ou no caso de ter uma tabela de relação
SELECT recursos.*
FROM recursos
JOIN permissoes_usuarios_recursos ON recursos.id = permissoes_usuarios_recursos.recurso_id
WHERE permissoes_usuarios_recursos.usuario_id = 1 AND (permissoes_usuarios_recursos.permissao_bitmask & 1) = 1;
permissões & 1 é o operador binário AND entre a permissão salva na base de dados e o valor da permissão Ver 1 ou o binário 00000001. Olha que interessante né?
Mas como tudo na vida cada um em suas desvantagens!
Isso significa que dependendo da requisição terei por exemplo de fazer uma query à base dados para validar se o usuário tem permissão para escrever algum recurso, logo para eventuais consultas desnecessárias também pode uma camada de RBAC que role fica no no JWT dessa forma a requisição é eminentemente negada caso tão tiver o acesso a rota específica por exemplo de admin.
Ainda estou aprendendo, logo gostaria se alguém conhece algum projeto open source ou ferramentas, ou artigos e recomendações pessoas de como normalmente lidam com controle de acesso, deixa aqui nos comentários se for no ecossistema fastify e Typescript melhor ainda.
E então?
Você confia na segurança do seu SaaS?
Bom obrigado pela leitura, espero que esse post tenha te aberto os olhos,e dar mais importância a segurança dos seus apps, todos sabemos que 100% seguro não existe mas deixar a porta entreaberta ai facilita né!