O GeckoFlag é um software executado no seu próprio servidor. Para que você possa confiar a ele as informações dos seus projetos com tranquilidade, o próprio desenvolvedor realiza testes de segurança a cada versão e publica nesta página o que foi testado e os resultados.
Esta página é um registro de autoavaliação feita pelo desenvolvedor. Não se trata de uma certificação nem de uma auditoria feita por terceiros. Como também publicamos o que é testado, use estas informações como apoio na decisão de adotar o GeckoFlag.
- Medidas no design
- Testes a cada versão
- Resultados da versão mais recente
- O que não é testado
- Relatar vulnerabilidades
- Verificação dos arquivos distribuídos
- Configurações recomendadas
Medidas de segurança no design
O GeckoFlag já inclui por padrão as medidas abaixo. Todas ficam ativas sem nenhuma configuração.
Proteção de senhas
As senhas nunca são armazenadas em texto simples: são salvas como hash com bcrypt. Os tokens de redefinição de senha também são armazenados como hash, e o número de solicitações de redefinição é limitado.
Limite de tentativas de login
As falhas de login são contadas tanto por conta quanto por endereço IP de origem e, quando ultrapassam um determinado número, o login fica temporariamente bloqueado. Isso contém ataques de força bruta e ataques direcionados a muitas contas.
Proteção contra CSRF
Um token é validado em todos os envios de formulário, impedindo que sites externos executem ações se passando pelo usuário.
Proteção contra XSS
O rich text de tarefas, comentários, Wiki, notas etc. é salvo e exibido pelo HTML Purifier, que mantém apenas as tags permitidas. Nos links, somente http e https são permitidos. Os textos gerados por IA também passam pelo mesmo processamento antes de serem salvos.
Proteção contra injeção de SQL
As operações no banco de dados usam o ORM do CakePHP 5 e prepared statements.
Validação do cabeçalho Host
Os links incluídos nos e-mails de redefinição de senha, convite e notificação são gerados a partir do domínio registrado, e não do cabeçalho Host da requisição. Um cabeçalho Host malicioso não consegue redirecionar os links dos e-mails para um endereço externo.
Armazenamento de arquivos
As imagens das tarefas e os arquivos dos projetos são armazenados fora da pasta pública e só são entregues depois de verificar se quem os acessa é membro do projeto. Arquivos com extensões executáveis, como PHP, não são aceitos.
Criptografia da chave de API
A chave da Claude API usada pelos recursos de IA é armazenada criptografada no banco de dados.
Tokens de API da integração com o Claude
A integração com o Claude vem desativada e só pode ser usada quando um administrador a ativa e a permite para cada usuário. De cada token de API é armazenado apenas um hash, e é possível definir uma data de validade. Alterar a senha invalida os tokens. A API verifica as mesmas permissões que as telas, e tokens somente leitura não podem alterar nada.
Restrição por endereço IP
Os administradores podem limitar os endereços IP que têm permissão de acesso.
Bloqueio do instalador
Depois que a configuração é concluída, a tela do instalador deixa de ser acessível.
Proteção das pastas privadas
No Apache, o acesso direto às pastas de configuração, logs, código-fonte etc. é negado por padrão (no Nginx, consulte as configurações recomendadas).
Backup automático antes da atualização
Um backup é criado automaticamente antes de cada atualização do software.
Verificação da assinatura dos arquivos de atualização
Os arquivos de atualização oficiais têm a assinatura digital do desenvolvedor (Ed25519). Antes de atualizar, a assinatura e o conteúdo de todos os arquivos são conferidos, e arquivos adulterados ou que não sejam oficiais não são aplicados.
Validação do envio de imagens
Imagens como avatares, miniaturas e logotipos têm o formato identificado pelo conteúdo do arquivo e são salvas com um nome de arquivo aleatório. As pastas de imagens não entregam nenhum arquivo que não seja imagem (no Apache). SVG não é aceito.
Cabeçalhos de segurança
São enviados os cabeçalhos Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy, que evitam clickjacking e o vazamento de informações para sites externos. Quando o sistema é executado com HTTPS, também é enviado o Strict-Transport-Security, para que o navegador sempre se conecte por HTTPS.
Gerenciamento de sessões
A sessão é recriada a cada login. Alterações de permissões, exclusão de contas e troca de senha são aplicadas imediatamente também às telas com sessão ativa. Para alterar o e-mail ou a senha, é preciso informar a senha atual.
Testes de segurança a cada versão
Antes de publicar uma nova versão, realizamos os testes a seguir. Eles são feitos em um ambiente de testes com a mesma configuração do ambiente de produção, e nunca em serviços em operação ou nos servidores dos clientes. O que foi feito na versão mais recente está descrito em “Resultados da versão mais recente”.
| Categoria | O que é testado | Ferramentas e referências | Frequência |
|---|---|---|---|
| Dependências | Verificação de vulnerabilidades conhecidas nas bibliotecas usadas e geração da lista de bibliotecas utilizadas (SBOM) | composer audit, OSV-Scanner, CycloneDX | A cada versão |
| Análise estática | Detecção, no código-fonte, de caminhos pelos quais dados de entrada chegam a operações perigosas (XSS, injeção de SQL etc.) | Psalm (análise de taint), PHPStan (nível 5), Semgrep | A cada versão |
| Segredos expostos | Se há senhas ou chaves de API no código-fonte ou nos arquivos distribuídos | gitleaks | A cada versão |
| Varredura dinâmica | Envio de requisições de ataque reais, com sessão iniciada como administrador e como usuário comum, para verificar as respostas | Nuclei | A cada versão |
| Testes de permissões | Se é possível ver ou alterar tarefas, arquivos ou notas de projetos dos quais o usuário não participa, trocando o ID na URL | Testes automatizados (PHPUnit), verificação manual | A cada versão |
| Envio de arquivos | Se arquivos executáveis, arquivos disfarçados de imagem, ZIPs que manipulam caminhos etc. são rejeitados | Revisão de código, verificação manual | A cada versão |
| XSS | Inserção de strings de ataque no texto das tarefas, comentários, Wiki e textos gerados por IA, para verificar se algum script é executado | Revisão de código, verificação manual | A cada versão |
| Verificação por configuração de servidor | Se é possível acessar diretamente arquivos de configuração ou logs no Apache e no Nginx, e em cada forma de posicionar a pasta pública | Verificação manual | A cada versão |
| Extensão da integração com o Claude | Vulnerabilidades conhecidas nas bibliotecas usadas pela extensão, tratamento do token da API e restrições sobre o destino das solicitações | npm audit, gitleaks, revisão de código | A cada versão da extensão |
| Autoavaliação com checklist | Verificação item por item de autenticação, sessões, validação de entrada, tratamento de erros etc. | Com base no OWASP ASVS 5.0 nível 1; IPA (Japão): Como proteger o seu site | A cada versão principal |
| Site oficial | Configuração de HTTPS e cabeçalhos de segurança de geckoflag.com | SSL Labs, Mozilla Observatory | Uma vez por mês |
Se for encontrado algum problema de gravidade “alta” ou “média”, a versão não é lançada até que ele seja corrigido e testado novamente. Os de gravidade “baixa” são analisados e corrigidos, ou registramos o motivo pelo qual não têm impacto.
Política de atualização das dependências
As vulnerabilidades conhecidas das bibliotecas usadas pelo GeckoFlag (como o CakePHP) são verificadas a cada versão. Se for encontrada uma vulnerabilidade que afete o GeckoFlag, publicaremos uma versão corrigida dentro dos prazos indicativos abaixo.
- Gravidade “crítica” ou “alta”: em até 14 dias após a divulgação
- Gravidade “média”: em até 30 dias após a divulgação
- Gravidade “baixa”: na próxima versão (no máximo em 90 dias)
Mesmo as vulnerabilidades que não afetam o GeckoFlag pela forma como ele usa a biblioteca são resolvidas na próxima versão, com a atualização para uma versão corrigida. As bibliotecas de desenvolvimento não são incluídas nos arquivos distribuídos.
Resultados da versão mais recente: v1.11.0
Esta rodada testou as mudanças desde a v1.10.0 (a integração com o Claude, as cores de texto e de fundo e os divisores do texto formatado, entre outras) e também corrigiu problemas que já existiam em versões anteriores. Se você usa a v1.10.0 ou anterior, recomendamos atualizar para a v1.11.0.
| Teste | Ferramentas (versão) | Detectados (alta / média / baixa) | Ação |
|---|---|---|---|
| Dependências | GitHub Advisory Database, FriendsOfPHP security-advisories (dados de 2026-10-28; 89 pacotes) | 0 / 0 / 0 | Nenhuma vulnerabilidade conhecida nas bibliotecas incluídas nos arquivos de distribuição. As vulnerabilidades conhecidas das bibliotecas de desenvolvimento foram resolvidas com a atualização na v1.11.0 (bibliotecas de desenvolvimento não são incluídas nos arquivos de distribuição) |
| Análise estática e revisão de código | Psalm 5.26.1 (análise taint), PHPStan 2.1.17 (nível 5), Semgrep 1.182.1, revisão manual de código (mudanças desde a v1.10.0: API e tokens da integração com o Claude, texto formatado, permanência do login, atualizações do software; além da saída de links em todas as telas) | 1 / 1 / 3 | Os problemas de gravidade “alta” e “média” e 2 dos de gravidade “baixa” foram corrigidos na v1.11.0. O problema “baixo” restante só ocorre por ações do próprio usuário, e foi confirmado que seu impacto é limitado. O problema “alto” já existia em versões anteriores |
| Segredos expostos | gitleaks 8.24.2 | 0 / 0 / 0 | Foram verificados tanto o código-fonte quanto os arquivos de distribuição. As 2 detecções foram falsos positivos (como strings de exemplo em bibliotecas externas) |
| Confirmação das correções | Testes de funcionamento no ambiente de testes (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | Para cada apontamento, confirmamos que o problema anterior à correção não se reproduz mais |
| Varredura dinâmica | Nuclei v3.11.1 (templates v10.5.1), sem login e como administrador e membro | 0 / 0 / 0 | Sem problemas |
| Testes de permissões | PHPUnit 12.5 (454 testes automatizados. Além dos testes anteriores, confirmam que a API da integração com o Claude recusa solicitações sem token, com token somente leitura, de usuários sem permissão e com o recurso desativado, e que nunca chega a projetos dos quais o usuário não participa) | 0 / 0 / 0 | Sem problemas |
| Verificação por configuração de servidor | Manual (Apache 2.4 e Nginx 1.24, 2 formas de posicionar a pasta pública; 39 URLs, incluindo arquivos de configuração, logs, sessões e arquivos armazenados) | 0 / 0 / 1 | Corrigido na v1.11.0: o acesso direto à pasta de arquivos de versões anteriores (files) agora é recusado por completo também no Apache. Sem outros problemas |
| Checklist | OWASP ASVS 5.0 nível 1 (70 itens) | Atende a 50 dos 56 itens aplicáveis | Não revisado desta vez (mantido o resultado da v1.10.0) |
| Extensão da integração com o Claude | npm audit, gitleaks 8.24.2, mcpb validate, revisão manual de código (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | Nenhuma vulnerabilidade conhecida que afete as bibliotecas incluídas no arquivo de distribuição. Verificados o tratamento do token da API e as restrições sobre o destino das solicitações (somente HTTPS, sem seguir redirecionamentos) |
Os resultados de todas as versões, incluindo as anteriores, ficam reunidos em “Resultados anteriores”.
O que não é testado
Os testes acima têm as limitações a seguir. Leve-as em conta também ao avaliar a adoção do GeckoFlag.
- Não há testes feitos por terceiros. No momento, não realizamos revisão de código-fonte nem testes de intrusão por especialistas externos.
- O ambiente do seu servidor não faz parte dos testes. A segurança varia muito conforme a configuração e o estado de atualização do sistema operacional, do servidor web, do PHP e do banco de dados.
- Nem todos os ambientes de hospedagem foram verificados. As configurações testadas se limitam às descritas em “Resultados da versão mais recente”.
- Serviços externos não fazem parte dos testes. A segurança da API da Anthropic usada pelos recursos de IA, do aplicativo Claude para desktop usado pela integração com o Claude, dos servidores de envio de e-mail etc. depende de cada fornecedor.
- Sobre o que as ferramentas automáticas não detectam. Tipos de problema que as ferramentas não detectam (como falhas na lógica de negócio) são cobertos por testes manuais, mas não é possível abranger tudo.
Como relatar uma vulnerabilidade
Se você encontrar um problema que pareça ser uma vulnerabilidade do GeckoFlag, não o divulgue publicamente: entre em contato diretamente pelo canal abaixo. O próprio desenvolvedor lê todos os relatos.
Canal de contato: use o formulário de contato e selecione o tipo de contato “Relato de vulnerabilidade”
O que incluir no relato
- A versão afetada e a tela ou o recurso com o problema
- Os passos para reproduzir (na medida do possível)
- O impacto esperado
- O ambiente do seu servidor (PHP, servidor web etc.)
Pedimos que
- Faça as verificações em um ambiente que você mesmo administra e não realize ações ofensivas contra instalações do GeckoFlag operadas por outras pessoas nem contra geckoflag.com.
Se desejar, publicaremos o seu nome como agradecimento nas informações de segurança da versão corrigida.
SHA-256 dos arquivos distribuídos
Você pode confirmar se o arquivo baixado é idêntico ao oficial comparando-o com os valores abaixo.
| Arquivo | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
Como verificar: no Windows, execute Get-FileHash nome-do-arquivo -Algorithm SHA256 no PowerShell; no macOS e no Linux, execute shasum -a 256 nome-do-arquivo.
Configurações recomendadas para um uso seguro
A segurança do GeckoFlag também depende da configuração do servidor onde ele é instalado. Recomendamos as configurações a seguir.
- Conclua a instalação logo após enviar os arquivos: até que a instalação termine, qualquer pessoa que conheça a URL pode abrir a tela de configuração. Depois de colocar os arquivos no servidor, conclua a instalação imediatamente.
- Use HTTPS: as credenciais de acesso e o conteúdo dos projetos são transmitidos de forma criptografada. Muitos provedores de hospedagem oferecem certificados SSL gratuitos. Observe que, depois que o site é aberto uma vez por HTTPS, o navegador passa a se conectar a esse endereço por HTTPS durante 1 ano (v1.10.0 ou posterior). Tenha cuidado se pretende deixar de usar HTTPS.
- Defina webroot como pasta pública (document root): assim, os arquivos de configuração e os logs ficam em um local inacessível pela web.
- Se usar Nginx, adicione a configuração necessária: no Nginx, o .htaccess não tem efeito. Configure separadamente a negação de acesso às pastas privadas e impeça a execução de PHP no destino do envio de imagens (webroot/img). Veja um exemplo de configuração no manual (Instalação).
- Atualize para a versão mais recente: as correções de segurança são fornecidas na versão mais recente. Obtenha os arquivos de atualização no site oficial e confira o SHA-256. A partir da v1.10.0, a assinatura também é verificada automaticamente antes da atualização.
- Mantenha o PHP e o banco de dados em versões com suporte: versões do PHP cujo suporte terminou não recebem correções.
- Proteja as contas de administrador: use senhas longas e difíceis de adivinhar e conceda permissões de administrador somente a quem realmente precisa.
- Para uso interno, use a restrição por IP: em “Configurações”, é possível limitar os endereços IP que podem acessar o sistema.
- Faça backups regularmente: guarde o banco de dados e os arquivos enviados em um local separado do servidor.