Skip to content

Pre master laje 260810 - #2003

Open
GabrielPintoSouza wants to merge 38 commits into
masterfrom
pre-master-LAJE-260810
Open

Pre master laje 260810#2003
GabrielPintoSouza wants to merge 38 commits into
masterfrom
pre-master-LAJE-260810

Conversation

@GabrielPintoSouza

@GabrielPintoSouza GabrielPintoSouza commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

Alterações no banco de dados:

-- -----------------------------------------------------
-- Table `wegia`.`registro_profissional_tipo`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `wegia`.`registro_profissional_tipo` (
  `id_registro_profissional_tipo` INT(11) NOT NULL AUTO_INCREMENT,
  `descricao` VARCHAR(40) NOT NULL,
  `status` BOOLEAN NULL DEFAULT TRUE,
  PRIMARY KEY (`id_registro_profissional_tipo`),
  UNIQUE INDEX `descricao` (`descricao` ASC))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `wegia`.`registro_profissional_identificador`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `wegia`.`registro_profissional_identificador`(
  `id_registro_profissional_identificador` INT(11) NOT NULL AUTO_INCREMENT,
  `id_registro_profissional_tipo` INT(11)  NOT NULL,
  `id_funcionario` INT(11)  NOT NULL,
  `numero_registro` VARCHAR(20) NOT NULL,
  `UF` varchar(2) NULL,
  PRIMARY KEY  (`id_registro_profissional_identificador`),
  UNIQUE INDEX `numero_registro` (`numero_registro` ASC),
  INDEX `fk_registro_identificador_funcionario1_idx` (`id_funcionario` ASC),
  INDEX `fk_registro_identificador_tipo_registro1_idx` (`id_registro_profissional_tipo` ASC),
  CONSTRAINT `fk_registro_identificador_funcionario1_idx`
    FOREIGN KEY (`id_funcionario`)
    REFERENCES `wegia`.`funcionario` (`id_funcionario`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_registro_identificador_tipo_registro1_idx`
    FOREIGN KEY (`id_registro_profissional_tipo`)
    REFERENCES `wegia`.`registro_profissional_tipo` (`id_registro_profissional_tipo`)
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB;

KayllaneBSanches and others added 30 commits July 29, 2026 10:14
…ndido, adição de title descritivo e adição de condição para o botão só ser exibino no profile_atendido se existir ficha médica associada ao atendido
…pos de registros profissionais ao cadastrar funcionário [issue #1558]
…ntrole para os tipos de registros profissionais
…ificadorRegistroProfissionalControle.php e em TipoRegistroProfissional.php [PR #1985]
…ntrole e remoção da lógica de permissão e chamada de métodos pelo IdentificadorRegistroProfissionalControle [PR #1985]
@GabrielPintoSouza GabrielPintoSouza self-assigned this Aug 26, 2026
id_acao é uma bitmask (1=SEM ACESSO, 3=GRAVAR E EXECUTAR, 5=LER E
EXECUTAR, 7=LER, GRAVAR E EXECUTAR), mas o gate comparava com "<". Isso
deixava passar, por exemplo, um cargo com 5 (leitura) por uma exigência
de 3 (escrita) — e principalmente deixava SEM ACESSO (1) passar sempre
que a chamada usava o nível padrão (também 1, "1 < 1" é falso). 23
pontos do código (entre eles exportar_dump.php e gerenciar_backup.php,
no módulo de Configurações) omitem o terceiro parâmetro e dependiam
desse default.

Corrigido: SEM ACESSO agora nega explicitamente, e o restante é
verificado via bitwise AND (o cargo precisa ter todos os bits
exigidos, não só um valor numericamente maior).

Validado com a função real contra o banco (não uma reimplementação),
reproduzindo a matriz de decisão completa do relatório: SEM ACESSO
sempre negado, e um cargo com 5 corretamente negado numa exigência de
3 (antes passava).

Refs: https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-fq5p-pjvq-7qxf

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013QAx9wDuRKcxkqpmgEQNQY
…ss do token mascarado

O dispatcher (control.php) autorizava GatewayPagamentoController contra
o recurso 7 (Contribuições), nível operacional usado pra registrar
boleto/sincronizar pagamento — não o recurso 9 (Configurações) que a
própria tela gateway_pagamento.php exige. Um operador de contribuições
com esse nível conseguia repontar o endpoint do gateway de pagamento.

Combinado com isso, GatewayPagamento::editar() só verificava se o token
enviado estava "mascarado" (contém *) pra decidir se reaproveitava o
token real salvo — sem checar se o endpoint também estava mudando.
Resultado: dava pra trocar o endpoint pra um servidor de terceiros
mantendo o token mascarado, e o token real salvo continuava sendo
enviado (agora pro host do atacante) nas próximas cobranças.

Corrigido:
- control.php: GatewayPagamentoController passa a exigir recurso 9.
- GatewayPagamento::editar(): se o endpoint mudar enquanto o token
  continua mascarado, a edição é recusada — o token precisa ser
  reinformado.
- GatewayPagamento::setEndpoint(): exige URL HTTPS válida (bloqueia o
  "http://attacker.tld/collect" do PoC do relatório).
- GatewayPagamentoDAO::buscarEndpointPorId(): novo método de apoio pra
  comparar o endpoint atual, independente do status do gateway.

Validado com banco de teste isolado (mesmo schema desta branch):
reproduzido o PoC exato (endpoint trocado + token=***) → recusado;
edição legítima (só nome, token mascarado, endpoint igual) → permitida;
reenvio do token real com novo endpoint → permitido; endpoint http:// →
recusado na criação do objeto. Também validado que um operador com
apenas o recurso 7 nível 3 (a precondição exata do relatório) continua
acessando MeioPagamentoController/RegraPagamentoController normalmente,
mas não alcança mais GatewayPagamentoController.

Refs: https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-cvwg-5rhv-q8pv

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013QAx9wDuRKcxkqpmgEQNQY
… sucesso.php

O gate de sessão só enviava um header de redirecionamento sem exit(),
e extract($_REQUEST) em seguida importava qualquer chave da requisição
como variável global — incluindo uma chave literal "_SESSION", que
sobrescrevia a superglobal $_SESSION de verdade pro resto da
requisição. As três chaves (msg, link, proxima) eram ecoadas sem
htmlspecialchars(), então um atacante que induzisse uma vítima já
autenticada a clicar num link malicioso conseguia rodar JavaScript
arbitrário no domínio da aplicação.

Corrigido: removido o extract($_REQUEST) (não tinha função legítima —
as três variáveis usadas mais abaixo já são $_SESSION, definidas por
outras páginas antes do redirect), adicionado exit() após o
header("Location: ...") e escapado o output com htmlspecialchars().

Validado simulando sessão autenticada real + o payload exato do PoC do
relatório: $_SESSION não é mais sobrescrito (a mensagem legítima
definida antes permanece intacta) e o payload <script> não aparece em
lugar nenhum do HTML renderizado. Fluxo legítimo de mensagem de sucesso
segue funcionando normalmente.

Refs: https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-qx7r-ffrg-8hxq

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013QAx9wDuRKcxkqpmgEQNQY
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants