Questa pagina spiega come interpretare, riprodurre e correggere i risultati di Web Security Scanner.
I ruoli IAM per Security Command Center possono essere concessi a livello di organizzazione, cartella o progetto. La possibilità di visualizzare, modificare, creare o aggiornare risultati, asset e origini di sicurezza dipende dal livello per cui ti è stato concesso l'accesso. Per scoprire di più sui ruoli di Security Command Center, consulta Controllo degli accessi.
Classi di vulnerabilità
Web Security Scanner rileva le seguenti classi di vulnerabilità:
- Cross-site scripting (XSS)
- Falsificazione delle richieste lato server
- Flash injection
- Contenuto misto
- Librerie obsolete o vulnerabili
- Password in chiaro
- Convalida dell'origine non sicura
- Intestazioni non valide
- Intestazioni con errori ortografici
- Repository accessibili
- SQL injection
- Iniezione di XML
- Prototype pollution
Se viene rilevata una qualsiasi di queste vulnerabilità, il risultato viene evidenziato per consentirti di esaminarlo nel dettaglio.
Impatto sui log
Nei file di log vengono visualizzate tracce delle scansioni di Web Security Scanner. Ad esempio,
Web Security Scanner genera richieste per stringhe insolite come ~sfi9876
e /sfi9876
. Questo processo consente alla scansione di esaminare le pagine di errore della tua applicazione. Queste richieste di pagine intenzionalmente non valide vengono visualizzate nei log.
Disattivazione dei risultati dopo la correzione
Dopo aver corretto una vulnerabilità,
Web Security Scanner non imposta automaticamente lo stato del
risultato di Security Command Center corrispondente su INACTIVE
.
A meno che non modifichi lo stato manualmente, lo stato dei risultati generati da Web Security Scanner in Security Command Center rimane ACTIVE
.
Se utilizzi la versione autonoma di Web Security Scanner, dopo aver corretto una vulnerabilità e Web Security Scanner non può più rilevarla, i report sulle vulnerabilità successivi non la includono. Un record della vulnerabilità rimane nei report sulle vulnerabilità passati.
Web Security Scanner esegue scansioni gestite settimanalmente.
Per saperne di più sulle analisi di Web Security Scanner, consulta Tipi di analisi.
Correzione dei risultati di Web Security Scanner
Questa sezione spiega come correggere i diversi tipi di risultati di Web Security Scanner. Per le strategie di difesa contro gli attacchi comuni a livello di applicazione descritti nel report OWASP Top 10, consulta le opzioni di mitigazione delle prime 10 minacce OWASP su Google Cloud.
XSS
Nome della categoria nell'API: XSS
Il test di injection di Cross-site scripting (XSS) di Web Security Scanner simula un attacco inserendo una stringa di test innocua in campi modificabili dall'utente ed eseguendo una serie di azioni utente. I rilevatori personalizzati osservano browser e DOM durante il test per determinare se un'injection è riuscita e valutarne il potenziale di sfruttamento.
Se la stringa JavaScript contenuta nel test viene eseguita correttamente, viene avviato il debugger di Chrome. Quando una stringa di test può essere eseguita, è possibile inserire e eseguire JavaScript nella pagina. Se un malintenzionato trovasse questo problema, potrebbe eseguire JavaScript di sua scelta come utente (vittima) che fa clic su un link dannoso.
In alcuni casi, l'applicazione in test potrebbe modificare la stringa di test prima che venga analizzata dal browser. Ad esempio, l'applicazione potrebbe convalidare l'input o limitare le dimensioni di un campo. Quando il browser tenta di eseguire questa stringa di test modificata, è probabile che si blocchi e generi un errore di esecuzione di JavaScript. L'errore indica un problema di attacco di tipo injection, ma potrebbe non essere possibile sfruttarlo.
Per risolvere il problema, devi verificare se si tratta di una vulnerabilità XSS verificando manualmente se le modifiche alla stringa di test possono essere eluse. Per informazioni dettagliate su come verificare questa vulnerabilità, consulta Cross-site scripting.
Esistono diversi modi per risolvere questo problema. La correzione consigliata consiste nell'applicare l'escape a tutto l'output e utilizzare un sistema di modelli che supporti l'applicazione automatica contestuale dell'escape.
XSS angular callback
Nome della categoria nell'API: XSS_ANGULAR_CALLBACK
Una vulnerabilità di cross-site scripting (XSS) nei moduli AngularJS può verificarsi quando Angular interpola una stringa fornita dall'utente. L'injection di valori forniti dall'utente in un'interpolazione AngularJS può consentire i seguenti attacchi:
- Un malintenzionato può inserire codice arbitrario nella pagina visualizzata dai browser.
- Un malintenzionato può eseguire azioni per conto del browser della vittima nell'origine della pagina.
Per riprodurre questa potenziale vulnerabilità, segui il link all'URL di riproduzione nella console Google Cloud dopo aver eseguito la scansione. Questo link apre direttamente una finestra di avviso o inserisce la stringa XSSDETECTED
per dimostrare che l'attacco è in grado di eseguire codice. Se la stringa viene iniettata, puoi aprire gli strumenti per sviluppatori del browser e cercare XSSDETECTED
per trovare la posizione esatta dell'injection.
XSS error
Nome della categoria nell'API: XSS_ERROR
Un rilevamento XSS_ERROR
indica un potenziale bug XSS a causa di un'interruzione di JavaScript. In alcune circostanze, l'applicazione in test potrebbe modificare la stringa di test prima che il browser la analizzi. Quando il browser tenta di eseguire questa stringa di test modificata, è probabile che si blocchi e generi un errore di esecuzione di JavaScript. Questo errore indica un problema di inserimento, ma potrebbe non essere possibile sfruttarlo.
Per risolvere il problema, devi verificare se si tratta di una vulnerabilità XSS verificando manualmente se le modifiche alla stringa di test possono essere eluse. Per informazioni dettagliate su come verificare questa vulnerabilità, consulta Cross-site scripting.
Server side request forgery
Nome della categoria nell'API: SERVER_SIDE_REQUEST_FORGERY
Una vulnerabilità SERVER_SIDE_REQUEST_FORGERY
consente a un utente di un'applicazione web di ottenere accesso ai dati interni costringendo un server a effettuare una richiesta (ad esempio una richiesta HTTP) a un endpoint di servizio con restrizioni. Ad esempio, un malintenzionato può sfruttare questa vulnerabilità per recuperare i dati dal servizio di metadati di Google Cloud.
Per risolvere il problema, utilizza una lista consentita per limitare i domini e gli indirizzi IP a cui l'applicazione web può inviare richieste.
Rosetta flash
Nome della categoria nell'API: ROSETTA_FLASH
Web Security Scanner potrebbe rilevare che il valore di un parametro di richiesta viene riportato all'inizio di una risposta, ad esempio nelle richieste che utilizzano JSONP. Questa vulnerabilità è nota anche come attacco di tipo flash injection. In determinate circostanze, un malintenzionato può fare in modo che il browser esegua la risposta come se fosse un file Flash fornito dall'applicazione web vulnerabile.
Per risolvere il problema, non includere dati controllabili dall'utente all'inizio di una risposta HTTP.
Mixed content
Nome della categoria nell'API: MIXED_CONTENT
Web Security Scanner osserva passivamente il traffico HTTP e rileva quando viene eseguita una richiesta di un file JavaScript o CSS tramite HTTP nel contesto di una pagina HTTPS. In questo scenario, un utente malintenzionato man in the middle potrebbe alterare la risorsa HTTP e ottenere l'accesso completo al sito web che carica la risorsa o monitorare le azioni intraprese dagli utenti.
Per risolvere il problema, utilizza link HTTP relativi, ad esempio, sostituisci http://
con
//
.
Outdated library
Nome della categoria nell'API: OUTDATED_LIBRARY
Web Security Scanner potrebbe rilevare che la versione di una libreria inclusa è nota per avere un problema di sicurezza. Web Security Scanner è uno scanner basato su firme che tenta di identificare la versione della libreria in uso e la controlla a fronte di un elenco noto di librerie vulnerabili. Sono possibili falsi positivi se il rilevamento della versione non riesce o se alla libreria sono state applicate patch manualmente.
Per risolvere il problema, esegui l'aggiornamento a una versione sicura della libreria inclusa.
Struts insecure deserialization
Nome della categoria nell'API: STRUTS_INSECURE_DESERIALIZATION
Web Security Scanner potrebbe rilevare che la tua applicazione web utilizza una versione di Apache Struts vulnerabile agli attacchi di inserimento di comandi remoti. Le versioni di Struts interessate possono analizzare in modo errato l'intestazione HTTP Content-Type non valida di un utente malintenzionato. Questa vulnerabilità consente di eseguire i comandi dannosi con i privilegi del server web.
Di seguito sono riportate le versioni di Apache Struts vulnerabili:
- Versioni 2.3.x precedenti alla 2.3.32
- Versioni 2.5.x precedenti alla 2.5.10.1
Per risolvere il problema, esegui l'upgrade di Apache Struts alla versione più recente.
Per ulteriori informazioni sulla vulnerabilità di Apache Struts, consulta CVE-2017-5638.
Cacheable password input
Nome della categoria nell'API: CACHEABLE_PASSWORD_INPUT
Web Security Scanner potrebbe rilevare che, per l'inserimento di una password, l'applicazione web utilizza un elemento <input>
per il quale l'attributo type
non è impostato su password
.
Ciò può portare i browser a memorizzare nella cache la password inserita dall'utente nella normale cache del browser, anziché in uno spazio di archiviazione sicuro delle password.
Per risolvere il problema, nell'elemento <input>
aggiungi l'attributo type
e impostalo su password
, ad esempio <input type="password">
.
Questo attributo oscura i caratteri inseriti dall'utente nel campo della password.
Clear text password
Nome della categoria nell'API: CLEAR_TEXT_PASSWORD
Web Security Scanner potrebbe rilevare che l'applicazione sembra trasmettere un campo password in chiaro. Un malintenzionato può intercettare il traffico di rete e sniffare il campo della password.
Per proteggere le informazioni sensibili trasmesse tra client e server, prendi sempre le seguenti precauzioni:
- Utilizza certificati TLS/SSL.
- Utilizza sempre HTTPS per le pagine che includono campi per la password.
- Assicurati che gli attributi di azione modulo puntino sempre a un URL HTTPS.
Insecure allow origin ends with validation
Nome della categoria nell'API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION
Web Security Scanner potrebbe rilevare che un endpoint HTTP o HTTPS tra siti convalida solo un suffisso dell'intestazione della richiesta Origin
prima di rifletterlo all'interno dell'intestazione della risposta Access-Control-Allow-Origin
. Se la convalida è configurata in modo errato, l'endpoint potrebbe concedere l'accesso a un dominio dannoso che ha lo stesso suffisso di un dominio incluso nella lista consentita. Ad esempio, se il validatore dell'endpoint corrisponde a domini come *google.com
, potrebbe concedere erroneamente l'accesso a maliciousdomaingoogle.com
.
Per risolvere il problema, verifica che il dominio principale previsto faccia parte del valore dell'intestazione Origin
prima di rifletterlo nell'intestazione della risposta Access-Control-Allow-Origin
. Per i caratteri jolly nel sottodominio, anteponi il punto al dominio principale, ad esempio .endsWith(".google.com")
.
Insecure allow origin starts with validation
Nome della categoria nell'API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION
Web Security Scanner potrebbe rilevare che un endpoint HTTP o HTTPS tra siti convalida solo un prefisso dell'intestazione della richiesta Origin
prima di rifletterlo all'interno dell'intestazione della risposta Access-Control-Allow-Origin
. Se la convalida è configurata in modo errato, l'endpoint potrebbe concedere l'accesso a un dominio dannoso che ha lo stesso prefisso di un dominio incluso nella lista consentita. Ad esempio, se il validatore dell'endpoint controlla solo se il dominio richiedente contiene google.com
, potrebbe erroneamente concedere l'accesso a google.com.maliciousdomain.com
.
Per correggere questo rilevamento, verifica che il dominio previsto corrisponda completamente al valore dell'intestazione Origin
prima di rifletterlo nell'intestazione della risposta Access-Control-Allow-Origin
, ad esempio .equals(".google.com")
.
Session ID leak
Nome della categoria nell'API: SESSION_ID_LEAK
Web Security Scanner potrebbe trovare un identificatore di sessione nell'Referer
header della richiesta delle richieste cross-domain della tua applicazione web.
I domini che ricevono il token Referer
possono utilizzare l'identificatore di sessione per rubare l'identità di un utente (utilizzando il relativo token) o identificarlo in modo univoco.
Per correggere questo rilevamento, memorizza gli identificatori di sessione nei cookie anziché nell'URL. Inoltre, metti al sicuro i cookie utilizzando i seguenti attributi:
- HTTPOnly: un attributo che rende i cookie inaccessibili agli script lato client
- Secure: un attributo che rende i cookie trasmissibili solo tramite HTTPS
Invalid content type
Nome della categoria nell'API: INVALID_CONTENT_TYPE
Web Security Scanner potrebbe rilevare risorse caricate che non corrispondono all'intestazione HTTP Content-Type della risposta. In questo scenario, l'applicazione restituisce contenuti sensibili con un tipo di contenuti non valido o senza un'intestazione X-Content-Type-Options: nosniff
.
Per risolvere il problema, assicurati di quanto segue:
- Le risposte JSON vengano fornite con l'intestazione Content-Type
application/json
- Altre risposte sensibili vengano fornite con i tipi MIME appropriati
- I contenuti vengano forniti con l'intestazione HTTP
X-Content-Type-Options: nosniff
Invalid header
Nome della categoria nell'API: INVALID_HEADER
Web Security Scanner potrebbe rilevare che un'intestazione di sicurezza contiene un errore di sintassi, in modo da generare un'intestazione con valore non valido o con formato non corretto. Di conseguenza, il browser ignora queste intestazioni.
Le intestazioni valide sono descritte nelle sezioni seguenti.
Intestazione Referrer-Policy
Un'intestazione referrer-policy valida contiene uno dei seguenti valori:
- Una stringa vuota
no-referrer
no-referrer-when-downgrade
same-origin
origin
strict-origin
origin-when-cross-origin
strict-origin-when-cross-origin
unsafe-url
Intestazione X-Frame-Options
Un'intestazione X-Frame-Options valida può avere solo i seguenti valori:
DENY
: non consentire alcun inquadramentoSAMEORIGIN
: consenti il framing se l'URL di primo livello è della stessa origineALLOW-FROM URL
Chrome non supporta ALLOW-FROM URL
. Non sono consentite intestazioni X-Frame-Options multiple.
Intestazione X-Content-Type-Options
Un'intestazione X-Content-Type-Options valida può avere un solo valore: nosniff
.
Intestazione X-XSS-Protection
Un'intestazione X-XSS-Protection valida deve iniziare con 0
("disattivata") o
1
("attivata"). Solo se attivi la protezione, puoi aggiungere fino a due opzioni:
mode=block
mostra una pagina vuota anziché filtrare gli XSSreport=URL
invia report aURL
Separa le opzioni con punti e virgola, ad esempio 1; mode=block; report=URI
. Assicurati di non avere una virgola semicircolare finale.
Misspelled security header name
Nome della categoria nell'API: MISSPELLED_SECURITY_HEADER_NAME
Web Security Scanner potrebbe trovare un errore ortografico nell'intestazione di sicurezza. Se errata, l'intestazione di sicurezza è inefficace e deve essere corretta.
Per riprodurre questa vulnerabilità, controlla la presenza di errori ortografici nella scheda Rete degli strumenti per sviluppatori del browser.
Mismatching security header values
Nome della categoria nell'API: MISMATCHING_SECURITY_HEADER_VALUES
Web Security Scanner potrebbe rilevare che la risposta contiene intestazioni di risposta relative alla sicurezza duplicate con valori in conflitto. Alcune intestazioni HTTP relative alla sicurezza si comportano in modo indefinito se vengono dichiarate due volte in una risposta con valori non corrispondenti.
Per risolvere il problema, mantieni solo una di queste intestazioni non corrispondenti.
Repository accessibile
Web Security Scanner potrebbe trovare un repository GIT o SVN accessibile nell'applicazione. Questa condizione può causare perdite di configurazione e del codice sorgente.
Per riprodurre la vulnerabilità, fai clic sull'URL di riproduzione nel rapporto dei risultati.
XXE reflected file leakage
Nome della categoria nell'API: XXE_REFLECTED_FILE_LEAKAGE
Web Security Scanner potrebbe trovare una vulnerabilità di tipo XXE (XML eXternal Entity) in un'applicazione web che analizza il codice XML dagli input utente. Un malintenzionato può fornire un XML contenente un'entità esterna. Questa entità esterna può fare riferimento ai contenuti a cui l'applicazione ha accesso, ad esempio i file sulla macchina host dell'applicazione. Quando l'analizzatore XML dell'applicazione elabora il codice XML dannoso, può divulgare i contenuti dei file sul suo host.
Per correggere questo rilevamento, configura i tuoi analizzatori XML in modo che non consentano entità esterne.
Per ulteriori informazioni su questa vulnerabilità, consulta Elaborazione di entità esterne XML (XXE).
SQL injection
Nome della categoria nell'API: SQL_INJECTION
Web Security Scanner potrebbe trovare una vulnerabilità di SQL injection. Gli utenti malintenzionati possono creare input che manipolano la struttura della query della query SQL sottostante in esecuzione sul server. Questi input consentono di esfiltrare i dati dal database e, in alcuni casi, di modificarli. Per risolvere questo problema, utilizza query parametrizzate per impedire input utente'utente di influenzare la struttura della query SQL.
Per ulteriori informazioni su questa vulnerabilità, consulta SQL Injection.
Prototype pollution
Nome della categoria nell'API: PROTOTYPE_POLLUTION
Web Security Scanner potrebbe trovare una vulnerabilità di tipo "prototype pollution" in un'applicazione web a cui sono assegnati valori controllabili dall'utente malintenzionato alle proprietà degli oggetti. Gli utenti malintenzionati possono creare input che rendono l'applicazione vulnerabile a cross-site scripting o ad altre vulnerabilità lato client.
Per correggere questo rilevamento, elimina la proprietà proto
deprecata e rendi immutabile l'oggetto Object.prototype
.
Se questa mitigazione è incompatibile con il tuo codice, modifica la parte di codice vulnerabile in modo da copiare solo i valori previsti dagli input controllabili da utenti malintenzionati.
Verificare il problema
Quando Web Security Scanner segnala un problema, devi verificarne la posizione. Questa sezione spiega come utilizzare i report sui risultati per riprodurre e verificare le vulnerabilità.
Vai alla pagina di Web Security Scanner nella console Google Cloud.
Seleziona un progetto. Viene visualizzata una pagina con un elenco delle analisi gestite e personalizzate.
In Configurazioni di scansione, seleziona la scansione che contiene il rilevamento che vuoi verificare. Viene visualizzata una pagina con i dettagli della scansione.
Vai alla scheda Risultati, espandi una categoria e seleziona un risultato per visualizzarne i dettagli.
Il metodo di verifica varia in base alla categoria del rilevamento. Utilizza un browser di prova e segui le istruzioni riportate di seguito.
- Cross-site scripting: l'URL Reproduction genera un popup vuoto nel browser, a indicare che la scansione ha inserito correttamente codice innocuo in uno script.
- Libreria obsoleta: l'URL vulnerabile restituisce una pagina con il testo "Exploited", che indica che la scansione ha iniettato correttamente codice benigno in uno script.
- Contenuti misti. Seguendo l'URL della pagina HTTPS viene visualizzato un avviso relativo a una vulnerabilità dei contenuti misti. Il report sui risultati identifica la risorsa vulnerabile in URL della risorsa gestita via HTTP.
- Iniezione di Flash: Web Security Scanner potrebbe restituire risultati in questa categoria, ma la maggior parte dei browser moderni è protetta dall'iniezione di Flash. È improbabile che questi risultati possano essere sfruttati.
- Contaminati del prototipo: segui l'URL nel campo URL di riproduzione e cerca le modifiche all'oggetto
Object.prototype
introdotte dal payload con i seguenti snippet JavaScript.({}).__secret_injected_property
({}).__defineGetter__.__secret_injected_property
({}).hasOwnProperty.__secret_injected_property
L'applicazione dei criteri di sicurezza dei contenuti (CSP) potrebbe comunque impedire l'esecuzione di codice JavaScript. Questa condizione può rendere più difficile riprodurre la vulnerabilità XSS. Se riscontri questo problema, controlla la console di log del browser per informazioni dettagliate sulla violazione CSP che si è verificata.