Sterilizzare HTML prima di riporre nel DB o prima del rendering? (Biblioteca AntiXSS in ASP.NET)

Question

Ho un editor che consente agli utenti di aggiungere codice HTML che viene memorizzato nel database e reso in una pagina web. Dal momento che questo è un input non attendibile, ho intenzione di usare Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment per disinfettare il codice HTML.

• Devo santiize prima di salvare nel database o prima del rendering dell'ingresso non attendibile nella pagina web?
• C'è un vantaggio nel incluso il codice sorgente AntiXSS nel mio progetto anziché solo la DLL? (Forse posso personalizzare la lista bianca?)
• Quale file classe dovrebbe mi guardo per effettiva attuazione del GetSafeHtmlFragment

Answer 1

Non sono d'accordo con la risposta selezionata per due motivi

1. Se si è memorizzato dati codificati, devi scegliere un encoder prima di memorizzare. Che cosa succede se è stato memorizzato qualcosa come HTML, ma anche voglia di spingerlo fuori in un altro formato, ad esempio, come risposta JSON, o come parte di un documento XML? Ora avete un un HTML formato codificato è necessario decodificare, quindi codificare nel formato corretto.
2. Che cosa succede se si scopre un bug nei codificatori e spingere una nuova versione fuori? Ora, perché non siete la codifica nel punto di uscita tutti i tuoi vecchi dati possono contenere le cose che sono state codificate in modo non corretto. È possibile codificare di nuovo, ma poi ha colpito i problemi matrimoniali di codifica che può essere doloroso per filtrare correttamente.

In genere si codifica nel punto di uscita e trattare tutti i dati provenienti da un archivio dati come non attendibile per difetto - dopo tutto, che cosa succede se qualcuno riesce a modificare direttamente o tramite iniezione SQL database

Answer 2

Dai ascoltare la podcast di OWASP 67 con Jeff Williams su XSS . Parla di non sanificazione o la codifica prima dello stoccaggio. Il motivo principale è che se (quando) le biblioteche si evolvono in risposta alle nuove vulnerabilità i dati sta per essere bloccato di nuovo nella vecchia versione. Naturalmente questo non ti impedisce di correre qualsiasi ingresso contro una whitelist al punto di ingresso e rifiutare nulla al di fuori dell'intervallo accettabile.

Answer 3

• Entrambi
• Solo se si ha intenzione di cambiarla, che io non farei personalmente
• La classe AntiXSS (dal momento che è chiamato come AntiXss.GetSafeHtmlFragment())

Answer 4

È possibile utilizzare la direttiva di pagina nel parametro ValidateRequest = "true" . In questo modo tutti i dati richiesta viene convalidato e se c'è un problema di validazione è sempre possibile rilevare l'errore. Inoltre impedisce fili iniezione SQL e altri non solo possibile XSS.

Con i dati numerici, è possibile convalidare integer overflow o uso improprio dei tipi di dati con Int32.TryParse () o qualsiasi altro della famiglia TryParse (Byte.TryParse Int16.TryParse ...)

Non c'è bisogno di usare qualsiasi altra classe o un metodo disinfettante aggiuntivo.