O artigo completo foi publicado emhttps://stackzero.net/ssrf-introduction/

A falsificação de solicitação do lado do servidor (SSRF) é um tipo de vulnerabilidade de aplicativo da Web que permite que um invasor envie uma solicitação criada de um aplicativo da Web vulnerável para um destino arbitrário. Isso pode incluir sistemas internos, como um servidor de banco de dados ou um servidor de arquivos.

A vulnerabilidade ocorre quando o aplicativo da web pega uma entrada não sanitizada fornecida pelo usuário e a usa para criar uma solicitação.
Dessa forma, é possível criar uma solicitação maliciosa e forçar o servidor vulnerável a enviá-la.

Por exemplo, imagine um aplicativo da web que:

• recebe uma URL como entrada
• exibe o conteúdo da página da web associada.

SSRF VS CSRF em poucas palavras:

Qual é a diferença entre SSRF e CSRF ?

• CSRF: o alvo é um usuário/cliente e ele tem que realizar algumas ações, para se tornar uma vítima. A vulnerabilidade não depende diretamente dele, mas do servidor que hospeda um aplicativo potencialmente vulnerável.
• SSRF: um hacker pode usar o próprio aplicativo para enviar solicitações maliciosas de um domínio confiável. Nesse caso, a vulnerabilidade não depende de fatores externos, mas diretamente do código do aplicativo.
Quer apostar que o CSRF não é tão difícil quanto você pensa?

Neste breve hands-on, vamos realizar uma exploração muito simples em um servidor mal codificado. Esta não é uma situação real, mas pode ajudar muito a entender a vulnerabilidade.

O que vou fazer é preparar nossa Kali Machine no VirtualBox de forma que tenhamos dois servidores rodando:

• O primeiro é o aplicativo vulnerável (dentro do diretório principal do projeto).
• O segundo é um servidor que mostra o conteúdo de um diretório secreto e só é visível do localhost (roda dentro de um diretório secreto).

Se você tiver dúvidas, pode encontrar o código completo no repositório do GitHub .

O servidor vulnerável a SSRF

Antes de escrever o código do servidor vulnerável precisamos do endereço IP, então vamos digitar em um terminal:

ifconfig

Depois de pegar o IP, podemos escrever o código de um aplicativo vulnerável.
Por exemplo, se for 192.168.1.116, este será o código relacionado para executar um servidor em LAN na porta 8000.

from flask import Flask, request
import requests


app = Flask(__name__)

my_ip = '192.168.1.116'

@app.route("/")
def index():
    url = request.args.get("url")
    response = requests.get(url)
    return response.text


if __name__ == "__main__":
    app.run(host=my_ip, port=8000)

Esse aplicativo tem um único terminal que usa uma URL como parâmetro de consulta e faz uma solicitação GET para essa URL usando a biblioteca de solicitações. A resposta da solicitação é então retornada ao usuário.

Desta forma, podemos forçar o servidor web a nos mostrar o que pode ver, mesmo que não tenhamos os direitos.

Podemos executar o aplicativo digitando em nosso terminal:

python vulnerable_application.py

Caso não tenha o flask instalado, deverá fazê-lo com o comando:

pip install flask

A vulnerabilidade desse aplicativo é que ele permite que um invasor crie uma URL que aponte para um serviço interno, mas vamos ver como fazer isso.

O Serviço Interno

Quero tornar esta introdução o mais simples possível, portanto, para executar um serviço interno, usarei um módulo interno do python: http.server .
Queremos executá-lo em localhost na porta 8888:

1. Abra um terminal ou prompt de comando.
2. Navegue até o diretório “supersecretdir” que contém o sinalizador.
3. Digite o seguinte comando para iniciar o servidor:

python -m http.server 8888

       
                

                    
                    
                
            

• Mover em sua máquina host
• Abra o navegador
• Tente se conectar a este URL:http://192.168.1.116:8000?url=http://localhost:8888

Assim, obtivemos acesso a um servidor interno que normalmente não poderíamos acessar!
Como esperávamos, o exploit está funcionando bem!

Conclusão

Vimos apenas uma simples prova de conceito, embora em cenários do mundo real a vulnerabilidade possa ser mais complexa de explorar e prevenir. No entanto, espero que este artigo tenha sido interessante e tenha fornecido valor para aqueles que desejam aprender mais sobre falsificação de solicitação do lado do servidor (SSRF).

Com a crescente prevalência de aplicativos da Web e infraestrutura em nuvem, é mais importante do que nunca estar ciente das possíveis vulnerabilidades de segurança impostas pelos ataques SSRF. Ao entender os fundamentos do SSRF, seu impacto e como evitá-lo, podemos proteger melhor nossos sistemas e dados de agentes mal-intencionados. Lembre-se, a prevenção é sempre melhor do que a reação e, ao tomar medidas proativas para proteger nossos aplicativos da Web, podemos evitar consequências potencialmente desastrosas no futuro.

Se você achou este artigo informativo, convido você a seguir meu blog para obter mais informações sobre segurança cibernética.
Mantenha-se atualizado sobre as últimas tendências e técnicas para proteger seus sistemas contra ameaças potenciais. Não hesite em deixar um comentário ou compartilhar este artigo com outras pessoas que possam achá-lo útil.
Obrigado por ler e esperamos vê-lo no blog!

Originalmente publicado em https://stackzero.net em 17 de fevereiro de 2023.

Siga-me no medium para receber meus novos artigos. E se você quiser se inscrever no Medium, considere usar meu link de referência, não é um custo adicional para você, mas seria uma grande ajuda para mim.

Outros artigos que você pode gostar: