access control
16 artigos com esta tag
Acesso não autorizado ao app Toypo (697.209 usuários afetados, segundo a Toypo): telefones, nomes e endereços vazados, e o que devem fazer os usuários de apps de lojas
A Toypo Inc. confirmou em 4 de outubro de 2026 um acesso não autorizado de terceiros ao seu app de gestão de clientes, o app Toypo, e, em comunicado datado de 14 de outubro, disse que 697.209 usuários são abrangidos e que suas informações podem ter vazado. Uma segunda página de comunicado da Toypo, sem data e sem número de pessoas, afirma que as informações vazaram. Desde 13 de outubro a empresa contata os abrangidos um a um, inclusive por notificação push no app. Segundo a empresa, parte do seu sistema tinha uma falha de controle de acesso que permitia a um usuário autenticado obter informações de outros usuários às quais não tinha direito, e seus registros mostram que um terceiro a usou para obter informações de usuários. A falha foi corrigida. As informações que podem ter vazado são o número de telefone e o ID de usuário ou identificadores semelhantes e, quando cadastrados, nome, nome em kana, e-mail, data de nascimento, gênero e endereço. Segundo a empresa, não estão incluídos senhas e outras credenciais de login, números de cartão de crédito e outros dados de pagamento, pontos, histórico de visitas a lojas e histórico de compras ou de uso, e os usuários não precisam trocar a senha nem tomar outra providência no app. Nenhum dano secundário específico foi confirmado. A empresa comunicou à Comissão de Proteção de Informações Pessoais. Uma avaliação de segurança por terceiros está sendo organizada. Nos comunicados de lojas que usam o app, a JR Kyushu Food Service diz que cerca de 26.900 de cerca de 61.500 membros cadastrados são abrangidos, e a Mannoya, 12 dos 212 membros do seu app oficial Kineya Mannoya. O contato da Toypo é 0120-546-030 (dias úteis, das 9:00 às 18:00, horário do Japão; o call center atende até as 18:00 de 30 de outubro e depois passa a valer o contato dentro do app). Conclusão deste site: uma mensagem que acerta seu telefone e seu nome não é necessariamente genuína. Não use seus links nem números; confirme pelo contato dentro do app ou pelo contato indicado no comunicado.
Acesso não autorizado ao Commune (166.505 registros de membros, contados por comunidade): dados de membros de comunidades corporativas vazados — o que membros e operadores devem fazer
Em 9 de outubro de 2026, a Commune Inc. anunciou que seus serviços de comunidade para empresas, Commune e Commune for Work, foram acessados sem autorização por um terceiro externo, e que dados de membros de algumas comunidades vazaram. Os vazamentos ocorreram por volta das 18h00 de 5 de outubro até por volta das 21h00 de 6 de outubro, e das 13h17 às 14h36 de 7 de outubro (horário do Japão). O primeiro comunicado indicou cerca de 307.000 membros (estimativa de pessoas únicas) como o máximo possivelmente afetado. Em uma atualização de 21 de outubro, após uma investigação detalhada, confirmou que 166.505 membros foram afetados (o total de IDs de membros contados por comunidade, então pessoas em várias comunidades são contadas uma vez para cada uma; isso inclui comunidades administradas pela empresa e comunidades de teste/demonstração, e exclui contas criadas pelo atacante), e que 125.601 deles tiveram dados, incluindo endereços de e-mail, vazados. Para os demais, os dados vazados incluem nomes de exibição, perfis e participações em grupos privados. Para 144 membros, as senhas foram alteradas para senhas temporárias sem a ação deles. Não foi confirmado vazamento das próprias senhas nem de mensagens diretas, e a empresa não guarda dados de pagamento. Ela atribui o incidente a links de convite para comunidades privadas obtidos de forma ilegítima e à personificação de administradores. Empresas clientes que administram comunidades no serviço também publicaram comunicados; a JMAM informou que nomes, endereços, idades e telefones nos perfis de membros de sua comunidade Toki Labo também vazaram. Para impedir o uso indevido dos e-mails vazados, a Commune Inc. interrompeu todas as comunidades para manutenção emergencial a partir das 00h50 de 10 de outubro e adotou medidas como tornar obrigatória a autenticação em dois fatores para contas de administradores. Em 16 de outubro, anunciou que as comunidades seriam reabertas em etapas, começando por clientes que solicitarem, apenas na versão para navegador web e com alguns recursos restritos (o aplicativo, o novo cadastro com endereço de e-mail e a redefinição por “esqueci minha senha” continuam indisponíveis). Diz que nenhum novo acesso não autorizado ou vazamento foi encontrado durante a manutenção ou os testes. A atualização de 21 de outubro também informa que a empresa apresentou um relatório preliminar ao Ministério de Assuntos Internos e Comunicações (Gabinete Regional de Telecomunicações de Kanto) em 9 de outubro, começou a consultar a polícia, não encontrou programas, contas ou configurações deixados pelo atacante após analisar todos os registros, e está preparando uma investigação forense por uma organização terceirizada. Nossa avaliação: verifique o comunicado da empresa que administra sua comunidade para saber se você foi afetado e não abra links em e-mails que aleguem vir da comunidade.
Vazamento de dados da NewsPicks (nomes de titulares de cartão e últimos dígitos, até 362.000 registros): o que vazou por meio de uma ferramenta administrativa interna e o que os usuários devem fazer
Em 8 de outubro de 2026, a Uzabase, Inc. anunciou que uma ferramenta administrativa usada na operação de seu serviço de notícias NewsPicks foi acessada sem autorização por um terceiro, e que alguns dados pessoais de usuários podem ter vazado. Seu segundo comunicado, de 9 de outubro, disse que a invasão explorou uma vulnerabilidade nessa ferramenta administrativa e informou as quantidades máximas estimadas por item: parte dos dados de cartão usados em pagamentos na web (nome do titular e os últimos 3 ou 4 dígitos do número do cartão, entre outros) 362.000; endereços de e-mail 323.000; categoria de cargo 273.000; vínculo institucional 65.000; nomes 59.000; e outros. A empresa afirma que números completos de cartão e códigos de segurança nunca foram armazenados em seus sistemas e não vazaram, e que nenhum vazamento de senhas foi confirmado. Nenhum dano secundário foi confirmado. Visão deste site: uma mensagem que cita os últimos dígitos do seu cartão ou o seu empregador não é prova de que é verdadeira. Não abra links, verifique pelo aplicativo oficial ou por um site oficial que você mesmo abrir, e acompanhe as faturas do seu cartão.
Vazamento de dados da skyticket (Adventure Inc.) (cerca de 14,64 milhões de registros): senhas, dados bancários de reembolso e dados de cartão de alguns usuários expostos. O que os usuários devem fazer hoje
Em 9 de outubro de 2026, a Adventure Inc. anunciou três incidentes separados de acesso não autorizado, cada um por uma rota diferente, que afetaram seu site de comparação e reserva de viagens skyticket. No primeiro, uma função administrativa foi usada indevidamente e serviu de ponto de partida para acessar outros servidores e dados armazenados na nuvem; cerca de 14,64 milhões de registros vazaram, incluindo nomes (também como escritos no passaporte), datas de nascimento, endereços de e-mail, números de telefone, endereços e o nome do remetente usado em transferências bancárias. Cerca de 4,13 milhões deles incluíam senhas de membros em hash. No segundo, uma vulnerabilidade em um sistema de gestão empresarial foi explorada, e 17.780 registros (incluindo duplicatas, com mais ainda sendo contados) contendo dados de contas bancárias para reembolso vazaram ou podem ter vazado. No terceiro, a página de conclusão de reservas de ônibus podia ser exibida sem login, e cerca de 12.000 reservas foram ou podem ter sido visualizadas. A empresa afirmou inicialmente que números de cartão não estavam entre os dados vazados, mas corrigiu isso em um segundo comunicado, em 16 de outubro: o número do cartão, o nome do titular e a data de validade (para alguns, apenas o número; sem códigos de segurança) de até 6.140 pessoas que cadastraram ou usaram um cartão de crédito para pagar a taxa de associação “skyticket Premium” entre fevereiro de 2017 e junho de 2018 vazaram no primeiro incidente, junto com IDs de membro, nomes e senhas de um serviço de benefícios sociais oferecido como vantagem do Premium. Imagens de passaportes não foram expostas e, até o comunicado de 9 de outubro, o único dano secundário confirmado foi um login não autorizado em uma conta de membro (o segundo comunicado não informa se os dados de cartão vazados foram usados indevidamente). A visão deste site: os membros devem trocar a senha pelo site ou aplicativo oficial hoje, trocá-la em qualquer outro serviço em que a tenham reutilizado, verificar as faturas do cartão a partir de outubro caso tenham cadastrado ou usado um cartão para a taxa Premium nesse período, ignorar mensagens sobre reembolsos, indenizações ou alterações de reserva e nunca informar a ninguém a senha do cartão bancário nem um código de uso único.
Exposição pública de armazenamento em nuvem: quando os dados podem vazar mesmo com o Block Public Access ativado
Vazamentos de bucket vêm de configuração, não de ataque. A frase que importa na documentação: as configurações de bloqueio de acesso público não alteram as políticas nem as ACLs existentes — as configurações públicas continuam por baixo do bloqueio, e remover o bloqueio restaura o acesso público. Então a meta não é "o bloqueio está ativado", mas "nada é público mesmo com o bloqueio desligado". Aplique no nível da conta, porque uma política de bucket pode dar a alguém a capacidade de desligar um bloqueio no nível do bucket. E "público" tem uma definição mais ampla do que as pessoas imaginam.
Vulnerabilidades de upload de arquivos — como evitar web shells e RCE pelo design
O problema de uma vulnerabilidade de upload não é 'receber um arquivo' — é onde você o coloca e se ele pode ser executado. Endpoint sem autenticação + sem validação de tipo + armazenado sob a raiz web + scripts executados ali = web shell → RCE. Defenda em camadas: (1) autenticação/permissão + CSRF no endpoint, (2) allow-list no servidor + inspeção do conteúdo, (3) armazenar fora da raiz web (ou desativar a execução), (4) nomes aleatórios, nunca confiar em caminhos do usuário. Não dependa de um único controle; tenha algo que possa barrar o ataque em cada etapa.
O que é o OWASP Top 10: a lista padrão dos 10 maiores riscos de aplicações web
O OWASP Top 10 é uma lista que a organização sem fins lucrativos OWASP publica a cada poucos anos com os 'riscos mais críticos de aplicações web'. É uma linguagem comum entre desenvolvedores e operadores. A edição atual de 2025 (anunciada em novembro de 2025) continua liderada por Controle de Acesso Quebrado; Configuração Incorreta de Segurança subiu para o segundo lugar, e duas categorias novas entraram: Falhas na Cadeia de Suprimentos de Software e Tratamento Inadequado de Condições Excepcionais. O SSRF foi incorporado a Controle de Acesso Quebrado. Estas são CATEGORIAS de risco, não exploits individuais — use-as como uma lente para auditar o seu próprio app.
O que é o PCI DSS: o padrão de segurança para lidar com dados de cartão de crédito
O PCI DSS (Payment Card Industry Data Security Standard) é o padrão internacional para empresas que armazenam, processam ou transmitem dados de cartão. Definido pelas bandeiras de cartão, ele exige proteção de rede, criptografia dos dados armazenados, controle de acesso de menor privilégio, monitoramento/registro e gestão de vulnerabilidades. Na prática, o movimento mais seguro é não guardar você mesmo os números de cartão — entregue o processamento a um provedor de pagamento em conformidade (tokenização) e reduza o seu escopo.
Segurança do ASP.NET Core — uma referência de hardening de produção
O ASP.NET Core é um framework maduro e estável, mas os incidentes vêm das configurações. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — não exponha erros detalhados / a Developer Exception Page em produção, externalize segredos (User Secrets/env/Key Vault), CVEs de dependências NuGet, autorização ([Authorize], fallback default-deny, baseada em recurso/proprietário), over-posting (DTOs/[Bind]), desserialização insegura (evite BinaryFormatter), HTTPS/headers/antiforgery, SSRF e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Segurança do Django — uma referência de hardening de produção
O Django traz muitos padrões seguros (ORM, CSRF, auto-escapamento, auth), mas os incidentes vêm das configurações. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — DEBUG=False + ALLOWED_HOSTS, externalizar o SECRET_KEY, CVEs de dependências pip, config de segurança de produção (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), autorização (escopo de proprietário), injeção e saída (raw/extra, mark_safe), CSRF/sessões/admin, SSRF/uploads e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Segurança do Express (Node.js) — uma referência de hardening para produção
O Express é minimalista — ele quase não protege nada por padrão, então você adiciona as defesas. Esta é uma referência de trabalho: (1) um checklist de hardening priorizado (P0–P2), (2) orientação por área — cabeçalhos de segurança (helmet) + desabilitar x-powered-by, CVEs de dependências npm, validação de entrada e injeção (operador SQL/NoSQL), autenticação e autorização com escopo de dono, limitação de taxa e limites de tamanho, sessões/cookies/CSRF, SSRF, tratamento de erros em produção (sem exposição de stack), NODE_ENV, e (3) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Laravel — uma referência de hardening para produção
Os padrões do Laravel são fortes; os incidentes em produção vêm da configuração e da operação. Esta é uma referência de trabalho: (1) um checklist de hardening por prioridade (P0–P2), (2) uma tabela de padrões perigosos, (3) orientação por área — segredos/APP_KEY, config de produção (APP_DEBUG/cache), autorização (Policy/Gate, Mass Assignment), injeção/saída (binding do Eloquent, Blade), sessões/CSRF/cookies, uploads, HTTPS/cabeçalhos/limitação de taxa, CVEs de dependências do Composer, e (4) um checklist de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Next.js — uma referência de hardening para produção
Os padrões do Next.js são bastante seguros, mas os incidentes acontecem na fronteira servidor/cliente. Esta é uma referência de trabalho: (1) uma lista de verificação de hardening por ordem de prioridade (P0–P2), (2) orientação por área — a fronteira e as variáveis de ambiente (NEXT_PUBLIC_), CVEs de dependências (incluindo RCE no núcleo), autorização em Server Actions / Route Handlers + validação de entrada, SSRF em buscas do lado do servidor, cabeçalhos de segurança/CSP, autenticação/sessão/cookies, limitação de taxa, e (3) uma lista de autoverificação. Apenas defensivo — sem passos de ataque.
Segurança do Ruby on Rails — uma referência de hardening de produção
O Rails entrega convenções e padrões seguros (proteção CSRF, Strong Parameters, um ORM), mas os incidentes de produção vêm da operação. Esta é uma referência de trabalho: (1) um checklist de hardening ordenado por prioridade (P0–P2), (2) orientação por área — segredos e credentials (master key/secret_key_base), config de produção (force_ssl, sem exposição de exceções), CVEs de gems, Strong Parameters/Mass Assignment, autorização (Pundit, escopo de proprietário), injeção e métodos perigosos (interpolação em where/send/constantize), sessões/cookies/CSRF, SSRF/uploads e (3) um checklist de autoverificação. Só defensivo — sem passos de ataque.
Autenticação vs autorização: só um login não protege os dados de outros usuários
Autenticação = verificar quem é a pessoa; autorização = decidir o que ela pode fazer. São coisas diferentes, e adicionar um login não é autorização. Sem restringir os dados ao dono (user_id), 'logado = vê todos os dados' — o Broken Access Control, o número um do OWASP. Some a isso um scaffold com o registro deixado aberto e um estranho pode se cadastrar e entrar. Defesas: restrinja toda consulta ao dono, feche o registro desnecessário, defesa em profundidade, logs de auditoria/acesso antes do incidente, detecte novos cadastros.
O que é IDOR: uma falha que expõe os dados de outras pessoas quando um ID é trocado
O IDOR permite que um usuário troque ?id=124 por 125 e leia a fatura ou os dados pessoais de outra pessoa — controle de acesso quebrado. A defesa principal: no servidor, verificar a cada acesso se o usuário logado tem permissão sobre este objeto. IDs difíceis de adivinhar não são uma correção.