Rimozione dannosa della stringa di query ASP.Net MVC5

Naviga le tue risposte
0

La mia applicazione web è costruita con ASP.Net MVC5. Uno dei metodi accetta parametri di stringa di query. I test di sicurezza hanno segnalato che accetta stringhe di query dannose e vengono visualizzati nel corpo senza alcuna modifica.

l'url inclusi i parametri Query vengono aggiunti all'output html dal pager MVCC per la paginazione.

descrizione dettagliata di seguito

Il nome di un parametro URL fornito arbitrariamente viene copiato nel valore di un attributo di tag HTML incapsulato tra virgolette doppie. Il payload 7dc29"style="behavior:url(#default#time2)"onbegin="alert(1)"2d524 è stato inviato in nome di un parametro URL fornito arbitrariamente. Questo input è stato echeggiato non modificato nella risposta dell'applicazione. Questo attacco proof-of-concept dimostra che è possibile iniettare JavaScript arbitrario nella risposta dell'applicazione. L'attacco proof-of-concept dimostrato utilizza un'espressione valutata dinamicamente con un attributo style per introdurre JavaScript arbitrario nel documento. Nota che questa tecnica è specifica per Internet Explorer e potrebbe non funzionare su altri browser.

Ho un filtro QueryString per le voci della lista nera @"</?\w+((\s+\w+(\s*=\s*(?:"".*?""|'.*?'|[^'"">\s]+))?)+\s*|\s*)/?>", "<img", "<iframe", "\";", "¼script¾", "embed src"

Inoltre, sanitizzo il parametro usando Microsoft.Security.Application.Sanitizer.GetSafeHtmlFragment()

La mia domanda: è sufficiente per proteggere l'attacco XSS? O come posso rimuovere la stringa di query dannosa?

    
posta Saanch 13.03.2014 - 15:47
fonte

2 risposte

1

Non dovresti rimuovere la stringa di query dannosa, ma dovresti codificarla correttamente quando esci nella pagina. Le liste nere sono raramente la strada da percorrere in sicurezza perché le cose cambiano sempre e ci sarà sempre un nuovo modo per scoprire la lista nera.

Ad esempio, se si emette un valore non sicuro in HTML dovrebbe essere codificato in HTML ( " diventa &quot; ) o se l'output in JavaScript deve essere codificato con entità esadecimale ( " diventa \x22 ). Per errore, leggi qualsiasi valore in cui non puoi garantire l'origine (questo significa stringa di query, valori di modulo, intestazioni o anche dati dal tuo database che potresti pensare sia "sicuro", ma un valore è solo sicuro se visto nel contesto del suo output).

Controlla il foglio Cheat di prevenzione XSS OWASP per ulteriori dettagli su come codificare in modo appropriato per output contesto.

    
risposta data 13.03.2014 - 17:16
fonte
0

Non utilizzare alcun filtro auto-implementato - la ruota è già stata inventata ...!

I filtri come quello che hai scritto hanno diversi problemi nascosti come il caso dei personaggi. Inoltre, l'approccio White-List è sempre più preferito rispetto all'approccio Black-List

Utilizza la libreria AntiXSS . Ora è integrato in .NET 4.5, ma non fare affidamento su questo. Aggiorna il pacchetto via nuget perché le versioni precedenti di AntiXSS possono essere ignorate ...! Vedi quanto segue per sapere come può essere ...

link

Dopodiché, tutto ciò che devi fare è il seguente comando: 

Sanitizer.GetSafeHtmlFragment(suspiciousCode);

Ed è sufficiente rimuovere tutti i tag e ottenere un testo pulito ...

    
risposta data 17.03.2015 - 07:30
fonte

Leggi altre domande sui tag

Revisione dell'approccio al solo hashing e crittografia lato client per l'applicazione web indirizzo a 3 byte della chiamata di sistema e uscita [chiuso]