Segurança
1Introdução
O Temma fornece nativamente um conjunto de ferramentas para proteger suas aplicações web: autenticação e controle de acesso, validação dos dados de entrada, proteção contra injeções de SQL, XSS e CSRF, sessões seguras…
Esta página apresenta uma visão geral das boas práticas de segurança em uma aplicação Temma. Cada seção contém links para as páginas de documentação detalhadas.
2Autenticação e controle de acesso
O Temma fornece um sistema completo de autenticação de usuários, além de um mecanismo de controle de acesso baseado em papéis (roles) e serviços.
- A página Autenticação explica passo a passo como implementar um sistema de autenticação sem senha (passwordless).
- O controlador/plugin Auth gerencia o formulário de login, o envio de links mágicos por e-mail e a sessão do usuário.
- O atributo Auth restringe o acesso aos controladores e às ações de acordo com a autenticação do usuário, seus papéis e seus serviços.
- O plugin API protege as APIs com autenticação por chaves públicas/privadas.
3Validação dos dados de entrada
Qualquer dado vindo de fora (parâmetros de URL, variáveis GET e POST, payload JSON, arquivos enviados) deve ser validado antes de ser usado.
- A página Validação de dados apresenta o sistema completo de validação do Temma, tanto na entrada quanto na saída.
- Os atributos Check validam os dados de entrada de forma declarativa, diretamente nos controladores e nas ações.
- O helper DataFilter valida e filtra dados a partir de um contrato que define o tipo e as restrições esperados.
4Injeções de SQL
Uma injeção de SQL consiste em executar consultas arbitrárias aproveitando dados inseridos em uma consulta sem escape. Nunca construa uma consulta SQL concatenando dados não escapados.
A fonte de dados SQL fornece tudo o que é necessário para se proteger:
- O parâmetro parameters dos métodos exec(), queryOne() e queryAll(), que escapa os valores automaticamente.
- As requisições preparadas, cujos parâmetros também são escapados automaticamente.
- Os métodos quote() e quoteNull() para os escapes explícitos.
5Cross-site scripting (XSS)
Um ataque XSS consiste em fazer o site exibir código HTML ou JavaScript malicioso, geralmente injetado por meio de conteúdos fornecidos pelos usuários.
- A view Smarty ativa o escape automático por padrão: todas as variáveis exibidas nos templates são escapadas, salvo uso explícito do modificador |raw. Use esse modificador apenas em conteúdos seguros.
- O helper HTMLCleaner limpa os fluxos HTML fornecidos pelos usuários (por exemplo, vindos de um editor WYSIWYG), removendo qualquer código proibido.
6Cross-site request forgery (CSRF)
Um ataque CSRF consiste em fazer um usuário autenticado executar uma ação sensível sem que ele perceba, disparando uma requisição para o seu site a partir de um site de terceiros.
Três mecanismos se combinam para se proteger disso:
- Aceite apenas requisições POST para as ações sensíveis, graças ao atributo Method.
- Os cookies de sessão criados pelo Temma têm o parâmetro SameSite=Lax: eles não são enviados em requisições POST vindas de outro domínio. Uma requisição POST forjada a partir de um site de terceiros chega, portanto, sem sessão, e a ação protegida por autenticação é recusada.
- O atributo Referer permite verificar que a requisição vem realmente de uma página do seu próprio site.
7Server-side request forgery (SSRF)
Um ataque SSRF consiste em levar o servidor a efetuar, ele mesmo, requisições para um alvo controlado pelo atacante (por exemplo, um serviço interno inacessível de fora), manipulando um dado de entrada usado para construir a requisição.
A principal proteção é a validação estrita dos dados de entrada usados para construir requisições no lado do servidor. Sempre que possível, não deixe o usuário fornecer uma URL livre: prefira uma lista branca de valores autorizados (por exemplo, com o tipo enum do DataFilter), a partir dos quais o próprio servidor constrói a URL final.
8Sessões e cookies
As sessões gerenciadas pelo Temma são seguras por padrão:
- Os cookies de sessão são criados com os parâmetros httponly (inacessíveis via JavaScript), secure (em HTTPS) e SameSite=Lax (veja a seção CSRF acima).
- Os identificadores de sessão são gerados por um gerador pseudoaleatório criptograficamente seguro.
- Os dados de sessão são armazenados no lado do servidor (pelo motor de sessões do PHP, ou em uma fonte de dados como Redis ou Memcache); apenas o identificador de sessão transita no cookie.
9A configuração x-security
As diretivas de configuração relacionadas à segurança são agrupadas na configuração estendida x-security do arquivo etc/temma.php.
| Chave | Papel | Usada por |
|---|---|---|
| redirect | URL de redirecionamento padrão em caso de acesso negado | atributos Auth, Method, Referer e Check |
| authRedirect | URL de redirecionamento específica em caso de autenticação negada | atributo Auth |
| authVariable | Nome da variável de template contendo o usuário atual | atributo Auth |
| methodRedirect | URL de redirecionamento específica em caso de método HTTP recusado | atributo Method |
| refererRedirect, refererDomain, refererUrl, refererPath | Redirecionamento e critérios de verificação do referer | atributo Referer |
| auth | Subconfiguração do sistema de autenticação (personalização dos e-mails, das tabelas, etc.) | controlador/plugin Auth e plugin API |
Exemplo:
<?php
return [
'x-security' => [
// redirecionamento padrão em caso de acesso negado
'redirect' => '/',
// redirecionamento para o formulário de login se não autenticado
'authRedirect' => '/auth/login',
]
];