Postado por: Andrey Pinchuk | Desenvolvedor Sênior Certificado AEM
Imagine a situação: você dorme em paz e vê seu terceiro sonho, quando de repente um telefone toca - um cliente insatisfeito reclama que todo o sistema está indisponível. Concordo que esses eventos causam desconforto durante a vida do desenvolvedor do AEM, de toda a equipe e do fornecedor da solução. Não há nada a ser feito, um aumento precoce e a busca de uma solução pela frente.
Para impedir que momentos tão desagradáveis ocorram na sua vida profissional, falarei sobre problemas típicos de segurança e como garantir melhor os problemas.
Vou aderir a esse plano:
- Segurança no nível do Autor;
- Publicar nível de segurança;
- Segurança do Despachante
- Proteção da estrutura CSRF;
- Ataques DDoS.
Dicas básicas de segurança do Adobe Experience Manager
O mundo dos projetos AEM se tornará ainda melhor se cada desenvolvedor tiver um entendimento comum de como toda a plataforma pode ser protegida contra vazamento de dados. De acordo com o diagrama abaixo, temos um autor, vários editores e dois ou mais despachantes (os chamados balanceadores). De fato, vale a pena prestar atenção nesses três níveis em primeiro lugar em termos de proteção de dados. Estas são as regras clássicas de trabalho que geralmente são aceitas na comunidade AEM em todo o mundo.
1. Use HTTPS . O AEM está evoluindo rapidamente, oferecendo a flexibilidade de criar um autor em outro protocolo mais seguro. Basta gerar a chave “SSL Wizard”, criar um caminho para ela e, assim, usar um protocolo mais seguro. Nas recomendações da Adobe - esta etapa é precisamente a primeira prioridade em segurança.
2. Instale os pacotes com as atualizações mais recentes. O processo padrão do desenvolvedor se resume ao fato de que, ao trabalhar com componentes e serviços, você precisa procurar soluções no Google. O objetivo desta etapa é monitorar regularmente o Service Pack e as Hot Fixes. Muitos problemas desaparecem, incluindo os relacionados à segurança dos dados. Embora isso não seja uma panacéia, o ponto importante é manter o sistema atualizado.
3. Criando páginas organizadas com mensagens de erro. Se você inicialmente criar uma página com uma breve descrição do erro, o cliente verá imediatamente que não está funcionando, enquanto o desenvolvedor já estará no processo de solução do problema. É lógico que essas informações não passem por você, mas você evitará o pânico do cliente e dos testadores, confusão nas tarefas.
4. Recuse definir uma senha e faça login em “admin-admin”. Não seria engraçado, mas o problema com login e senha de baixa qualidade é bastante comum, mesmo no AEM. Como resultado, em busca de velocidade ou outras considerações, obtemos o sistema mais vulnerável. Depois de descobrir que os detalhes do login primitivo estão definidos, tente convencer a equipe / superiores e alterá-los para mais confiáveis o mais rápido possível.
Segurança no nível do autor
Primeiro, use vpn . O uso da rede virtual protegida é o trabalho de uma rede privada segura para estabelecer uma conexão segura entre você e o servidor. Essa é uma ferramenta simples e importante: como seu tráfego será criptografado, é impossível descobrir de onde você está enviando seus dados. Acontece que, com o vPn, ninguém poderá acessar sua instância.
Essa abordagem é adequada para desenvolvedores remotos e para todos aqueles cujo trabalho é realizado em diferentes locais com uma conexão à Internet instável.
Em segundo lugar, seu "autor" deve sempre estar fechado, inclusive do Google . Assim, você pode pegar uma senha e invadir o sistema: por negligência, o autor pode ser indexado. Para verificar sua vulnerabilidade em um mecanismo de pesquisa, digite na linha seu domínio e autor e o caminho para o crx. Sim, você pode entrar em contato com o Yandex ou o Google com uma solicitação para excluir essa linha no SERP. Mas, enquanto o problema estiver sendo resolvido, o sistema já estará disponível ao público.
Terceiro, não subestime os privilégios do usuário "admin" , que geralmente tem a capacidade de executar quaisquer operações disponíveis.
Isso é especialmente crítico no momento em que um funcionário se despede da empresa. De fato, para a maioria das empresas, o acesso à instância não é pessoal, mas através de uma conta de administrador. É mais lógico fazer o oposto e estar ciente de alterações específicas no sistema de um autor específico.
O AEM 6.1 introduziu uma nova abordagem na qual você pode definir direitos específicos para um pacote ou serviço de usuário. Mas é melhor criar um perfil pessoal: é agradável para o funcionário e é mais fácil para a empresa rastrear quem tem quais níveis de acesso ao sistema. Essa abordagem é relevante para os níveis de autor e editor.
Publicar segurança
Como regra, somente após muito tempo no projeto, eles percebem que não verificaram o usuário anônimo. E enquanto um usuário comum pode ter restrições às operações, um usuário anônimo - geralmente acontece, tem muito mais direitos para executar operações.
O filtro Apache Sling Referrer é um mecanismo conveniente e eficaz para tornar seu aplicativo seguro. Por exemplo, envie métricas para o AEM, você verá informações sobre o envio de dados na Caixa de entrada. Se você exceder o valor padrão, um sistema de terceiros poderá enviar esta solicitação. Isso significa que ninguém poderá enviar uma solicitação. Você insere o domínio na configuração; no momento da solicitação, ele o compara com os dados inseridos originalmente e, se tudo corresponder, a integração ocorrerá.
Isso resultará em uma configuração mais flexível com o filtro: você pode especificar a solicitação, método, host. Também há um valor vazio ou um asterisco para consultas mais detalhadas.
Segurança no nível do expedidor
Os desenvolvedores enfrentam disputa em 10% dos casos. Portanto, este é o principal arquivo de configuração, onde definimos o tipo de URL (proibir / permitir).
Geralmente, os desenvolvedores realizam uma pequena tarefa, criam uma regra e esquecem que isso adicionará vulnerabilidade. Para que ninguém tente atacar sua instância, é necessário verificar o URL com seletores no momento da disponibilidade.
Através do arquivo de configuração, você pode especificar o processamento de cabeçalhos. Como, com mais precisão, você especifica o zag, o método etc., uma configuração tão detalhada definitivamente não quebra nada. Estes são exemplos elementares. E se houver centenas dessas regras e navegá-las for mais difícil?
A maneira mais fácil é habilitar o log. Dependendo da versão do Apache, o mecanismo de trabalho pode ser ligeiramente alterado. Mas o sistema destacará imediatamente para você qual URL que regra específica está funcionando e o que ainda precisa ser corrigido.
Você também pode especificar domínios nas regras: esta é uma referência à integração.
Depois que o expedidor é usado para armazenar em cache, as solicitações são executadas muitas vezes mais rapidamente: você não precisa ir a lugar nenhum e verificar e pode entregá-lo imediatamente ao cliente. Além disso, esse método melhora muito a segurança do seu aplicativo.
Falsificação de solicitação entre sites - solicitação falsa.
Princípio geral do CSRF: suponha que você use sua conta no site do banco. Após a autorização, você tem uma sessão padrão com cookies no navegador, recebe um email e segue o link para um site suspeito. Nele, um invasor incorporou um formulário, após o término do qual seus dados são enviados para o site do banco.
O ponto está no protocolo HTTP. Um invasor não precisa de muitos dados: essa solicitação é suficiente. O servidor do banco verá: uma solicitação chegou, há cookies e uma sessão, está tudo bem. É assim que os ataques típicos funcionam.
O que o AEM pode oferecer para impedir a falsificação de consultas
Um exemplo clássico de proteção é a geração de um "segredo" em uma string. Quando o formulário é gerado, esse token secreto é adicionado a partir do campo oculto. Se você for ao site do invasor, o sistema detectará a ausência de um token ou sua invalidade e se recusará a enviar dados. Às vezes, eles protegem dos próprios usuários.
Agora você tem um ajack regular, no qual não é possível adicionar um campo oculto. No estágio de autorização, o servidor retorna um cookie com um nome com SCRF para você, transfira-o para o cabeçalho e envie-o para o servidor. Então você assinou a solicitação.
O AEM fará tudo por você: gerará chaves, tokens, verificará o envio do formulário
Há casos em que um aplicativo é escrito em React e há um momento difícil com a integração. O AEM levou essa situação em consideração: basta ir ao inpoint e assinar para verificação. Adequado ao usar componentes e bibliotecas não padrão.
O que mais pode ser feito para proteger o sistema:
- Bibliotecas que são responsáveis por isso. Não faz sentido adicionar até você quebrar alguma coisa.
- No nível baixo, você pode ver todos os "segredos". Este é um tipo de validação dos seus dados.
- É simples: existe uma API pronta e você já está protegido contra esse tipo de ataque.
Ataque DDOS - o segundo ataque mais popular
O objetivo é esgotar os recursos físicos do servidor. Milhões de pedidos estão sendo feitos em algum host. Quando eles se tornam infinitamente numerosos, o sistema começa a não lidar fisicamente. Como regra, eles atacam poderosamente de várias fontes e usam uma VPN. 100% disso não é seguro; mas não vamos ajudá-los.
Em quais casos o sistema é vulnerável:
- Configure o sistema com o sufixo errado;
- Existem muitos pedidos de avs, o expedidor em público não pode encaminhá-los;
- Quando não é proibido exibir um número ilimitado de nós de conteúdo. Em particular, o renderizador JSON, que pode atravessar a estrutura da árvore em vários níveis.
- localhost : 4502 / .json pode despejar o repositório inteiro no formato JSON.
Para tornar seu trabalho no AEM mais seguro, concentre-se nos recursos de usuários específicos.
Não se esqueça de passar pela Lista de verificação de segurança da Adobe e deixar tudo estável com seu projeto no AEM.