Che cos’è la prevenzione cross-Site Scripting?
La prevenzione cross-site scripting è il processo di rilevamento e correzione delle vulnerabilità XSS nei siti Web o nelle applicazioni Web prima che raggiungano la produzione. Il rilevamento delle vulnerabilità XSS può essere eseguito automaticamente, utilizzando uno scanner di vulnerabilità automatico o manualmente eseguendo test di penetrazione. In questo articolo imparerete le migliori pratiche per la prevenzione cross-site scripting e come è possibile implementare immediatamente. Alla fine dell’articolo, troverai anche un link a uno scanner di vulnerabilità gratuito incentrato sugli sviluppatori in modo da poter iniziare a rilevare e correggere le vulnerabilità di cross-site scripting precocemente e spesso, come parte delle pipeline di sviluppo
In questo articolo, imparerai:
- Che cos’è la prevenzione cross-Site Scripting?
- Come funziona il cross-site scripting?
- Quali sono i tipi di attacchi XSS?
- Quanto è importante la prevenzione cross-site scripting?
- Cross site scripting di protezione
- Escape contenuto dinamico
- Whitelist valori
- Implementare un contenuto-la politica di sicurezza
- Disinfettare HTML
- HTTP solo i Cookie
- XSS Prevenzione con esempi di codice
- Cross-site scripting di prevenzione in Python (Django)
- Cross-site scripting di prevenzione in Ruby (Rails)
- Cross-site scripting di prevenzione in Java (Java Server Pages)
- Cross-site scripting di prevenzione in C# ASP.NET)
- Prevenzione cross-site scripting nel nodo
- Baffi.js
- Polvere.js
- Nunjucks
- Prevenzione cross-site scripting in PHP
- Prevenzione cross-site scripting in AngularJS
- Prevenzione cross-site scripting in React
- In che modo gli strumenti automatici possono aiutare a prevenire lo scripting cross-site?
Come funziona il cross-site scripting?
Gli attacchi XSS (Cross-Site Scripting) sono una forma di attacco di iniezione, in cui gli script dannosi vengono iniettati in applicazioni Web attendibili.
Un utente malintenzionato può utilizzare l’applicazione Web per inviare codice dannoso, in genere sotto forma di script lato browser, a un utente finale diverso, causando un attacco XSS.
Le vulnerabilità XSS sono molto comuni, si verificano quando un’applicazione Web utilizza l’input di un utente valido contenuto nell’output generato, ma senza la convalida o la codifica appropriata.
Con lo script dannoso inviato all’utente, il browser non è in grado di sapere categoricamente che lo script non deve essere considerato attendibile e successivamente esegue lo script. Questo script può quindi accedere a una moltitudine di dati, inclusi eventuali cookie, token di sessione o qualsiasi altra informazione sensibile che può essere conservata dal browser per quel sito.
Quali sono i tipi di attacchi XSS?
Esistono tre tipi principali di attacchi XSS:
- XSS riflesso: lo script dannoso proviene dalla richiesta HTTP corrente
- XSS memorizzato: lo script dannoso proviene dal database del sito web
- XSS basato su DOM: dove la vulnerabilità esiste nel codice lato client piuttosto che nel codice lato server.
Quanto è importante la prevenzione cross-site scripting?
Il danno derivante dallo sfruttamento di una vulnerabilità XSS dipende dalla sensibilità dei dati gestiti dal tuo sito. Ecco alcuni esempi in cui gli hacker hanno sfruttato le app vulnerabili XSS:
- Diffusione di worm sui social media: Facebook, Twitter e YouTube sono stati tutti attaccati con successo in questo modo.
- Dirottamento di sessione: JavaScript dannoso può essere in grado di inviare l’ID di sessione a un sito remoto sotto il controllo dell’hacker, consentendo all’hacker di impersonare quell’utente dirottando una sessione in corso.
- Furto di identità: se l’utente inserisce informazioni riservate come numeri di carta di credito in un sito web compromesso, questi dettagli possono essere rubati utilizzando JavaScript dannoso.
- Attacchi denial of service e atti vandalici sul sito web.
- Furto di dati sensibili, come le password.
- Frode finanziaria su siti bancari.
Cross-site scripting protection
Escape dynamic content
Di solito, quando una pagina web viene renderizzata, il contenuto dinamico viene intrecciato in HTML. Se il contenuto dinamico viene trattato in modo improprio, un utente malintenzionato può utilizzarlo per costruire un attacco XSS memorizzato. L’utente malintenzionato abuserebbe di un campo modificabile inserendo un codice JavaScript dannoso, che viene valutato nel browser quando un altro utente visita quella pagina.
Potresti non volere che i tuoi utenti creino HTML raw a meno che il tuo sito non sia un sistema di gestione dei contenuti. Escape tutti i contenuti dinamici provenienti da un archivio dati, in modo che il browser sa che deve essere trattato come il contenuto dei tag HTML, al contrario di HTML grezzo.
Fuga di contenuti dinamici in genere prevede la sostituzione di personaggi più significativi con le entità HTML codifica:
” "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
Come si vedrà negli esempi di codice qui di seguito, i più moderni quadri di sfuggire contenuto dinamico per impostazione predefinita.
Eseguendo l’escape del contenuto modificabile in questo modo, il contenuto non verrà mai trattato come codice eseguibile dal browser. Ciò impedirà la maggior parte degli attacchi XSS.
Valori whitelist
Se un elemento di dati dinamico può accettare solo una manciata di valori validi, limitare i valori nell’archivio dati. Inoltre, assicurati che la tua logica di rendering consenta solo valori noti e corretti.
Un esempio in cui è possibile utilizzare questo approccio è chiedere a un utente di selezionare il proprio paese da un elenco a discesa, invece di digitarlo manualmente.
Implementare una politica di sicurezza dei contenuti
I browser moderni supportano le politiche di sicurezza dei contenuti. I criteri di sicurezza dei contenuti consentono all’autore di una pagina Web di controllare da dove è possibile caricare ed eseguire JavaScript e altre risorse.
Affinché un attacco XSS sia possibile, l’utente malintenzionato deve essere in grado di eseguire script dannosi sulla pagina Web di un utente, iniettando tag < script>in linea da qualche parte all’interno del tag < html> di una pagina o ingannando il browser nel caricare il JavaScript da un dominio di terze parti dannoso.
Impostazione di una politica di sicurezza dei contenuti nell’intestazione di risposta vi permetterà di dire al browser di non eseguire JavaScript inline, e di scegliere i domini che possono ospitare JavaScript per una pagina:
Content-Security-Policy: script-src 'self' https://apis.google.com
Da whitelisting l’Url da cui gli script possono essere caricati, si sta implicitamente affermando che JavaScript inline non è consentito.
È anche possibile inserire la politica di sicurezza dei contenuti in un tag <meta>
nell’elemento <head>
di una pagina:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
Questo approccio è molto efficace nel proteggere i tuoi utenti, ma richiede disciplina per rendere il tuo sito pronto per tale intestazione. Mentre avere script in linea è considerato una cattiva pratica nel moderno sviluppo web, sono comuni nei vecchi siti legacy.
Per migrare dagli script in linea in modo incrementale, considerare l’utilizzo di rapporti di violazione CSP. Aggiungendo una direttiva report-uri nell’intestazione dei criteri, il browser notificherà eventuali violazioni dei criteri, anziché impedire l’esecuzione di JavaScript in linea:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
Questo ti darà la rassicurazione che non ci sono script in linea persistenti, prima di vietarli a titolo definitivo.
Disinfettare HTML
Per alcuni siti, vi è una legittima necessità di memorizzare e rendere HTML grezzo. Se il sito memorizza e rende contenuti ricchi, è necessario utilizzare una libreria di sanificazione HTML per garantire che gli utenti malintenzionati non possano iniettare script nei loro invii HTML.
Cookie solo HTTP
JavaScript dannoso può essere utilizzato per rubare un cookie contenente l’ID di sessione dell’utente. Raramente c’è una buona ragione per leggere o manipolare i cookie in JavaScript lato client, quindi considera di contrassegnare i cookie come solo HTTP, il che significa che i cookie verranno ricevuti, memorizzati e inviati dal browser, ma non possono essere modificati o letti da JavaScript.
Prevenzione XSS con esempi di codice
Prevenzione cross-site scripting in Python (Django)
I modelli in Django escape HTML per impostazione predefinita, quindi tutto ciò che assomiglia al seguente è generalmente sicuro:
**{{ contents }}**
È possibile ignorare l’escape utilizzando il filtro / safe. Ci sono spesso buone ragioni per farlo, ma è necessario condurre revisioni del codice su tutto ciò che utilizza questo comando:
**{{ contents | safe }}**
Si noti che l’escape HTML può anche essere attivata o disattivata con il tag {% autoescape %}
.
Prevenzione cross-site scripting in Ruby (Rails)
I modelli Rails sfuggono all’HTML per impostazione predefinita, quindi tutto ciò che assomiglia al seguente è generalmente sicuro:
<%= contents %>
È possibile ignorare l’escape utilizzando la funzione raw o utilizzando l’operatore <%==
. Spesso ci sono buone ragioni per fare questo, ma è necessario codice di condotta giudizi su qualsiasi cosa che utilizza queste funzioni:
<% raw contents %>
<%== contents %>
il Cross-site scripting di prevenzione in Java (Java Server Pages)
Usare c:out
tag per sfuggire in modo sicuro HTML:
<c:out value="${contents}">
I seguenti modi di scrivere ad un modello non fuggire HTML, così si dovrebbe usare con cura:
<%= contents %>
${contents}
<%
out.println(contents);
%>
il Cross-site scripting di prevenzione in C# ASP.NET)
Utilizzare uno dei seguenti funzioni tranquillamente fuggire in HTML (il <%:
modulo è stato introdotto nel ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
Il seguente modo di scrivere di un modello non sfugge HTML automaticamente, così si dovrebbe usare con cura:
<%= contents %>
Utilizzare HttpUtility.HtmlEncode(...)
se avete bisogno di manuale di fuga HTML.
Prevenzione cross-site scripting nel nodo
Baffi.js
In Baffi.js, qualsiasi tag in baffi doppi sfugge automaticamente all’HTML:
{{ contents }}
Tieni presente che i tag in baffi tripli non sfuggono all’HTML, quindi usali con cura:
{{{ contents }}}
Polvere.js
Tasto automaticamente i tag HTML fuga:
{ contents }
Tuttavia, la fuga può essere disattivato con il |s
operatore, in modo da utilizzare con cautela
{ contents | s }
Nunjucks
Se la funzione di escape è attivata nell’ambiente, Nunjucks automaticamente fuga tag per uscita di sicurezza:
{{ contents }}
Contenuto contrassegnato con la cassetta di sicurezza filtro non sarà sfuggito – utilizzare questa funzione con cautela:
{{ contents | safe }}
Auto escape può essere disattivata per un modello, in questo caso i tag devono essere sfuggito manualmente:
{{ contents | escape }}
il Cross-site scripting di prevenzione in PHP
Il comando echo in PHP non sfugge HTML per impostazione predefinita, il che significa che il codice come il seguente, che consente di estrarre i dati direttamente da una richiesta HTTP, è vulnerabile ad attacchi di tipo XSS:
<?php
Echo $_POST;
?>
il Cross-site scripting di prevenzione in AngularJS
Qualsiasi contenuto scritto in parentesi graffe automaticamente essere sfuggito, in modo che la seguente è sicuro:
<div>{{dynamicContent}}</div>
Tenete a mente che il codice che lega il contenuto dinamico per l’attributo innerHTML non sarà automaticamente sfuggito:
<div ="dynamicContent"></div>
<div innerHTML]="{{dynamicContent}}"></div>
il Cross-site scripting prevenzione, Reagiscono
contenuti dinamici scritto tra parentesi graffe automaticamente essere sfuggito a Reagire, quindi il codice seguente è sicuro:
render() {
return <div>{dynamicContent}</div>
}
Si può anche scrivere HTML grezzo da associazione del contenuto per il dangerouslySetInnerHTML proprietà. Il nome non è una coincidenza, quindi cerca qualsiasi codice simile al seguente:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
In che modo gli strumenti automatici possono aiutare a prevenire lo scripting cross-site?
Come accennato in precedenza, prevenire gli attacchi cross-site scripting può essere facile, con molti framework che sfuggono al contenuto dinamico per impostazione predefinita. Ma che la convenienza può portare a inavvertenza e alcune gravi debolezze di sicurezza per la vostra applicazione e il vostro business.
Assicurarsi sempre di eseguire la scansione delle vulnerabilità delle applicazioni prima di rilasciarle in produzione, idealmente come parte delle pipeline DevOps e CI/CD per rilevare e correggere le vulnerabilità di sicurezza in anticipo, su ogni build / commit.
È possibile iniziare ad automatizzare il test di sicurezza oggi con Dynamic Application Security Testing scanner di NeuraLegion, Nexploit. Creato per gli sviluppatori e senza falsi positivi, è possibile integrarlo nelle pipeline per spostare i test di sicurezza a sinistra ed essere sicuri in base alla progettazione.
Registrati per il tuo account GRATUITO qui: https://nexploit.app/signup