Ho un'applicazione ASP.NET Web Forms. C'è una pagina con TextBox e gli utenti inseriscono termini di ricerca in questi che sono usati per interrogare il database.Come Html.Encode nei moduli Web
So che ho bisogno di prevenire gli attacchi di JavaScript injection. Come faccio a fare questo?
In MVC vorrei usare Html.Encode. Non sembra essere riconosciuto in Web Form.
Grazie!
È possibile utilizzare HttpUtility.HtmlEncode
È possibile utilizzare Server.HtmlEncode (che si traduce in HttpServerUtility.HtmlEncode), ma Microsoft ha una libreria di protezione web migliore chiamato AntiXSS che è possibile scaricare dal CodePlex. Include un'utilità che utilizza un approccio white-list a HtmlEncoding (molto più sicuro e migliore e recommended by OWASP anche se puntano a un older version). Dispone inoltre di strumenti che consentono di ottenere frammenti HTML sicuri, ecc.
Se non si guarda nient'altro, tuttavia, dare un'occhiata allo OWASP top 10. Sembra che tu stia solo scalfendo la superficie della sicurezza delle app Web, e questa è la migliore risorsa in circolazione. Gli attacchi Cross-Site Scripting sono solo una delle tante cose di cui devi difendervi.
E 'anche quello che è necessario per conformarsi a se avete a che fare con qualsiasi tipo di conformità (PCI, Bandiera rossa, ecc)
Su webforms è possibile chiamare
HttpUtility.HtmlEncode(foo);
Fare attenzione a non raddoppiare.
+1 per "attenzione a non raddoppiare la codifica".
Se siete su ASP.NET 4 o più recente, è possibile utilizzare la seguente sintassi:
<%: Model.Username %>
che sarà HTML-codificare l'espressione. Scott Gu explains the benefit of this syntax:
abbiamo scelto il <%:%> sintassi in modo che sarebbe stato facile sostituire rapidamente istanze esistenti di <% blocchi =%> codice. Ti consente anche di cercare facilmente nella base di codice gli elementi <% =%> per trovare e verificare i casi in cui non stai utilizzando la codifica HTML all'interno dell'applicazione per assicurarti di avere il comportamento corretto.
Mi spiace, ma il filtro di input anti-XSS non è affatto un sostituto per il testo in chiaro HTML in fase di output-to-HTML. Tutti gli strumenti anti-XSS sono fragili, maneggiano input validi e incompleti: nella migliore delle ipotesi un cerotto per applicazioni mal scritte con problemi di escape HTML e non una cura che risolve il problema. – bobince
Si prega di commentare se si esegue il downvoting in modo da poter imparare dai miei errori ... – David
(Scusa per il -ve, ma è un problema serio con autori di webapp naive che stanno attaccando varie forme di output da stringhe di testo senza L'escaping HTML, la codifica JSON, la codifica URL o qualsiasi altro tipo di codifica sensibile al contesto sono necessari per l'attività specifica, quindi si aspettano un layer anti-XSS con filtro dell'input per risolvere in qualche modo tutto ciò. più che spazzolare i problemi sotto il tappeto.) – bobince