logo naturale cybe cybersicurezza modena

Server Side Request Forgery (SSRF)

visual Server Side Request Forgery OWASP 10 cybe

Owasp Capitolo 10: come difendersi dalle tecniche di exploiting, i consigli di Cybe

Alla posizione numero 10 della nostra Top 10 troviamo la cosiddetta Server Side Request Forgery. Nuovissima entry rispetto alla scorsa classifica del 2017, negli ultimi anni è aumentato nettamente l’uso di tale tecnica di exploiting.

Ma che cos’è l’SSRF e quali sono i danni/impatti che essa può portare alla nostra web app?
Una falla di tipo SSRF avviene quando una web app, richiede una risorsa remota senza verificare e validare l’URL fornito dall’utente. Essa permette dunque ad un attaccante di costringere l’applicazione ad inviare una richiesta creata appositamente, ad una destinazione inaspettata, anche se protetta da un firewall o una VPN o una qualsiasi tipo di ACL (access control list).
Con l’incremento di servizi e funzioni che le web app mettono a disposizione, è aumentato fortemente l’utilizzo di tale falla, e anche la gravità e gli impatti di attacchi che sfruttano l’SSRF sono aumentati notevolmente all’aumentare dei servizi cloud e della complessità delle architetture.

Come difendersi da tale falla?

Abbiamo diversi approcci per tutelarci. I due principali riguardano il layer di rete e il layer applicativo.
A livello di rete dobbiamo assicurarci che la risorse remote siano segmentate nel modo giusto, in reti differenti, per ridurre l’impatto della SSRF.
A livello di firewall bisogna imporre delle policies di tipo deny all (nega tutto) o delle ACL molto stringenti per bloccare tutto il traffico non essenziale.
Nel pratico alcuni consigli utili sono sicuramente di stabilire la proprietà e un ciclo vita delle regole per i firewall, basate sugli scopi e funzionalità dell’applicativo, e raccogliere le informazioni di sistema (log) di tutte le attività bloccate e accettate sul firewall stesso.

Da un punto di vista applicativo invece i principali metodi di mitigazione sono:

  • Implementare la validazione e sanitizzazione dell’input del client/utente
  • Imporre lo schema URL, porta e destinazione con una ACL permissiva
  • Non inviare risposte grezze ai client
  • Disabilitare i redirect http
  • Tenere a mente la consistenza degli URL per evitare attacchi come il rebinding DNS e le race conditions time of check, time of use

Seguite la  nostra pagina LinkedIn per scoprire i prossimi capitoli.

Altri Articoli

Sei sotto attacco?
Possiamo aiutarti, adesso.