Contatta il reparto vendite solo da fisso 800 13.40.41 | Richiedi il Supporto Partner

Articoli

Icona delle News




Che cos'è la falsificazione delle richieste lato server (SSRF)?

la falsificazione delle richieste lato server (SSRF)

18/11/21 CoreTech Blog

Le vulnerabilità SSRF (Server-side Request Forgery) consentono a un utente malintenzionato di inviare richieste predisposte dal server back-end di un'applicazione Web vulnerabile. I criminali di solito utilizzano attacchi SSRF per colpire i sistemi interni che si trovano dietro i firewall e non sono accessibili dalla rete esterna. Un utente malintenzionato può anche sfruttare SSRF per accedere ai servizi disponibili tramite l'interfaccia di loopback (127.0.0.1) del server sfruttato.

Le vulnerabilità SSRF si verificano quando un utente malintenzionato ha il controllo completo o parziale della richiesta inviata dall'applicazione web. Un esempio comune è quando un utente malintenzionato può controllare l'URL del servizio di terze parti a cui l'applicazione Web effettua una richiesta.

Mitigare la falsificazione delle richieste lato server

Semplici blacklist ed espressioni regolari applicate all'input dell'utente sono un cattivo approccio per mitigare SSRF. In generale, le liste nere sono uno scarso mezzo di controllo della sicurezza. Gli aggressori troveranno sempre metodi per aggirarli. In questo caso, un utente malintenzionato può utilizzare un reindirizzamento HTTP, un servizio DNS con caratteri jolly come xip.io o anche una codifica IP alternativa .

Whitelist e risoluzione DNS

Il modo più efficace per evitare la falsificazione delle richieste lato server (SSRF) è inserire nella whitelist il nome DNS o l'indirizzo IP a cui l'applicazione deve accedere. Se un approccio alla whitelist non ti soddisfa e devi fare affidamento su una blacklist, è importante convalidare correttamente l'input dell'utente. Ad esempio, non consentire richieste a indirizzi IP privati ​​(non instradabili) (dettagliato in RFC 1918 ).

Tuttavia, nel caso di una lista nera, la corretta mitigazione da adottare varierà da un'applicazione all'altra. In altre parole, non esiste una correzione universale per SSRF perché dipende fortemente dalla funzionalità dell'applicazione e dai requisiti aziendali.

Banner

Gestione della risposta

Per evitare che i dati di risposta vengano divulgati all'autore dell'attacco, è necessario assicurarsi che la risposta ricevuta sia quella prevista. In nessun caso il corpo della risposta non elaborato dalla richiesta inviata dal server deve essere consegnato al client.

Disabilita gli schemi URL inutilizzati

Se la tua applicazione utilizza solo HTTP o HTTPS per effettuare richieste, consenti solo questi schemi URL. Se disabiliti gli schemi URL inutilizzati, l'autore dell'attacco non sarà in grado di utilizzare l'applicazione Web per effettuare richieste utilizzando schemi potenzialmente pericolosi come file:/// , dict:// , ftp:// e gopher:// .

Autenticazione sui servizi interni

Per impostazione predefinita, servizi come Memcached, Redis, Elasticsearch e MongoDB non richiedono l'autenticazione. Un utente malintenzionato può utilizzare le vulnerabilità di falsificazione delle richieste lato server per accedere ad alcuni di questi servizi senza alcuna autenticazione. Pertanto, per garantire la sicurezza delle applicazioni web, è meglio abilitare l'autenticazione laddove possibile, anche per i servizi sulla rete locale.


Articoli su Sicurezza

Nozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft