Conheça o recycle(♻️) do Laravel

Tarcisio Araújo — Wed, 05 Feb 2025 15:04:57 +0000

Quando o assunto é criar estruturas de dados complexas para testes, o Laravel oferece uma ferramenta extremamente poderosa que pode ajudar a economizar recursos e possibilitar a criação de ambientes específicos, garantindo maior assertividade nos testes.

Esta ferramenta é o método recycle(), ele oferece o poder de reutilizar instâncias de models em chamadas a Factories. Isso pode ser extremamente útil quando você precisa criar cenários com Models contendo relações em comum. Por exemplo:

// Cria um Time
$team = Team::factory()->create();

// Cria 3 Vendedores associando-os ao mesmo Time através do recycle
$sellers = Seller::factory(3)->recycle($team)->create();

No exemplo acima, criamos um cenário específico com 3 instâncias de Vendedores associadas ao mesmo Time. Dessa forma, é possível realizar testes com essa estrutura de dados definida, sem a necessidade de configurar manualmente as relações através dos atributos do create().

Utilizando Collections 🗂️

Além de funcionar com instâncias únicas de Models, o método recycle() também aceita Collections. No entanto, quando utilizado com uma Collection, seu comportamento difere do uso básico, oferecendo uma camada extra de flexibilidade na criação de cenários de teste.

$teams = Team::factory(3)->create();

$sellers = Seller::factory(30)->recycle($teams)->create();

Nesse trecho de código passamos uma Collection com três Times distintos no recycle. Desta forma, a cada Vendedor criado, será escolhido aleatoriamente um dos três Times para ser atribuído, construindo um ambiente controlado em que todos os Vendedores estão associados a um desses Times.

Como isso aumenta a performance do meu teste? 📈

Ao criar conjuntos de dados com uma grande quantidade de registros, reciclar instâncias irá poupar recursos e diminuir o número de inserções no banco de dados.

$sellers = Seller::factory(3)->create();

$sales = Sale::factory(500)->create();

Sem o uso do recycle, atingimos um total de 1003 queries! Sendo 3 para criar os primeiros Vendedores, 500 para criar cada Venda e mais 500 para inserir, individualmente, os Vendedores associados a cada Venda.

$sellers = Seller::factory(3)->create();

$sales = Sale::factory(500)->recycle($sellers)->create();

Agora, utilizando o recycle, conseguimos uma redução de 500 chamadas ao banco de dados! Eliminando as instâncias individuais de Vendedores realizadas pelas Factory de Venda.

Conclusão

Reutilizando instâncias de models, ele simplifica a criação de cenários complexos e reduz significativamente o número de queries realizadas. Resultando em testes mais rápidos, eficientes e fáceis de manter. O recycle() acaba mostrando-se uma ferramenta essencial no repertório de qualquer desenvolvedor Laravel, especialmente para quem trabalha com desenvolvimento orientado a testes.

Referência:

- Documentação oficial do Laravel.

Simples Mudanças, Grandes Impactos: Como Fortalecer a Segurança da Sua Aplicação Laravel

Tarcisio Araújo — Sun, 01 Sep 2024 14:10:22 +0000

Se você já trabalhou em algum projeto Laravel com certeza já ter percebido como o framework entrega uma vasta gama de ferramentas uteis para o desenvolvimento. Mas, você já se perguntou se não pode estar deixando passar algum erro? Se ao utilizar essas ferramentas não acabou escapando algum detalhe simples, mas importante para garantir a segurança do seu sistema?

Neste artigo irei mostrar alguns erros "simples", mas muito comuns e fáceis de serem resolvidos.

Fazendo um deploy seguro 🚀

Ao tornar um projeto público na internet é necessário se atentar ao arquivo .env que irá para os ambientes de produção/homologação, ou seja lá qual for o cenário de implantação, pois as chaves APP_ENV e APP_DEBUG podem estar abrindo possíveis vulnerabilidades nestes ambientes.

Qual a utilidade dessas chaves?

APP_ENV = Flag que irá indicar o ambiente atual da aplicação, ela pode receber valores como "local", "production", "staging", "testing", etc.
APP_DEBUG = Flag que irá indicar se o ambiente atual está em modo de debug, ela pode receber um booleano.

Use essa configuração apenas para ambiente de desenvolvimento.

APP_ENV=local
APP_DEBUG=true

Use essa configuração para ambiente de produção.

APP_ENV=production
APP_DEBUG=false

Qual o problema de não usar a configuração certa em produção?

Deixar uma aplicação Laravel no modo debug permite a exibição de mensagens de erros detalhadas, o que é ótimo para desenvolvimento mas, péssimo para outros ambientes, pois pode exibir as seguintes informações sensíveis:

Trechos de código.
Versão do PHP e do Laravel. (Pode ser utilizado para explorar falhas de segurança conhecidas das versões)
Informações do usuário e keys secretas.
Senha do banco de dados.
Estado da chave APP_ENV.

A chave indicando o ambiente estar com o valor "local" pode abrir um leque amplo de vulnerabilidades, que pode ir desde o Telescope, que fica aberto sem necessidade de login até o comportamento de alguma funcionalidade do sistema esteja utilizando o APP_ENV para determinar o fluxo. Como, por exemplo, a seguinte configuração para o consumo de uma api externa:

'api_service' => [
    'key' => env('APP_ENV') === 'production' ? env('API_KEY_PROD') : env('API_KEY_DEV')
]

Validando inputs 🔍

Todo desenvolvedor já deve ter escutado em algum momento da vida "Não confie no usuário" e neste artigo você irá ver mais um motivo para pensar assim.

Vamos imaginar o seguinte cenário, você possui em seu e-commerce um formulário de edição de produtos disponível apenas para os funcionários que não são gerentes, porém esse formulário não possui o campo valor disponível a fim de não permitir alterações por funcionários não autorizados.

Esta é a tabela produtos

id	valor	nome	quantidade	codigo	setor_id
1	100	Panela	4	PAN10323	3
...	...	...	...	...	...

Estas são as regras de validação do seu Form Request

public function rules(): array
{
    return [
        'nome' => 'string|max:255',
        'quantidade' => 'integer|min:0',
        'codigo' => 'string|max:255|unique:itens,codigo',
        'setor_id' => 'exists:setores,id',
    ];
}

E esta é a função utilizada no seu controller:

public function FuncionarioUpdateItem(UpdateItemRequest $request, $id)
{
    $item = Item::findOrFail($id);

    $result = $item->update($request->all());

    return response()->json(['sucesso' => $result], 200);
}

Você verificou e os dados foram atualizados corretamente, as validações foram bem-sucedidas e tudo parece estar em ordem. No entanto, há uma grande falha nesse fluxo: estamos considerando que o formulário enviará apenas quatro campos na requisição.

Mas o que acontece se um usuário mal-intencionado alterar manualmente o HTML da página para adicionar o campo valor? Ou se um invasor até mesmo enviar a requisição por meio de uma plataforma de API, como o Postman, incluindo o campo valor a requisição?

Digamos que o usuário malicioso enviou os seguintes dados para a rota:

{
   valor: 1,
   nome: 'Panela barata',
}

Você iria ter a sua tabela produtos com o seguinte registro:

id	valor	nome	quantidade	codigo	setor_id
1	1	Panela barata	4	PAN10323	3
...	...	...	...	...	...

Agora o produto que custava R$ 100 acabou disponível por R$ 1, e o problema está na forma de extrair os dados do request.

Errado ❌

$request->all();

Assim é retornado TODOS os dados do request.

Certo ✅

$request->validated();

Assim é retornado APENAS os dados validos do request.

Se o Controller do exemplo estivesse utilizando a forma correta de receber os dados, o mesmo exemplo de payload malicioso iria resultar no seguinte registro:

id	valor	nome	quantidade	codigo	setor_id
1	100	Panela barata	4	PAN10323	3
...	...	...	...	...	...

Evitando assim qualquer dado não esperado!

Evitando SQL Injection 💉

Quando falamos de SQL Injection falamos de vulnerabilidades que dão possibilidade para invasores executar comandos SQL indesejados e imprevistos no banco de dados da aplicação.

Exemplo:
Considere que seu sistema possui uma funcionalidade de pesquisa de usuários que executa a seguinte query.

$query = "SELECT * FROM users WHERE username = '$username'";

Considere que a variável $user é dada pelo usuário realizando a busca, se o usuário inserir admin'; DROP TABLE users; -- irá gerar a seguinte consulta.

SELECT * FROM users WHERE username = 'admin'; DROP TABLE users; --'

A consulta gerada é maliciosa e irá derrubar a tabela users inteira gerando um dano gigantesco a integridade da aplicação.

Como proteger minha aplicação?

Os próprios Eloquent ORM e o Query Builder do Laravel possuem uma proteção robusta contra inputs maliciosos e caracteres potencialmente perigosos para suas consultas. Porem devemos tomar cuidado ao utilizar quaisquer métodos que aceitem queries raw, pois estes se mal utilizados, podem resultar em aberturas para injeção de inputs mal-intencionados.

Exemplos:
Errado ❌

$email = $request->email;

DB::select("SELECT * FROM users WHERE email = '" . $email . "'");

Neste caso estamos passando diretamente o input do usuário para a consulta via concatenação de strings, que não irá realizar nenhuma sanitização de parâmetros.

Certo ✅

$email = $request->email;

User::where('email', $email)->get();

Desta forma utilizamos a proteção nativa do Laravel, passando o input como parâmetro da função que irá construir a query.

Certo ✅

$email = $request->email;

DB::select("SELECT * FROM users WHERE email = ?", [$mail]);

Supondo que você tenha realmente a necessidade de utilizar um método que aceite consulta raw, passe os parâmetros através de bindings. Desta forma, o Laravel irá impedir que o input seja interpretado como código SQL e manter a query segura.

Não se esqueça ⚠

Sempre use bindings quando o assunto for consultas com SQL bruto no Laravel.

Utilizando Rate Limit 🚧

Limitar quantas requisições podem ser realizadas em um determinado tempo é essencial para proteger a sua aplicação contra alguns tipos de ataques, como, por exemplo:

Brute Force: Tentativa de "adivinhar" senhas e credenciais realizando inúmeras requisições com combinações possíveis até obter sucesso.
DDoS: Tentativa de sobrecarregar o servidor com uma quantidade massiva de requisições em um curto período.

É recomendável considerar adicionar esta proteção em rotas relacionadas a formas de autenticação ou rotas com uso de token aleatório privado.

Como aplicar?

No arquivo AppServiceProvider.php você irá criar dentro da função boot o seu RateLimiter:

RateLimiter::for('default-limiter', function (Request $request) {
            return Limit::perMinute(10);
});

Pronto, agora com nosso limiter definido iremos aplicar a nossa rota sensível.

Route::middleware('throttle:default-limiter')->group(function () {
    Route::get('/private/{token}', [TokenController::class, 'privateThing']);
});

Considere que esta rota recebe um token gerado aleatoriamente para exibir um dado privado do seu portador. Desta forma estamos definindo um limite de 10 requisições por minuto, evitando um possível ataque por força bruta para adivinhar o token secreto e assim obter acesso à informação privada.

Ainda é possível definir regras específicas e personalizadas para a limitação como, por exemplo, por IP:

RateLimiter::for('default-limiter', function (Request $request) {
    return Limit::perMinute(10)->by($request->ip());
});

Essas limitações são usualmente baseadas em IP e no usuário logado, e são muito importantes para evitar diversos tipos de ataques, inclusive ataques DDoS feito com diversos IPs. Lembre-se sempre de criar regras de limitação robustas!

Se você já utiliza algum kit de autenticação pronto do Laravel como o Breeze ou o Jetstream então parabéns! Suas rotas de login já estão protegidas com Rate Limit.

Atenção ⚠

Preste bastante atenção ao definir as limitações para não afetar o uso normal dos usuários do seu sistema. Em casos de rotas com um fluxo maior de requests é recomendável utilizar o Per-Second Rate Limiting feature do Laravel 11.

Conclusão

Devemos manter sempre um olhar atento para questões de segurança durante o desenvolvimento, pois pequenas decisões ou deslizes aparentemente insignificantes podem resultar em grandes problemas no futuro.

Muito obrigado por ler até aqui! ❤

Forem: Tarcisio Araújo

Conheça o recycle(♻️) do Laravel

Utilizando Collections 🗂️

Como isso aumenta a performance do meu teste? 📈

Conclusão

Referência:

Simples Mudanças, Grandes Impactos: Como Fortalecer a Segurança da Sua Aplicação Laravel

Fazendo um deploy seguro 🚀

Qual a utilidade dessas chaves?

Qual o problema de não usar a configuração certa em produção?

Validando inputs 🔍

Evitando SQL Injection 💉

Como proteger minha aplicação?

Não se esqueça ⚠

Utilizando Rate Limit 🚧

Como aplicar?

Atenção ⚠

Conclusão