Prevenire attacco XSS

Question

Sto lavorando su un progetto sito Web ASP.Net C# + jQuery ajax. Sto cercando di prevenire gli attacchi xss e so che di seguito non è l'approccio completo, ma questo è almeno quello che dovrei fare - per usare HtmlEncode quando si accetta la stringa libera dagli utenti). E io davvero qualcuno che controlli gentilmente se sto facendo la cosa giusta.

Quindi supponiamo di avere uno scenario per il quale uno dei controlli di pagina è una casella di testo "Descrizione" e gli utenti possono immettere una stringa "libera" utilizzata per descrivere il loro prodotto. Per evitare di ottenere input di attacco xss, nel Metodo pagina lato server, ho concluso il testo "Descrizione" utilizzando HtmlUtility.HtmlEncode(), quindi la stringa verrà interpretata come testo puro prima di passare al database, ovvero <script> diventa >script<.

La parte che segue è quello che sono in dubbio: come gestire il testo codificato in html prima di restituirlo all'utente?

Quando l'utente desidera visualizzare il testo della descrizione immesso, il sito Web recupera dal database e lo stampa.

È logico eseguire la decodifica html nella descrizione in modo che l'utente non veda quei caratteri Wierd ><? In primo luogo, sconfiggerà lo scopo di usare HtmlEncode? E se sì, è questa la linea jQuery corretta per decodificare e stampare il testo agli utenti ???

$("#txtDescription").val($(this).html(obj.Description).text();

Grazie molto molto

Answer 1

È necessario tenere a mente il tipo di contenuto di ogni stringa con cui si gestiscono e da dove proviene, da una fonte sicura o da una fonte non affidabile, e anche sapere quando concatenare due stringhe che sono entrambe stringhe dello stesso contenuto -tipo e livello di fiducia.

ho avvolto la "Descrizione" testo utilizzando HtmlUtility.HtmlEncode(), quindi la stringa viene interpretato come puro testo prima di andare in banca dati cioè <script> diventa >script<.

Qui sembra che tu stai dicendo che il campo di descrizione è una stringa di testo normale e quello che stai memorizzazione nel database è una stringa di sicuro HTML (dal HtmlEncode s' uscita è garantito di non contenere pericolosi codice).

Questo mostra il primo problema con la codifica prematura del contenuto. Se stai componendo una stringa SQL da inviare al server, la codifica preliminare come HTML non ti protegge dall'iniezione SQL. L'utilizzo di un'istruzione SQL preparata è un buon metodo per superare questo problema per SQL, ma la pre-codifica non rende sicura una stringa in tutti i contesti.

La parte che segue è quello che sono in dubbio: come gestire il testo codificato in html prima di restituirlo all'utente?

Quando l'utente desidera visualizzare il testo della descrizione immesso, il sito Web recupera dal database e lo stampa.

Se l'utente riceve HTML sicuro e si dispone di una stringa di HTML sicuro, è sufficiente inviarlo all'utente.

Se l'utente riceve un messaggio di testo in chiaro, è necessario convertire il codice HTML di sicurezza memorizzato nel database in testo normale.

Se l'utente riceve RSS, è necessario assicurarsi di comporre il proprio RSS utilizzando sottostringhe XML.

Contextual auto-escaping può aiutarti a verificare che i valori siano correttamente codificati in uscita.

Answer 2

non codificano il testo in corso nel database. Conservalo nella sua forma grezza e non filtrata. Codifica solo i caratteri HTML quando la stringa viene esportata in un contesto che supporta HTML (come l'output sul browser).

Answer 3

È consigliabile utilizzare AntiXss library anziché httputility.htmlencode. Considerare la lettura della documentazione per maggiore chiarezza. Sono disponibili opzioni più ampie nella codifica di input w.r.t della libreria AntiXSS. Segue un approccio basato su white list più sicuro come menzionato in questo discussion.