No momento em que escrevo esta publicação, estou indo para o 3º período do Bacharelado em Tecnologia da Informação na Universidade Federal do Rio Grande do Norte (UFRN). E sim, é isso mesmo que você leu no título. Mas calma, não se preocupe: os dados de todo mundo estão protegidos e nada foi vazado. Deixe-me contar melhor como tudo isso aconteceu.

O sistema de gestão acadêmica utilizado pela UFRN é o SIGAA (Sistema Integrado de Gestão de Atividades Acadêmicas), desenvolvido aqui pela Superintendência de Tecnologia da Informação (STI) da universidade. Ele é amplamente utilizado por dezenas de instituições em todo o Brasil, incluindo outras universidades federais (UnB, UFC, UFPB, UFPI), universidades estaduais e institutos federais. Não tenho números exatos, mas o total de usuários, somando todas as instituições, pode ultrapassar 1 milhão.

A STI/UFRN mantém uma API que permite interagir com dados do SIGAA e de outros sistemas. Essa API é de uso restrito e, normalmente, é necessário um processo formal para obter credenciais. Um dos clientes dessa API é o SIGAA Mobile, um app nativo com interface simples que permite aos alunos acessarem notas, horários e notícias.

#A Curiosidade Matou o Gato? (Quase)

Como estudante de TI, sou naturalmente curioso sobre o funcionamento das coisas e gosto de criar ferramentas que facilitem a vida. No ensino médio (IFRN), ajudei a criar um aplicativo (App Save) que resolvia a falta de uma interface mobile decente para o sistema de lá.

Eu tinha planos de fazer algo parecido para a UFRN, talvez um chatbot com IA para consultar notas e outras informações. Como eu não sabia da existência da API naquele momento (e mesmo se soubesse não teria as credenciais), resolvi fazer engenharia reversa para entender como o SIGAA Mobile funcionava. Instalei o app no emulador Android Genymotion e utilizei o HTTP Toolkit para inspecionar as requisições (man-in-the-middle) e entender o tráfego de dados. Tudo isso em um ambiente controlado, usando apenas minha própria conta.

Ao inspecionar o tráfego, descobri os a existência da API, e consegui encontrar a documentação. A partir daí, comecei a estudar como ela se comportava: testei extensivamente vários endpoints para ver quais dados retornavam e quais eram os limites de validação (também testei inputs como 9999999999, 0 e -1 só para ver se o que acontecia 🙃).

A API é complexa — possui centenas de endpoints. O fluxo de dados é fragmentado: para começar, eu precisava primeiro pegar meu id_usuario, depois listar meus vinculos (graduação, mestrado, etc.), selecionar o vínculo ativo e só então chamar os enpoints que eu queria (notas, turmas, etc).

Muitos endpoints retornavam acesso negado, outros traziam apenas dados públicos. Mas eu continuei "cutucando".

#O Momento "Eita..."

Em certo momento, me deparei com um endpoint relacionado a busca de "usuários". Resolvi testar, esperando receber um erro de permissão.

Quando executei a requisição, veio a surpresa: a API retornou o objeto JSON completo contendo nome, CPF e e-mail pessoal de usuários cadastrados no sistema. Isso incluía não apenas alunos, mas provavelmente professores e servidores.

Fiquei em choque. Cheguei a cogitar se aqueles dados seriam públicos por alguma lei de transparência, mas pesquisei e vi que, à luz da LGPD, aquilo era uma exposição crítica. Essa falha figura no topo da lista de problemas de segurança mais comuns da OWASP Top 10 de 2025.

Não explorei a fundo para não coletar dados indevidos, mas o potencial de extração era massivo, abrangendo registros de décadas.

Naquele momento, o medo bateu. "Será que serei processado?", "Será se foi errado eu ter explorado o sistema dessa maneira?". Mas a ética falou mais alto: eu precisava reportar aquilo antes que alguém mal-intencionado descobrisse.

#Responsible Disclosure (Divulgação Responsável)

Imediatamente interrompi os testes e redigi um relatório técnico. Enviei um e-mail para a STI detalhando a vulnerabilidade, o passo a passo para reprodução e o impacto (exposição de CPF/E-mails), deixando claro que não realizei extração de dados de terceiros, apenas a validação da falha.

A resposta foi exemplar.

A equipe da STI entrou em contato comigo no mesmo dia. Tive uma reunião com a diretoria, onde expliquei o ocorrido. Recebi agradecimentos pela postura ética e profissional. Fui convidado a participar de processos seletivos para bolsas para me juntar à equipe e mantivemos o acordo de que eu só falaria publicamente sobre isso após a correção.

O patch de segurança foi aplicado poucos dias depois, corrigindo as permissões de acesso nos endpoints afetados.

#Conclusão

Fiquei muito feliz com o desfecho. A STI demonstrou ser uma equipe madura e profissional, e fico honrado em ter contribuído — mesmo que acidentalmente — para a segurança dos dados de toda a comunidade acadêmica da UFRN.

Essa experiência reforçou para mim que, agir com ética e responsabilidade, mesmo em situações delicadas, é sempre o melhor caminho.

Às vezes precisamos baixar uma pasta de um repositório no GitHub sem clonar tudo. Por exemplo, quando você quer acessar apenas a pasta "exemplos" de um projeto. Claro você pode simplesmente clonar o repositório inteiro, mas você pode querer algo mais simples, ou o reposítório é muito grande,o que demora para baixar e consome muito espaço. Vou mostrar três formas práticas de fazer isso.

#1. Usando o DownGit (ferramenta online)

Uma das maneiras mais fáceis é utilizando a ferramenta online DownGit, ele cria um arquivo ZIP contendo apenas o conteúdo da pasta desejada. Siga os passos abaixo:

1. Acesse o DownGit.
2. Cole a URL da pasta do GitHub (ex: https://github.com/usuario/repo/tree/main/pasta).
3. Clique em Download.

Dica: Você pode criar links para download diretos prefixando a URL da pasta com https://downgit.github.io/#/home?url=.

#2. Usando o Degit (Node.js)

Outra opção é utilizar a ferramenta de linha de comando Degit. Ela vai fazer o download de todos os arquivos do repositório, sem o histórico do Git (sem a pasta .git, o que o torna mais leve que o git clone), mas permite que você extraia apenas a pasta desejada. Basta executar o comando abaixo:

npx degit usuario/repositorio/caminho para pasta#branch ou tag destino

#3. Usando o Git Sparse Checkout (nativo)

Esse método não é tão simples quanto os anteriores, mas o git tem uma funcionalidade nativa e robusta para essa finalidade, chamada Sparse Checkout. Diferente do Degit, esse método vai baixar apenas os metadados (estrutura de pastas, etc) e os arquivos que você especificar. Basta executar os comandos abaixo:

git clone --filter=blob:none --no-checkout url do repositorio

cd pasta do repositorio

git sparse-checkout init --cone

git sparse-checkout set caminho da pasta que você quer baixar

git checkout branch