Executando verificação de segurança...
34
rafinhahdc19
3 min de leitura ·

Seu SaaS está realmente seguro?

Estava navegando pelo YouTube quando encontrei este vídeo incrível:

https://youtu.be/r2E_Mc9KY6c?si=_26w3A37lfiVnFwB

Todo o crédito do vídeo e desta postagem vai para YuriRDev!

Pesquisei no TabNews e percebi que ninguém falou sobre isso ainda, então resolvi compartilhar.

A Importância da Segurança em SaaS

Se você já tentou lançar um SaaS e buscou desenvolvê-lo o mais rápido possível, sabe que essa abordagem pode ser arriscada. Não há nada de errado em querer agilidade, mas é essencial dedicar um tempo extra para segurança. Caso contrário, seu SaaS pode acabar vulnerável a ataques.

No vídeo, o Yuri analisa dois SaaS e demonstra falhas de segurança que poderiam causar grandes prejuízos, especialmente para sistemas com receita recorrente. Muitas dessas falhas são simples, mas passam despercebidas.

Não sou especialista em segurança, mas já me interessei pelo tema na época do PHP e aprendi algumas boas práticas que carrego até hoje. Por isso, quero compartilhar algumas dicas básicas para que você não cometa os mesmos erros.

📌 Dicas para Melhorar a Segurança do Seu SaaS

1️⃣ Nunca confie nos dados enviados pelo front-end

O back-end deve ser sólido e nunca depender apenas das informações enviadas pelo front-end. Aqui está um exemplo de erro comum (que inclusive é mostado do vídeo):

❌ Rota de assinatura insegura: O front-end envia os dados do plano diretamente para o gateway de pagamento.
✅ Solução: O back-end deve definir propriedades fixas sobre os planos disponíveis e permitir apenas que o front escolha qual deseja.

para quem não entendeu direito esse erro seria tão grave quanto permitir que o front-end envie diretamente comandos SQL para a api execultar no banco de dados, e nem preciso explicar porque isso daria um problemão.

Além disso, sempre valide permissões de usuário. Não basta confiar apenas no que o front-end informa.

2️⃣ Trate a API como o produto final

Esqueça o front-end por um momento e pense em sua API como um serviço autônomo. Quem interage com a API deve apenas especificar como quer os dados, e não o que a API deve fazer.

3️⃣ Utilize JWT para autenticação

Muitos iniciantes não conhecem o JWT (JSON Web Token), mas ele pode resolver problemas graves de segurança.

✅ Como funciona:

  1. O servidor gera um token JWT com informações sobre o usuário, incluindo alguma forma de identificar o usuario e não só características do usuario para evitar que o usuario use o token de outra conta (como por exemplo um token de um site que tem o plano gratis temporário, ai quando
    o tempo gratis do usuario acabar esse identificador do usuario vai evitar que ele possa criar uma conta nova e ultilizar esse token apenas um exemplo talvez guardar informações de plano ou outro tipo de dados no jwt não seja a melhor alternativa a não ser em casos específicos).

  2. Esse token é enviado ao cliente, que o armazena.

  3. Toda vez que o cliente fizer uma requisição, ele envia o JWT para o servidor.

  4. O servidor verifica se o token é válido (por meio da assinatura) e verifica os dados do jwt para ver se tal usuario tem tais permissões antes de processar a solicitação.

Isso teria prevenido o problema do primeiro SaaS analisado no vídeo, onde bastava alterar um ID na requisição para acessar dados de outros usuários.

Além disso, ajudaria a mitigar o problema do segundo SaaS, onde o usuário conseguia se tornar administrador apenas modificando um parâmetro na requisição. Se a API validasse essa informação via JWT, poderia impedir essa vulnerabilidade.

🔍 Conclusão

Essas são apenas algumas dicas básicas para melhorar a segurança de um SaaS. Existem muitas outras técnicas e boas práticas que podem ser aplicadas. Se você tiver mais sugestões, compartilhe nos comentários!

Ah, e para os hackers de plantão, se quiserem testar a segurança do meu SaaS, fiquem à vontade – desde que não façam ataques DDoS. Se encontrarem alguma falha, peço que relatem para o e-mail do projeto. Me preocupo bastante com segurança, mas ninguém é perfeito, então toda ajuda é bem-vinda.

🔗 Teste seu conhecimento em segurança aqui: https://showmyprojects.com

Carregando publicação patrocinada...
4
2
0
0
1
PedroPontes

Muito bom, concordo com você, encontrei uma vulnerabilidade no SaaS da empresa q eu trabalho, no primeiro dia de serviço.

Peguei para fazer alguns testes nas rotas sem olhar muito para o código fonte ainda, comecei pelo padrão, explorando a rota de cadastro de customers.

Fiz um cadastro simples utilizando o Postman na rota de cadastro, percebi portanto, que no caso de sucesso, me retornava algo parecido com isso:

{
    username: 'any_username',
    email: '[email protected]',
    ...
    isAdmin: false,
}

Bimba!

Uma possivel vulnerabilidade encontrada, não sou bobo nem nada, fiz o cadastro injetando uma props

{ isAdmin: true }

Passou como uma luva, tinha acesso a tudo do site, gerenciamento de cupons, exclusão de cadastros, ou seja, controle total do SaaS.

Uma vulnerabilidade que parece um absurdo, mas pode acontecer. Se fosse uma pessoa mal intencionada poderia acabar com seu sistema sem voce nem perceber.

1
DivinSphere

"❌ Rota de assinatura insegura: O front-end envia os dados do plano diretamente para o gateway de pagamento.
✅ Solução: O back-end deve definir propriedades fixas sobre os planos disponíveis e permitir apenas que o front escolha qual deseja.!

Imagina só, permitir que o frontend envie para o gateway o valor do pedido ou quantas moedas a pessoa vai ganhar em uma compra por exemplo, que perigo XD afinal de contas, tem algumas plataformas que permitem a criação dinâmica de um pagamento com um valor X, se a aplicação pegar esse valor do frontend, então a pessoa poderia facilmente alterar quanto vai gastar/ganhar em uma compra

Nunca fui muito de estudar sobre segurança, mas sempre gostei dos assuntos, dos temas, e principalmente de partes de criptografia, boas práticas e essas coisas

1
igorbenav

Lembrando que a maior vantagem do JWT é ser stateless (então você não tem a mesma carga no servidor que autenticação por sessões, pelo menos), mas tem a grande desvantagem de você não poder deslogar o usuário. Essencialmente só valida se o JWT é válido e o usuário tá logado até o token expirar.

Pra mitigar isso é importante ter um access token (mais curto, durando talvez 15 minutos) e um refresh token com duração mais longa. Dessa forma, se o access token for comprometido, tem menos tempo pro hacker fazer besteira.

Implementar uma política de token blacklist pra contornar isso tira a vantagem do JWT, aí vale mais a pena só usar sessões mesmo.

Pra painel de admin, o melhor é autorizar o acesso só a partir de alguns IPs.

1
ElpidioNet

muito bom post,

agora sera que esses SaaS foram construídos com low code? Normalmente esses produtos são feitos com uso de low code pois é mais rápido de desenvolver, mas pode ter tido falha na configuração ou foi erro da ferramenta mesmo?

Fica essa duvida no ar para devs low code

0
0
-1