L'articolo completo è stato pubblicato suhttps://stackzero.net/ssrf-introduction/

La contraffazione delle richieste lato server (SSRF) è un tipo di vulnerabilità delle applicazioni Web che consente a un utente malintenzionato di inviare una richiesta predisposta da un'applicazione Web vulnerabile a una destinazione arbitraria. Questo può includere sistemi interni, come un server di database o un file server.

La vulnerabilità si verifica quando l'applicazione Web accetta un input fornito dall'utente non disinfettato e lo utilizza per creare una richiesta.
In questo modo è possibile creare una richiesta dannosa e forzare il server vulnerabile a inviarla.

Ad esempio, immagina un'applicazione web che:

• accetta un URL come input
• visualizza il contenuto della pagina Web associata.

SSRF VS CSRF in poche parole:

Qual è la differenza tra SSRF e CSRF ?

• CSRF: il target è un utente/cliente e deve compiere delle azioni, per diventare una vittima. La vulnerabilità non dipende direttamente da lui, ma dal server che ospita un'applicazione potenzialmente vulnerabile.
• SSRF: un hacker può utilizzare l'applicazione stessa per inviare richieste dannose da un dominio attendibile. In questo caso la vulnerabilità non dipende da fattori esterni ma direttamente dal codice dell'applicazione.
Vuoi scommettere che CSRF non è così difficile come pensi?

In questo breve hands-on, eseguiremo un exploit molto semplice su un server mal codificato. Questa non è una situazione reale, ma può aiutare molto a comprendere la vulnerabilità.

Quello che farò è preparare la nostra Kali Machine in VirtualBox in modo da avere due server in esecuzione:

• La prima è l'applicazione vulnerabile (all'interno della directory principale del progetto).
• Il secondo è un server che mostra il contenuto di una directory segreta ed è visibile solo da localhost (viene eseguito all'interno di una directory segreta).

Se hai dei dubbi puoi trovare tutto il codice nel repository GitHub .

Il server vulnerabile SSRF

Prima di scrivere il codice del server vulnerabile abbiamo bisogno dell'indirizzo IP, quindi digitiamo su un terminale:

ifconfig

Dopo aver preso l'IP possiamo scrivere il codice di un'applicazione vulnerabile.
Ad esempio, se fosse 192.168.1.116 questo sarà il codice relativo per eseguire un server in LAN sulla 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)

Questa applicazione ha un singolo endpoint che accetta un URL come parametro di query e invia una richiesta GET a tale URL utilizzando la libreria delle richieste. La risposta della richiesta viene quindi restituita all'utente.

In questo modo possiamo costringere il server web a mostrarci ciò che può vedere, anche se non ne abbiamo i diritti.

Possiamo eseguire l'applicazione digitando nel nostro terminale:

python vulnerable_application.py

Se non hai installato flask, dovresti farlo con il comando:

pip install flask

La vulnerabilità in questa applicazione è che consente a un utente malintenzionato di creare un URL che punta a un servizio interno, ma vediamo come farlo.

Il servizio interno

Voglio rendere questa introduzione il più semplice possibile, quindi per eseguire un servizio interno userò un modulo interno Python: http.server .
Vogliamo eseguirlo su localhost sulla porta 8888:

1. Apri un terminale o un prompt dei comandi.
2. Passare alla directory "supersecretdir" che contiene il flag.
3. Digita il seguente comando per avviare il server:

python -m http.server 8888

       
                

                    
                    
                
            

• Spostati sulla tua macchina host
• Apri il navigatore
• Prova a connetterti a questo URL:http://192.168.1.116:8000?url=http://localhost:8888

Quindi abbiamo avuto accesso a un server interno a cui normalmente non potevamo accedere!
Come previsto, l'exploit sta funzionando bene!

Conclusione

Abbiamo visto solo una semplice prova di concetto anche se negli scenari del mondo reale la vulnerabilità potrebbe essere più complessa da sfruttare e prevenire. Tuttavia, spero che questo articolo sia stato interessante e abbia fornito valore a coloro che desiderano saperne di più su Server Side Request Forgery (SSRF).

Con la crescente prevalenza di applicazioni Web e infrastrutture cloud, è più importante che mai essere consapevoli delle potenziali vulnerabilità di sicurezza poste dagli attacchi SSRF. Comprendendo le basi di SSRF, il suo impatto e come prevenirlo, possiamo proteggere meglio i nostri sistemi e dati da attori malintenzionati. Ricorda, prevenire è sempre meglio che reagire e adottando misure proattive per proteggere le nostre applicazioni web, possiamo evitare conseguenze potenzialmente disastrose in futuro.

Se hai trovato questo articolo informativo, ti invito a seguire il mio blog per ulteriori approfondimenti sulla sicurezza informatica.
Rimani aggiornato sulle ultime tendenze e tecniche per proteggere i tuoi sistemi da potenziali minacce. Non esitare a lasciare un commento o condividere questo articolo con altri che potrebbero trovarlo utile.
Grazie per aver letto e non vediamo l'ora di vedervi sul blog!

Originariamente pubblicato su https://stackzero.net il 17 febbraio 2023.

Seguimi su medium per ricevere i miei nuovi articoli. E se vuoi iscriverti a Medium, considera di utilizzare il mio link di riferimento, non è un costo aggiuntivo per te ma sarebbe di grande aiuto per me.

Altri articoli che potrebbero piacerti: