Em aplicativos da Web, problemas de segurança causados por erros de configuração de segurança são comuns.As configurações de segurança comuns são problemas de segurança de configuração do Apache, problemas de segurança de configuração do Nginx e problemas de segurança de configuração do Tomcat. Aqui descrevemos brevemente os problemas de configuração desses três softwares de servidor.
1. Problemas de configuração de segurança do Apache
O arquivo de configuração do Apache é chamado httpd.conf Antes de iniciarmos nossa própria aplicação web, primeiro precisamos modificar sua configuração.
Se quisermos que o Apache o analise com x-httpd-php quando encontrar um arquivo de página com a extensão PHP, podemos adicionar o código AddHandler application/x-httpd-php .php ao arquivo de configuração
Antes de uma análise aprofundada, precisamos entender um recurso básico do Apache, ou seja, o Apache permite que os arquivos tenham vários sufixos e suporta a execução de diferentes programas de análise para diferentes sufixos. Quando configuramos as opções acima, se nosso sufixo de arquivo contiver o sufixo l.php, o apache chamará o programa de análise do PHP para analisar o arquivo.
Aqui usamos o campo de tiro como exemplo:
Primeiro carregue test.test.php.xyz.jpg, o conteúdo do arquivo é:<?php phpinfo();?>
De acordo com a lógica normal, devemos mostrar o resultado de um de nossos formatos de imagem.
Mas neste momento nós modificamos o conteúdo do arquivo de configuração do apache e adicionamos: AddHandler application/x-httpd-php .php. Em seguida, reinicie o serviço Apache2.
Em seguida, visite o arquivo que enviamos e o conteúdo da resposta obtido é o seguinte:
Aqui você pode ver que o código PHP malicioso que carregamos foi executado. Neste ponto, o aplicativo da web não é mais seguro.
Pode-se ver que, se nosso gerenciador de aplicativos da Web configurar essa opção, nosso invasor poderá usar essa configuração para ignorar o limite de upload e obter shell.
2. Problemas de configuração de segurança do Nginx
Nginx é um servidor web HTTP e proxy reverso de alto desempenho, podemos executá-lo em Unix e Linux. É amplamente utilizado, perdendo apenas para o software de servidor web do apache, e sua taxa de utilização está aumentando ano a ano, e tende a alcançar o apache.
Quando nosso nginx não está configurado corretamente, também causará problemas de segurança.
O código a seguir é um arquivo de configuração para um host virtual do Nginx:
server {
listen 8080;
root /usr/share/nginx/html;
index index.html;
server_name _;
location / {
return 302 https://$host$uri;
}
}
Neste arquivo de configuração do Nginx, a configuração problemática está na última linha, só precisamos prestar atenção nesta parte:
return 302 https://$host$uri;
$host pode ser simplesmente entendido como as informações do host na solicitação original, enquanto $uri é a chave para questões de segurança e representa o caminho de solicitação decodificado na solicitação. Se o invasor definir as informações de URL solicitadas da seguinte maneira:
http://ip:port/%0a%0dSet-Cookie:%20a=test
Nesta URL, %0a é CR após a decodificação, %0d é LF após a decodificação e %20 corresponde a um espaço após a decodificação. Portanto, quando o Nginx decodificar $uri, ele decodificará %0a%0d em CRLF, o que fará com que a mensagem HTTP seja agrupada e, em seguida, iniciará uma solicitação Set-Cookie, que é o efeito da injeção de CRLF.
Vamos fazer um teste, acesse 127.0.0.1:8080/%0a%0dSet-Cookie:%20a=test, e veja que salta para https, mas o conteúdo do nosso Set-cookie é encontrado na resposta, indicando nossa CRLF Injection foi um sucesso.
3. Problemas de configuração de segurança do Tomcat
O servidor Tomcat é um servidor de aplicativos da Web gratuito e de código aberto, que é um servidor de aplicativos leve e é comumente usado em sistemas de pequeno e médio porte e em ocasiões em que não há muitos usuários de acesso simultâneo. Na verdade, o Tomcat é uma extensão do servidor Apache, mas é executado de forma independente no tempo de execução; portanto, quando você executa o Tomcat, ele é executado como um processo separado do Apache.
Há um problema de configuração de segurança bem conhecido no Tomcat, que é CVE-2017-12615. O problema específico é que, quando o Tomcat está sendo executado em um host do Windows e DefaultServlet readonly é definido como false no arquivo de configuração conf/web.xml, então, se ele ativar o método de solicitação HTTP PUT, levará à segurança da gravação arbitrária do arquivo ocorre o problema. Isso é um pouco semelhante à vulnerabilidade de upload IIS PUT.
Aqui chegamos ao teste real, ligue nossa máquina de destino, a exibição é Tomcat 8.5.19:
Em seguida, usamos a ferramenta de verificação de vulnerabilidade para realizar uma verificação de vulnerabilidade:
Os resultados da verificação mostram que nossa máquina de destino tem várias vulnerabilidades de segurança e nossa vulnerabilidade Tomcat PUT também é verificada e, em seguida, usamos a ferramenta de exploração de vulnerabilidade Tomcat PUT para explorar a vulnerabilidade:
Pode-se ver que a exploração foi bem-sucedida e os privilégios de administrador foram obtidos.
4. Princípios de configuração de segurança
Para evitar erros de configuração de segurança, precisamos seguir vários princípios ao configurar aplicativos da web:
- Princípio de serviço mínimo
我们需要将 Web 应用不需要的服务进行关闭或限制，防止攻击者通过这些服务发起恶意行为
- Configurações de relatórios de erros generalizados
将 Web 应用的报错信息设置得通用化，使得报错信息中不包含错误发生的细节信息，防止因此导致的敏感信息泄露
- Modificar informações de conta padrão
将 Web 应用默认的账户信息进行修改，尽量让账户密码变得复杂，否则攻击者很容易就会猜出账户信息，登陆进 Web 应用的管理后台