Interceptando mensagens de erro com o nginx

Como Desenvolvedores de Software, o cuidado com o quesito segurança de nossas apps é constante e nunca é demais. Sempre que uma de nossas aplicações se tornam públicas, temos o máximo de cuidado para não expor informações privadas e que possam comprometer o funcionamento da mesma, ou até mesmo do negócio como um todo.

Um ponto crucial de atenção que todos devemos ter ao expor uma aplicação para o público é como ela se comporta quando ocorre algum erro e o que é reportado para o usuário nesses cenários. Resposta de erros mal tratadas podem não ser nada demais para a maioria dos usuários, mas tenha certeza que para alguém, vai ser um prato cheio.

Com o intuito de ajudar a mitigar esses problemas, este artigo aborda o uso da feature proxy_intercept_errors do nginx.

O que é o nginx

O nginx é um web server largamente utilizado que pode ter muitas utilidades, as mais comuns são Load Balancer e Reverse Proxy. Nesses casos, podemos fazer diversas tratativas nos detalhes das requisições antes e depois do processamento por parte de nossas apps.

A imagem abaixo é uma representação básica de como o nginx pode ser utilizado:

Substituindo mensagens de erro

Para vermos a interceptação de erros em ação, vamos criar um projetinho simples usando Go, nginx e docker-compose.

Você pode encontrar o repositório de exemplo aqui.

Aplicação

Nosso exemplo é uma aplicação simples em Go contendo um http server simples com as seguintes rotas e seus respectivos códigos de retorno:

• /success, 200;
• /bad_request, 400;
• /not_found, 404;
• /internal_server_error, 500.

package main import ( "net/http" "github.com/gofiber/fiber/v2" ) func main() { app := fiber.New() app.Get("/success", func(c *fiber.Ctx) error { c.Set("Content-Type", "application/json") return c.SendString(`{"message": "success"}`) }) app.Get("/bad_request", func(c *fiber.Ctx) error { c.Set("Content-Type", "application/json") return c.Status(http.StatusBadRequest).SendString(`{"error": "The new password cannot be the same as the previous one"}`) }) app.Get("/not_found", func(c *fiber.Ctx) error { c.Set("Content-Type", "application/json") return c.Status(http.StatusNotFound).SendString(`{"error":"This resource is not found at database 'vuln'"`) }) app.Get("/internal_server_error", func(c *fiber.Ctx) error { c.Set("Content-Type", "application/json") return c.Status(http.StatusInternalServerError).SendString(`{"error":"Error log with private information"`) }) app.Listen(":8000") } 

A ideia é justamente podermos simular vários códigos de erro para testar nossa feat de interceptação de erros. Imagine que em um cenário real qualquer um desses retornos possa carregar uma informação que o cliente não possa ter acesso.

Configuração do nginx

De maneira bem simples, nosso arquivo de configuração do nginx ficou mais ou menos assim:

events{} http { server { listen 80; error_page 404 500 /custom_err.html; error_page 400 @error400; location / { # proxy_intercept_errors on; proxy_pass http://app:8000; } location = /custom_err.html { root /usr/share/nginx/html; internal; } location @error400 { default_type application/json; internal; return 400 '{"error": {"status_code": 400,"status": "Bad Request"}}'; } } } 

Sim, a linha comentada é intencional.

Testando a aplicação

Antes de entendermos melhor essa como tudo funciona, vamos ver nosso exemplo em ação. Execute o seguinte comando para iniciar nossa aplicação:

$ make run 

Assim que estiver tudo rodando, vamos testar um dos endpoints de erro:

$ curl -i localhost/not_found 

O resultado deve ser esse:

HTTP/1.1 404 Not Found Server: nginx/1.25.3 Date: Sun, 12 Nov 2023 02:42:58 GMT Content-Type: application/json Content-Length: 56 Connection: keep-alive {"error":"This resource is not found at database 'vuln'" 

E voila! Tivemos uma resposta com informações comprometedoras.

Interceptando erros

Removendo o comentário, nosso location /fica assim:

 #... location / { proxy_intercept_errors on; proxy_pass http://app:8000; } #... 

Chamando o mesmo endpoint que antes, temos esse novo retorno:

HTTP/1.1 404 Not Found Server: nginx/1.25.3 Date: Sun, 12 Nov 2023 02:43:50 GMT Content-Type: text/html Content-Length: 250 Connection: keep-alive ETag: "654cd606-fa" <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Error page</title> </head> <body> <h1>Ops... This is a custom error page</h1> </body> </html> 

Isso significa que o Nginx interceptou nosso retorno de erro e substituiu pelo retorno de nossa página de erro customizada. E segundo a documentação, esse recurso é desabilitado por padrão.

É possível também retornar alguns outros formatos de resposta, como quando executamos o comando:

$ curl -i localhost/bad_request 

Que retorna a seguinte resposta:

HTTP/1.1 400 Bad Request Server: nginx/1.25.3 Date: Sun, 12 Nov 2023 02:57:55 GMT Content-Type: application/json Content-Length: 55 Connection: close {"error": {"status_code": 400,"status": "Bad Request"}} 

Como já deu para perceber, a resposta a ser retornada é definida pela config error_page.

Conclusão

Por mais que seja uma configuração simples, a interceptação de erros por parte do nginx pode ajudar a mitigar vários problemas. Esse post demonstrou uma das muitas maneiras de utilizar esse recurso.

Não esqueça de testar você mesmo o nosso exemplo aqui apresentado e explorar as mais diversas formas de usar essa e outras features do nginx.

And keep learning!

Créditos de imagem:

Cover image: Photo by David Pupăză on Unsplash