<![CDATA[Stories by Larissa Fabiao Fonseca on Medium]]> https://medium.com/@larissafabiaofonseca?source=rss-9ab5b6cb7101------2 https://cdn-images-1.medium.com/fit/c/150/150/1*2soCcAcESrmMjiNHycj73Q.jpeg Stories by Larissa Fabiao Fonseca on Medium https://medium.com/@larissafabiaofonseca?source=rss-9ab5b6cb7101------2 Medium Sat, 14 Nov 2026 15:27:26 GMT <![CDATA[Código seguro com o Horusec]]> https://larissafabiaofonseca.medium.com/c%C3%B3digo-seguro-com-o-horusec-539f9f4a154?source=rss-9ab5b6cb7101------2 https://medium.com/p/539f9f4a154 Fri, 30 Apr 2021 20:08:44 GMT 2021-04-30T20:08:44.634Z

Como analista de segurança da informação, uma das funções que lido diariamente é a necessidade de garantir que os produtos em desenvolvimento pela minha equipe estejam de acordo os padrões de segurança esperados. Mesmo desenvolvedores experientes podem deixar passar um pequeno detalhe no código que pode prejudicar a segurança de seu produto. Para auxiliar neste processo, ferramentas de análise estática sempre são bem vindas, principalmente considerando que as mesmas podem ser embutidas na pipeline de forma a automatizar sua execução.

A análise estática de código consiste em analisar linha a linha do código fonte para verificar se algum padrão de código vulnerável está sendo utilizado ou ainda se alguma biblioteca ou framework com falhas de segurança está em uso. Com base nisto, uma ótima opção de ferramenta que realiza esse processo é o framework Horusec, o qual irei explorar e neste artigo através da utilização de sua versão CLI.

https://www.horusec.io/site/

O Horusec realiza uma análise de código estática combinando diversas ferramentas de segurança para garantir uma verificação completa do código e também uma maior cobertura de linguagens suportadas pela mesma . Por ser open source, temos como vantagem o fato de ser gratuita e de podermos colaborar com o seu desenvolvimento. Além disso, temos como vantagem a fácil utilização da ferramenta, a qual vamos entender a seguir.

Para a construção deste artigo, utilizei o ubuntu 20.04, tendo como pré requisito a instalação do docker para a instalação do Horusec, e também a intalação do Git e GitHub para obter o projeto utilizado como exemplo.

GitHub - ZupIT/horusec: Horusec is an open source tool that improves identification of vulnerabilities in your project with just one command.

Como instalar?

Antes de começar a instalação do horus, certifique-se de que possui o Docker com uma versão igual ou superior a versão 19.0. Para verificar se sua máquina já possui o Docker de acordo com os critérios previamente citados, execute o seguinte comando:

docker version

Agora que sabemos que seu computador possui os pré requisitos, vamos iniciar a instalação do Horusec. Para isso, neste tutorial, utilizaremos o terminal (ou cmd) do windows ou do linux, utilizando seus respectivos comandos para a instalação da última versão disponível:

Para sistemas Mac ou Linux:

curl -fsSL https://horusec.io/bin/install.sh | bash

Para Windows:

curl “https://horusec.exe" -o “./horusec.exe” && ./horusec.exe version

Vale ressaltar que a ferramenta é compatível com os sistemas linux_x86, linux_x64, mac_x64, win_x86 e win_x64. Para instalar outras versões do horus pode-se utilizar a instalação manual. Para mais informações sobre a instalação, consultar a documentação do projeto, disponibilizada aqui.

Como executar?

Como exemplo, usarei um projeto criado propositalmente com algumas vulnerabilidades comuns, este projeto está disponível neste repositório. Para executar o horus é necessário clonar o repositório localmente, caso o mesmo já não esteja em sua máquina, e dentro do terminal navegar até a pasta do projeto. Após localiza-lo, devemos migrar para a branch desejada caso existam múltiplas branchs no projeto. Por fim, para iniciar a análise, o seguinte comando deverá ser executado para realizar uma análise simples:

horusec start

Após executar o comando, você terá que confirmar se o diretório selecionado corresponde ao desejado para executar realizar a varredura do Horus e posteriormente verá que serão exibidas diversas mensagens informando o tempo restante de análise. Caso precise de análises mais complexas, a ferramenta possibilita a inclusão de parâmetros para configurar itens adicionais à análise. Os principais parâmetros são:

  • -t : usado para definir o timeout da análise, o qual é por padrão 600 segundos.
  • -G : usado para habilitar a busca exibindo o autor da vulnerabilidade. Para usar definimos como -G=”true”.
  • --enable-git-history : usado para habilitar a análise em todo o histórico de modificações do github, muito útil para encontrar vulnerabilidades como credenciais hardcoded corrigidas porém ainda salvas no histórico do github. Para utilizar, adicionamos o parâmetro da seguinte forma: — enable-git-history=”true”.
  • -F : usado para ignorar vulnerabilidades de acordo com hash identificador da mesma (veremos mais sobre isso na próxima seção). Usado no formato -F=”hash-da-vulnerabilidade”.
  • -i : determinar paths que serão excluídos da análise.
  • -s : definir níveis de vulnerabilidade que devem ser ignorados. Usado da seguinte forma: -s:”LOW,MEDIUM, NOSEC”.
  • -O : usado para configurar o local de saída caso selecionado para o resultado ir para um arquivo. Usado da seguinte forma: -O=”caminho-do-local”.
  • -o : definir um formato de saída para que o resultado da análise seja enviado para um arquivo. Os formatos aceitos são json, sonarqube ou text.

Para ver todos os parâmetros que podem ser utilizados com a ferramenta para aprimorar a análise, execute o comando:

horusec start --help

Como analisar?

Agora que já sabemos como executar a ferramenta para analisar o código, precisamos entender o relatório criado após a sua execução. Todos os exemplos mostrados a seguir correspondem a uma análise simples executada no projeto previamente citado.

Após executar a análise, o seguinte resultado será exibido no terminal:

$ horusec start
✔ The folder selected is: [/home/exemple/InsecureCode]. Proceed? [Y/n]
WARN[0006] {HORUSEC_CLI} When starting the analysis WE SKIP A TOTAL OF 277 FILES that are not considered to be analyzed. To see more details use flag --log-level=debug
WARN[0006] {HORUSEC_CLI} PLEASE DON'T REMOVE ".horusec" FOLDER BEFORE THE ANALYSIS FINISH! Don’t worry, we’ll remove it after the analysis ends automatically! Project sent to folder in location: [/home/exemple/InsecureCode/.horusec/690c2ec4-c580-4975-b21c-dcfca794108a]
INFO[0006] Hold on! Horusec still analysis your code. Timeout in: 600s 
INFO[0021] Hold on! Horusec still analysis your code. Timeout in: 585s 
WARN[0036] {HORUSEC_CLI} Horusec not show info vulnerabilities in this analysis, to see info vulnerabilities add option "enableInformationSeverity"="true". For more details use (horusec start --help) command.
==================================================================================
HORUSEC ENDED THE ANALYSIS WITH STATUS OF "success" AND WITH THE FOLLOWING RESULTS:
==================================================================================
Analysis StartedAt: 2021-01-21 21:08:10
Analysis FinishedAt: 2021-01-21 21:08:40
==================================================================================
Language: Java
Severity: HIGH
Line: 21
Column: 0
SecurityTool: HorusecJava
Confidence: LOW
File: //home/exemple/InsecureCode/CWE89_SQL_Injection__connect_tcp_execute_01.java
Code: import javax.servlet.http.*;
Details: Web applications should not have a main method
Having a main method in a web application opens a door to the application logic that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be present. For more information checkout the CWE-489 (https://cwe.mitre.org/data/definitions/489.html) advisory.
Type: Vulnerability
ReferenceHash: 8005bf5843d10e9ebef303691d2718bccc74752d9379189cb42a84af7fee151a
==================================================================================
Language: Java
Severity: HIGH
Line: 20
Column: 0
SecurityTool: HorusecJava
Confidence: LOW
File: /home/exemple/InsecureCode/CWE614_Sensitive_Cookie_Without_Secure__Servlet_03.java
Code: import javax.servlet.http.*;
Details: Web applications should not have a main method
Having a main method in a web application opens a door to the application logic that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be present. For more information checkout the CWE-489 (https://cwe.mitre.org/data/definitions/489.html) advisory.
Type: Vulnerability
ReferenceHash: 8a1bc784e471da40f2196cf61f6f512c919f411578f2b2070efcb2a0dca64835
==================================================================================
Language: Java
Severity: HIGH
Line: 20
Column: 0
SecurityTool: HorusecJava
Confidence: LOW
File: /home/exemple/InsecureCode/CWE598_Information_Exposure_QueryString__Servlet_08.java
Code: import javax.servlet.http.*;
Details: Web applications should not have a main method
Having a main method in a web application opens a door to the application logic that an attacker may never be able to reach (but watch out if one does!), but it is a sloppy practice and indicates that other problems may be present. For more information checkout the CWE-489 (https://cwe.mitre.org/data/definitions/489.html) advisory.
Type: Vulnerability
ReferenceHash: d641bd0928f23149ea285ba4a47631d924bd9e04eb89b92bb66744be5bdc76e2
==================================================================================
Language: Java
Severity: HIGH
Line: 115
Column: 51
SecurityTool: HorusecJava
Confidence: LOW
File: /home/exemple/InsecureCode/CWE89_SQL_Injection__connect_tcp_execute_01.java
Code: users (status) values ('updated') where name='"+data+"'");
Details: SQL Injection
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, each parameter can be escaped manually. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.
Type: Vulnerability
ReferenceHash: 37a7cf46d0838d9c0ac94d025e08cb688601cd05501c8149ec81f3eb84c3db7d
==================================================================================
Language: Java
Severity: HIGH
Line: 27
Column: 13
SecurityTool: Semgrep
Confidence: 
File: /home/exemple/InsecureCode/CWE614_Sensitive_Cookie_Without_Secure__Servlet_03.java
Code:         if (5 == 5)
Details: `5 == 5` or `5 != 5` is always true. (Unless the value compared is a float or double).
To test if `5` is not-a-number, use `Double.isNaN(5)`.
Type: Vulnerability
ReferenceHash: 1ea89b0d9469dd8c80b72e26941e11fd53c36a3fe3d8f42095498696f299dc75
==================================================================================
Language: Java
Severity: HIGH
Line: 41
Column: 13
SecurityTool: Semgrep
Confidence: 
File: /home/exemple/InsecureCode/CWE614_Sensitive_Cookie_Without_Secure__Servlet_03.java
Code:         if (5 != 5)
Details: `5 == 5` or `5 != 5` is always true. (Unless the value compared is a float or double).
To test if `5` is not-a-number, use `Double.isNaN(5)`.
Type: Vulnerability
ReferenceHash: 4f3944bd0fa8993cce4dee80471349500936603a60fecf72c8c10a9ef853e933
==================================================================================
Language: Java
Severity: HIGH
Line: 63
Column: 13
SecurityTool: Semgrep
Confidence: 
File: /home/exemple/InsecureCode/CWE614_Sensitive_Cookie_Without_Secure__Servlet_03.java
Code:         if (5 == 5)
Details: `5 == 5` or `5 != 5` is always true. (Unless the value compared is a float or double).
To test if `5` is not-a-number, use `Double.isNaN(5)`.
Type: Vulnerability
ReferenceHash: 0534f1b6ab9966d4293a032237c02e75d94c97e1b038c32b89f539b373e815ed
==================================================================================
Language: Java
Severity: LOW
Line: 50
Column: 25
SecurityTool: HorusecJava
Confidence: LOW
File: /home/exemple/InsecureCode/CWE89_SQL_Injection__connect_tcp_execute_01.java
Code: socket = new Socket("host.example.org", 39544);
Details: TCP Socket
TCP Socket
Type: Vulnerability
ReferenceHash: f43756ac18b471805a27f2bdc065aeb765cfd59a99c6d0581909204cba69a5f8
==================================================================================
In this analysis, a total of 8 possible vulnerabilities were found and we classified them into:
Total of Vulnerability HIGH is: 7
Total of Vulnerability LOW is: 1
==================================================================================
WARN[0036] {HORUSEC_CLI} No authorization token was found, your code it is not going to be sent to horusec. Please enter a token with the -a flag to configure and save your analysis
WARN[0036] [HORUSEC] 8 VULNERABILITIES WERE FOUND IN YOUR CODE SENT TO HORUSEC, TO SEE MORE DETAILS USE THE LOG LEVEL AS DEBUG AND TRY AGAIN

Podemos notar que são exibidas diversas informações acerca da execução enquanto a mesma é executada e após finalizado o processo, são exibidas as vulnerabilidades encontradas em um formato padrão:

  • Language: informa a linguagem do trecho de código sendo reportado.
  • Severity: informa a severidade da vulnerabilidade, podendo ser CRITICAL(crítico), HIGH(alto), MEDIUM(médio), LOW(baixo), INFO(vulnerabilidade informativa), NOSEC (Falso positivo) e RISCO ACEITO.
  • Line: linha do código em que a vulnerabilidade foi encontrada.
  • Column: coluna do código em que a vulnerabilidade foi encontrada.
  • SecurityTool: ferramenta de segurança que encontrou a vulnerabilidade.
  • Confidence: mostra o nível de confiança que a ferramenta possui da vulnerabilidade, ou seja, quanto menor o nível maior é a necessidade de uma segunda análise manual.
  • File: exibe o caminho e o arquivo em que a vulnerabilidade foi encontrada.
  • Code: Trecho de código vulnerável
  • Details: exibe uma pequena descrição da vulnerabilidade, podendo conter um link para a classificação cwe mitre da vulnerabilidade.
  • Type: define o tipo de informação retornada, como por exemplo se é uma vulnerabilidade ou apenas uma informação.
  • ReferenceHash: hash única usada para identificar a vulnerabilidade reportada, sendo esta a usada para o caso de querermos eliminar uma vulnerabilidade específica por considera-la um falso positivo.

Conhecendo os tópicos do relatório, podemos agora tomar como exemplo uma das vulnerabilidades e tentar compreende-la como um todo. Selecionei o seguinte item do relatório:

Language: Java
Severity: HIGH
Line: 115
Column: 51
SecurityTool: HorusecJava
Confidence: LOW
File: /home/exemple/InsecureCode/CWE89_SQL_Injection__connect_tcp_execute_01.java
Code: users (status) values ('updated') where name='"+data+"'");
Details: SQL Injection
The input values included in SQL queries need to be passed in safely. Bind variables in prepared statements can be used to easily mitigate the risk of SQL injection. Alternatively to prepare statements, each parameter can be escaped manually. For more information checkout the CWE-89 (https://cwe.mitre.org/data/definitions/89.html) advisory.
Type: Vulnerability
ReferenceHash: 37a7cf46d0838d9c0ac94d025e08cb688601cd05501c8149ec81f3eb84c3db7d

Na vulnerabilidade secionada, inicialmente podemos notar que o códifo foi escrito em Java e que foi identificado pela ferramenta HorusecJava, ou seja, uma ferramenta do próprio horus para reconhecimento de falhas de segurança escritos nesta linguagem. Além disso, vemos que a vulnerabilidade é alta porém com o valor de confidence baixo, estando localizado na linha 115 do arquivo CWE89_SQL_Injection__connect_tcp_execute_01.java . Agora, podemos ver que o trecho de código que gerou o alerta foi o seguinte:

users (status) values ('updated') where name='"+data+"'");

Observando a linha citada e a descrição da vulnerabilidade, notamos que se refere a um risco de SQL Injection, uma vez que estamos passando os valores da query SQL sem nenhum tratamento para garantir que o código não seja burlado com as comuns táticas de SQL injection. Na descrição ainda, observamos que é proposta a solução de utilizar Bind variables (ou variáveis de ligação) ou ainda escapar manualmente os valores para impedir que trechos de código malicioso sejam executados.

Além dos itens previamente criados, temos como informação complementar o link do CWE Mitre correspondente à vulnerabilidade encontrada. Ao acessar o link encontramos uma descrição mais completa da falha de segurança, a relação desta com outras vulnerabilidades reportadas, informações sobre em que plataformas ocorre, o impacto que pode gerar caso explorada, além de exemplos e formas de mitigar. Desta maneira, analisando o CWE disponibilizado podemos encontrar formas comprovadamente seguras para resolver o problema e ainda entender a extensão do impacto que a mesma pode gerar em um código.

Conclusão

Agora que sabemos como instalar, executar e analisar o código com o Horusec, podemos inserir a análise estática de código em nossas rotinas como desenvolvedores. Além de garantir a qualidade do código com base na análise de segurança, utilizando o horus também podemos promover o aprendizado de boas práticas de programação para que cada vez mais possamos escrever algoritmos melhores e mais seguros. Aproveitem da ferramenta e lembrem-se sempre da possibilidade de contribuir para o crescimento da mesma!

Caso tenham alguma dúvida ou feedback deixe um comentário, ficarei feliz em escuta-los.

Sobre mim

Sou a Larissa Fonseca, Analista de segurança na Zup Innovation. Sou apaixonada por segurança da informação e principalmente por participar de capture the flags e amo poder compartilhar meu conhecimento com a comunidade.

Larissa F. - Analista de segurança Jr - Zup Innovation | LinkedIn

Muito obrigada e até mais ! :)

]]>