Qual è la differenza tra AntiXss.HtmlEncode e HttpUtility.HtmlEncode?

Question

Ho appena incontrato una domanda con una risposta che suggeriva la libreria AntiXss per evitare lo scripting cross site. Sembra interessante, leggendo il blog msdn , sembra fornire solo un codice HTML () metodo. Ma utilizzo già HttpUtility.HtmlEncode ().

Perché dovrei usare AntiXss.HtmlEncode su HttpUtility.HtmlEncode?

In effetti, non sono il primo a porre questa domanda. E, in effetti, Google presenta alcuni risposte , principalmente

• Un approccio alla white list invece che alla black list
• Un miglioramento delle prestazioni di 0.1ms

Bene, è carino, ma cosa significa per me? Non mi importa molto delle prestazioni di 0,1 ms e non mi va di scaricare e aggiungere un'altra dipendenza dalla libreria per le funzionalità che già possiedo.

Ci sono esempi di casi in cui l'implementazione di AntiXss impedirebbe un attacco che l'implementazione di HttpUtility non avrebbe?

Se continuo a utilizzare l'implementazione di HttpUtility, sono a rischio? Che dire di questo "bug" ?

Answer 1

Non ho una risposta specifica alla tua domanda, ma vorrei sottolineare che l'approccio white list vs black list non si limita a " nice " ;. È importante. Molto importante. Quando si tratta di sicurezza, ogni piccola cosa è importante. Ricorda che con gli script cross-site e falsificazione di richieste cross-site , anche se il tuo sito non mostra dati sensibili, un hacker potrebbe infettare il tuo sito iniettando javascript e utilizzarlo per ottenere dati sensibili da un altro sito. Quindi farlo nel modo giusto è fondamentale.

Le linee guida OWASP specificano l'utilizzo di un approccio con lista bianca . Le linee guida sulla conformità PCI lo specificano anche negli standard di codifica (poiché fanno riferimento alle linee guida OWASP).

Inoltre, la versione più recente della libreria AntiXss ha una bella nuova funzione: .GetSafeHtmlFragment () che è utile per quei casi in cui si desidera archiviare HTML nel database e visualizzarlo come HTML.

Inoltre, come per " bug " ;, se stai codificando correttamente e seguendo tutte le linee guida di sicurezza, stai usando procedure memorizzate parametrizzate, quindi le virgolette singole saranno gestite correttamente, Se non stai codificando correttamente, nessuna libreria non protetta ti proteggerà completamente. La libreria AntiXss è pensata per essere uno strumento da utilizzare, non un sostituto della conoscenza. Fare affidamento sulla biblioteca per farlo bene per te si aspetterebbe che un pennello davvero buono produca buoni dipinti senza un buon artista.

Modifica - Aggiunto

Come richiesto nella domanda, un esempio di dove l'anti xss ti proteggerà e HttpUtility non lo farà:

HttpUtility.HtmlEncode e Server. HtmlEncode non impedisce lo scripting cross site

Questo è secondo l'autore, però. Non l'ho provato personalmente.

---

Sembra che tu sia in linea con le tue linee guida sulla sicurezza, quindi potrebbe non essere qualcosa che devo dirti, ma nel caso in cui uno sviluppatore meno esperto sia là fuori a leggere questo, il motivo per cui dico che la lista bianca l'approccio è fondamentale è questo.

In questo momento, oggi, HttpUtility.HtmlEncode può bloccare con successo ogni attacco là fuori, semplicemente rimuovendo / codificando < e >, oltre ad alcuni altri " conosciuti potenzialmente non sicuri " personaggi, ma qualcuno cerca sempre di pensare a nuovi modi di irrompere. Consentire solo contenuti conosciuti e sicuri (lista bianca) è molto più semplice che cercare di pensare a ogni possibile input non sicuro che un attaccante potrebbe lanciarti (nero -list approccio).

Answer 2

Per quanto riguarda il motivo per cui dovresti usare l'uno sull'altro, considera che la libreria AntiXSS viene rilasciata più spesso rispetto al framework ASP.NET, poiché, come dice David Stratton 'qualcuno cerca sempre di pensare a nuovi modi di rompere in ", quando qualcuno ne esce uno, la libreria AntiXSS ha molte più probabilità di ottenere una versione aggiornata per difendersi da essa.

Answer 3

Le seguenti sono le differenze tra i metodi Microsoft.Security.Application.AntiXss.HtmlEncode e System.Web.HttpUtility.HtmlEncode:

1. Anti-XSS utilizza la tecnica della white list, a volte indicata come principio delle inclusioni, per fornire protezione contro gli attacchi XSS (Cross-Site Scripting). Questo approccio funziona definendo innanzitutto un set di caratteri valido o consentito e codifica qualsiasi cosa al di fuori di questo set (caratteri non validi o potenziali attacchi). HttpUtility e altri metodi di codifica in quello spazio dei nomi usano il principio di esclusioni e codificano solo alcuni caratteri designati come potenzialmente pericolosi come < ;, > ;, & amp; e 'personaggi.

2. L'elenco di caratteri bianchi (o sicuri) della Biblioteca Anti-XSS supporta più di una dozzina di lingue (greco e copto, cirillico, integratore cirillico, armeno, ebraico, arabo, siriaco, arabo, Thaana, NKo e altro)

3. La libreria Anti-XSS è stata progettata appositamente per mitigare gli attacchi XSS mentre AntiXss.HtmlEncode() vengono creati metodi di codifica per garantire che l'output ASP.NET non rompa HTML.

4. Prestazioni: il delta medio tra HttpUtility.HtmlEncode() e <=> è +0,1 millisecondi per transazione.

5. Anti-XSS Versione 3.0 fornisce un cablaggio di prova che consente agli sviluppatori di eseguire sia la convalida XSS sia i test delle prestazioni.

Answer 4

La maggior parte delle vulnerabilità XSS (qualsiasi tipo di vulnerabilità, in realtà) si basano esclusivamente sul fatto che la sicurezza esistente non ha " prevede " certe cose succedono. Gli approcci solo della whitelist sono più adatti a gestire questi scenari per impostazione predefinita.

Answer 5

Utilizziamo l'approccio white list per i siti Windows Live di Microsoft. Sono sicuro che ci siano un numero qualsiasi di attacchi alla sicurezza che non abbiamo ancora pensato, quindi sono più a mio agio con l'approccio paranoico. Ho il sospetto che ci siano stati casi in cui la lista nera ha rivelato vulnerabilità che la lista bianca non ha fatto, ma non ho potuto dirti i dettagli.