Come proteggo dagli attacchi XSS in attributi come src?

c# html-agility-pack security xss

Domanda

Quindi ho creato un disinfettante in C # html usando l'agilità html con una lista bianca. Funziona bene, tranne casi come questi:

<img src="javascript:alert('BadStuff');" />
<img src="jav&#x09;ascript:alert('BadStuff');"> 

Voglio consentire l'attributo src, ma non roba malevola in esso ovviamente. Tutte le cose che ho cercato hanno appena consigliato una lista bianca per i tag e i loro attributi. Come gestiresti qualcosa di simile? So che questo non funzionerà con nessun browser più recente, ma non ho molta familiarità con la sicurezza e sono sicuro che ci sono altre cose intelligenti che gli hacker potrebbero fare.

Risposta accettata

Gli attacchi XSS (Cross-Site Scripting) sfruttano le vulnerabilità nella convalida della pagina Web inserendo codice script lato client. Le vulnerabilità comuni che rendono le vostre applicazioni Web vulnerabili agli attacchi di cross-site scripting includono il mancato validamento dell'input, la mancata codifica dell'output e la fiducia dei dati recuperati da un database condiviso. Per proteggere la tua applicazione dagli attacchi di cross-site scripting, supponi che tutti gli input siano dannosi. Vincola e convalida tutti gli input. Codifica tutti gli output che potrebbero, potenzialmente, includere caratteri HTML. Ciò include i dati letti da file e database.

Uno degli esempi più gravi di un attacco di scripting cross-site si verifica quando un utente malintenzionato scrive uno script per recuperare il cookie di autenticazione che fornisce l'accesso a un sito attendibile e quindi invia il cookie a un indirizzo Web noto all'attaccante. Ciò consente all'aggressore di falsificare l'identità dell'utente legittimo e ottenere accesso illecito al sito Web.

Le vulnerabilità comuni che rendono la tua applicazione Web vulnerabile agli attacchi di cross-site scripting includono:

  • Impossibile vincolare e convalidare l'input.
  • Impossibile codificare l'output.
  • Fidati dei dati recuperati da un database condiviso.

Linee guida

Le due contromisure più importanti per prevenire gli attacchi di cross-site scripting sono:

  • Vincola l'input.
  • Codifica output.

Riepilogo dei passaggi

Per evitare lo scripting cross-site, procedere come segue:

Passaggio 1. Verificare che la convalida della richiesta ASP.NET sia abilitata.

Passaggio 2. Rivedere il codice ASP.NET che genera l'output HTML.

Passaggio 3. Determinare se l'output HTML include parametri di input.

Passaggio 4 . Esamina i tag e gli attributi HTML potenzialmente pericolosi.

Passaggio 5 . Valutare le contromisure.

Per dettagli vedi il 2 ° riferimento.

Riferimenti:

Script cross-site spiegato: Come prevenire gli attacchi XSS

Procedura: impedire la creazione di script tra siti in ASP.NET


Risposta popolare

È possibile consentire in modo sicuro l'attributo src, a condizione che si disinfetti e gestisca l'input correttamente. Per fare questo dovresti prima sanitizzarlo attraverso una whitelist di caratteri URL validi, canonicalizzarlo e quindi verificare che punti ad un'immagine valida.

La whitelist che hai menzionato è il primo passo (e uno importante). Per implementare la lista bianca, basta rimuovere tutti i caratteri che non sono validi per un URL. Verificare inoltre che l'URL sia formato correttamente, nel senso che punta a una risorsa valida a cui l'utente dovrebbe essere in grado di accedere. Ad esempio, l'utente non deve accedere a un file locale sul server passando il file://sensitive.txt o qualcosa del genere. Se http o https sono gli unici protocolli che dovrebbero essere utilizzati, controlla che l'URL inizi con quelli. Se sei un paranoico in più, puoi rifiutare del tutto la richiesta poiché è ovvio che è stata manomessa. La whitelist è importante, ma la whitelist da sola tuttavia non manterrà la funzionalità protetta.

La canonizzazione è importante perché molti attacchi dipendono dall'invio di URL che alla fine ti portano in una certa posizione, ma possono abusare della mancanza innata del ragionamento del computer per ottenere cose che non dovrebbero. Ciò aiuterà anche a eliminare i percorsi duplicati verso la stessa risorsa, che potrebbero migliorare le prestazioni (o almeno consentire di migliorare le prestazioni non ricontrollando un file noto che non è cambiato dall'ultima volta che è stato controllato. è possibile falsificare un'ultima data modificata in modo che un utente malintenzionato possa scambiare un file malevolo dopo averlo già controllato e considerato attendibile).

Per verificare che stai puntando a un'immagine valida, apri il file e leggi i primi pochi byte. Non è sufficiente fidarsi l'estensione del file, anche se non controllano in primo luogo prima di aprire il file (per le prestazioni e per la sicurezza). Ogni formato di immagine ha un determinato modello di byte che puoi controllare. Uno buono da guardare in primo luogo è JPEG . Potrebbe essere ancora possibile per un utente malintenzionato inserire codice shell o altro codice di attacco in un file immagine contenente le intestazioni corrette, ma è molto più difficile da eseguire. Questo sarà un collo di bottiglia delle prestazioni, quindi pianificalo in modo appropriato se lo implementi.



Related

Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow
È legale questo KB? Sì, impara il perché