 |
| Bellacosa Mainframe api security um guia para padawans |
☕ Um Café no Bellacosa Mainframe
API Security: O Guia Definitivo Para Programadores Juniores (e Para Todo Mundo que Acha que HTTPS Resolve Tudo)
"Uma API não é apenas uma porta de entrada para sua aplicação. Ela é a porta da frente da empresa inteira. Se ela estiver destrancada, não importa o quão seguro seja o resto da casa."
Existe uma frase muito famosa entre profissionais de segurança:
"Os hackers raramente quebram algoritmos. Eles exploram erros de implementação."
E isso nunca foi tão verdadeiro quanto no mundo das APIs.
Nos últimos anos, praticamente todos os grandes vazamentos de dados envolveram APIs.
Facebook.
Twitter.
T-Mobile.
Optus.
Experian.
Até empresas que investem milhões em segurança acabam descobrindo que um simples endpoint mal protegido era suficiente para entregar milhares de registros para qualquer pessoa.
O mais curioso?
Na maioria dos casos...
O problema não era criptografia.
Não era um vírus.
Não era um super hacker usando inteligência artificial.
Era simplesmente uma API que confiava demais no usuário.
Hoje vamos conversar sobre isso.
Pegue seu café.
Porque este assunto vale ouro para qualquer desenvolvedor — principalmente para quem está começando.
O que é uma API, afinal?
Imagine um restaurante.
Você não entra na cozinha para preparar seu próprio prato.
Existe um garçom.
Você faz um pedido.
O garçom leva o pedido.
A cozinha prepara.
O garçom entrega o resultado.
A API é exatamente esse garçom.
Cliente
↓
API
↓
Sistema
↓
Banco de Dados
Ela recebe pedidos.
Executa regras.
Consulta bancos.
Chama outros sistemas.
Retorna respostas.
Simples.
Até alguém decidir fazer um pedido que nunca deveria existir.
O maior erro dos programadores iniciantes
Todo desenvolvedor júnior já escreveu algo parecido:
GET /clientes/100
A API devolve:
{
"nome":"João",
"saldo":5000
}
Legal.
Então alguém abre o navegador e altera a URL.
GET /clientes/101
Se aparecer o cliente do vizinho...
Parabéns.
Sua API acabou de sofrer um ataque chamado BOLA.
(Broken Object Level Authorization)
É atualmente a vulnerabilidade número 1 do OWASP API Security Top 10.
O problema não foi o usuário alterar a URL.
O problema foi a API acreditar nela.
A API nunca deve confiar em ninguém
Essa talvez seja a regra mais importante deste artigo.
Repita comigo:
Nunca confie na entrada do usuário.
Nunca.
Nem no navegador.
Nem no aplicativo mobile.
Nem no frontend.
Nem porque "foi o React que enviou".
Nem porque "é um aplicativo interno".
Toda requisição pode ter sido criada manualmente.
Ferramentas como Postman, Insomnia ou Burp Suite permitem montar qualquer requisição imaginável.
Para um atacante, sua tela bonita simplesmente não existe.
Ele conversa diretamente com a API.
HTTPS não significa segurança
Esse é um mito extremamente comum.
"Minha API usa HTTPS."
Ótimo.
Isso apenas significa que a comunicação é criptografada.
Não significa que a pessoa tenha autorização.
Imagine um carro-forte.
Ele transporta dinheiro de forma segura.
Mas isso não significa que qualquer pessoa possa entrar nele.
HTTPS protege o caminho.
Não protege a autorização.
OAuth2 não é login
Outro erro muito comum.
OAuth2 resolve autorização.
Quem resolve identidade normalmente é o OpenID Connect (OIDC).
Funciona assim:
Usuário
↓
Identity Provider
↓
Token JWT
↓
API
A API nunca recebe a senha.
Ela recebe apenas um token dizendo:
"Este usuário já foi autenticado."
Isso reduz muito a superfície de ataque.
 |
| Bellacosa Mainframe boas praticas na segurança de api |
Adeus Password Grant
Se você ainda encontrar isso:
username
password
↓
API
Desconfie.
Os fluxos Password Grant e Implicit praticamente desapareceram dos projetos modernos.
Hoje usamos Authorization Code + PKCE.
Principalmente em:
aplicativos mobile
SPAs
aplicações desktop
PKCE impede o roubo do Authorization Code.
É uma camada extra que praticamente virou padrão.
Tokens também envelhecem
Imagine um token válido por 24 horas.
Agora imagine que alguém o roubou.
Esse invasor terá um dia inteiro para fazer estragos.
Por isso usamos:
Access Token
5~15 minutos
Depois disso...
Adeus.
Se precisar continuar, utiliza um Refresh Token.
Curiosamente, muitos ataques modernos acontecem justamente porque empresas deixam tokens válidos durante dias.
O princípio do menor privilégio
Existe uma regra clássica na segurança chamada:
Least Privilege
Se alguém precisa apenas consultar pedidos...
Não entregue permissões de administrador.
Errado:
scope=admin
Melhor:
orders.read
Quanto menor o privilégio...
Menor o estrago.
Menos dados também é segurança
Outro hábito muito comum:
SELECT *
O problema?
Talvez o cliente precise apenas do nome.
Mas você devolve:
CPF
RG
salário
endereço
telefone
hash da senha
Tudo isso via API.
Mesmo que o frontend esconda essas informações.
Lembre-se:
Quem vê a resposta da API é o atacante.
Não o usuário.
Cuidado com o Field-Level Authorization
Esse é um assunto que pouca gente comenta.
Imagine um gerente e um atendente.
Ambos consultam o mesmo cliente.
O gerente pode ver:
Nome
Salário
Limite
CPF
O atendente precisa apenas:
Nome
Telefone
A autorização pode acontecer até no nível dos campos.
É uma das práticas mais sofisticadas em APIs modernas.
TLS protege a estrada
Imagine a internet como uma rodovia.
TLS coloca um caminhão blindado nela.
Mas...
Depois que o caminhão chega ao destino...
Os dados continuam circulando entre diversos serviços.
Gateway
↓
Microserviço
↓
Fila MQ
↓
Banco
↓
Cache
Cada salto precisa ser protegido.
É aí que entra o mTLS.
mTLS: quando os servidores também apresentam documento
No HTTPS comum...
O cliente verifica o certificado do servidor.
No mTLS...
Os dois lados apresentam certificados.
É quase como entrar num prédio onde tanto o visitante quanto o porteiro mostram identidade.
Muito usado entre microserviços.
O segredo mais famoso do GitHub
Existe uma piada entre desenvolvedores:
"Todo iniciante já publicou uma senha no GitHub."
Infelizmente...
Ela não é totalmente piada.
Nunca faça isso:
SECRET="123456"
Nem isso:
password=admin
Muito menos:
git push
Hoje existem robôs que monitoram commits públicos procurando:
AWS Keys
Azure Keys
Google Keys
Tokens GitHub
Tokens JWT
Senhas
Às vezes em poucos segundos.
Vault é o cofre da aplicação
Em vez de guardar senhas no código...
Utilizamos Vaults.
Como:
Hashicorp Vault
IBM Hyper Protect
Azure Key Vault
AWS Secrets Manager
Esses sistemas armazenam segredos de forma segura.
Melhor ainda quando utilizam HSM.
HSM: a chave que nunca sai do cofre
Imagine um cofre de banco.
Você leva um documento.
O funcionário entra.
Assina.
Volta.
Você nunca vê a chave.
É exatamente isso que faz um Hardware Security Module.
Ele assina.
Mas nunca entrega a chave privada.
Nem para o sistema operacional.
Validação de entrada salva vidas
Uma API recebe:
{
"idade":"abc"
}
Sua aplicação espera:
idade = inteiro
Quem deveria descobrir isso?
O código?
Não.
O Gateway.
Hoje utilizamos OpenAPI e JSON Schema para validar tudo antes da aplicação receber.
Isso reduz bugs e ataques.
Nunca aceite campos desconhecidos
Imagine:
{
"nome":"Carlos",
"idade":30,
"admin":true
}
Você nunca criou o campo admin.
Mas o atacante criou.
Se sua API simplesmente copiar tudo para o banco...
Você acabou de criar um administrador.
Esse tipo de problema é conhecido como Mass Assignment.
Rate Limit: educando clientes mal comportados
Nem todo ataque é malicioso.
Às vezes um bug faz um aplicativo repetir milhares de chamadas.
Resultado:
CPU em 100%.
Banco sobrecarregado.
Sistema fora do ar.
Por isso usamos limites.
Exemplo:
100 requisições/minuto
Além disso:
limite de payload
timeout
limite de memória
limite por IP
Idempotência: a arte de não cobrar duas vezes
Imagine um PIX.
Você aperta Confirmar.
A internet cai.
Você aperta novamente.
Sem idempotência:
R$100
↓
R$100
Cobrança duplicada.
Com Idempotency Key:
Mesmo identificador
↓
Resposta antiga
↓
Nenhuma nova cobrança
Bancos usam isso o tempo todo.
SSRF: quando sua API ataca por você
Esse é um dos ataques mais interessantes.
O usuário envia:
https://empresa.com/imagem.jpg
Mas na verdade envia:
http://169.254.169.254
Esse endereço existe em praticamente todos os provedores de nuvem.
Ele contém metadados da máquina.
Se a API acessar...
Pode entregar credenciais internas.
Solução?
Allowlist.
Sempre.
CORS não é um botão mágico
Muitos desenvolvedores fazem:
Access-Control-Allow-Origin: *
Funciona.
Até alguém descobrir.
CORS deveria liberar apenas domínios conhecidos.
Nunca o mundo inteiro.
Shadow APIs
Essa talvez seja minha curiosidade favorita.
Grandes empresas frequentemente descobrem APIs que ninguém lembrava que existiam.
Criadas por:
estagiários
provas de conceito
sistemas antigos
versões esquecidas
ambientes de teste
Chamamos isso de Shadow APIs.
Curiosamente...
Muitos ataques começam justamente por elas.
Logs são a caixa-preta do avião
Imagine um acidente.
Sem caixa-preta...
Nunca saberemos o que aconteceu.
Com APIs é igual.
Registre:
autenticações
autorizações
erros
tokens inválidos
mudanças de configuração
tentativas suspeitas
Mas atenção.
Nunca registre:
senhas
cartões
tokens completos
chaves privadas
Logs também vazam.
SIEM: o cérebro da segurança
Imagine milhares de servidores enviando eventos.
O SIEM junta tudo.
Percebe padrões.
Por exemplo:
500 erros 401
↓
Mesmo IP
↓
Mesmo minuto
Provável ataque de força bruta.
Outro exemplo:
Login
Brasil
↓
3 segundos
↓
Japão
Fisicamente impossível.
Alerta.
Como isso tudo conversa com o Mainframe?
Quem trabalha com IBM Z pode pensar:
"Isso é coisa de microsserviços."
Não é.
Hoje milhares de programas COBOL são publicados como APIs através do IBM z/OS Connect Enterprise Edition.
Quem faz a autenticação?
OAuth2.
Quem autoriza?
RACF.
Quem protege certificados?
AT-TLS.
Quem registra auditoria?
SMF.
Quem envia eventos?
QRadar.
Ou seja...
O mundo moderno e o mainframe estão muito mais próximos do que muita gente imagina.
☕ Curiosidades do Café
Você sabia?
O ataque BOLA aparece entre as vulnerabilidades mais exploradas do mundo há vários anos consecutivos.
Você sabia?
Mais de 80% do tráfego da internet atualmente é composto por chamadas de APIs, não por pessoas navegando em páginas web.
Você sabia?
Empresas frequentemente possuem mais APIs do que desenvolvedores.
Em grandes bancos não é raro encontrar dezenas de milhares de endpoints ativos.
Você sabia?
O famoso código HTTP 418 – I'm a Teapot nasceu como uma brincadeira em um protocolo criado no Dia da Mentira (RFC 2324), simulando um "protocolo para cafeteiras". Embora seja um easter egg da internet, alguns servidores realmente retornam esse status.
🥚 Easter Eggs para Programadores
🥚 Se você encontrou uma API que aceita:
?id=1
Experimente trocar por:
?id=2
Se funcionar...
Você acabou de encontrar um candidato a BOLA.
(Não faça isso em sistemas que você não possui autorização para testar.)
🥚 O famoso endereço:
169.254.169.254
é praticamente um "portal secreto" dos provedores de nuvem para acesso a metadados da instância. Por isso ele aparece em tantos estudos sobre SSRF.
🥚 Os famosos códigos:
401
403
404
não significam a mesma coisa.
401
Você não está autenticado.
403
Você está autenticado, mas não possui autorização.
404
O recurso não existe (ou o servidor decidiu ocultar sua existência por segurança).
Grandes empresas frequentemente devolvem 404 em vez de 403 para não revelar que determinado recurso realmente existe.
Conclusão
Segurança de APIs não é um recurso que se instala.
É uma forma de pensar.
Cada requisição deve ser tratada como potencialmente maliciosa. Cada parâmetro precisa ser validado. Cada autorização deve ser conferida. Cada segredo precisa ser protegido. Cada log pode ser a diferença entre identificar um ataque em segundos ou descobrir um vazamento dias depois.
Se existe uma única lição que eu gostaria que todo programador júnior levasse deste café, seria esta:
Nunca confie na requisição; confie apenas nas verificações que sua aplicação faz sobre ela.
É exatamente essa mentalidade que transforma um desenvolvedor que apenas "faz a API funcionar" em um engenheiro capaz de construir sistemas confiáveis, resilientes e preparados para enfrentar o mundo real — seja em microsserviços na nuvem, seja em aplicações COBOL rodando há décadas no IBM Z.
Porque, no fim das contas, a tecnologia muda, os frameworks mudam, os protocolos evoluem... mas um princípio continua imutável:
A melhor API não é apenas rápida ou elegante. É aquela que continua segura mesmo quando alguém tenta usá-la da pior maneira possível.
Sem comentários:
Enviar um comentário