Come prevenire gli attacchi di injection JavaScript all’interno di HTML generato dall’utente

Sto salvando l’HTML inviato dall’utente (in un database). Devo prevenire gli attacchi di injection javascript. Il più pernicioso che ho visto è lo script in uno stile = “espressione (…)”.

Oltre a questo, una buona quantità di contenuti utente validi includerà caratteri speciali e costrutti XML, quindi vorrei evitare un approccio di white list se ansible. (Elenco di ogni elemento HTML e attributo consentito).

Esempi di stringhe di attacco Javascript sono:

1)

“Ciao, ho un problema di alert (” bad! “) con l’elemento …”

2)

“Ciao, questo Dog è nero.”

C’è un modo per prevenire tali Javascript e lasciare intatto il resto?

L’unica soluzione che ho finora è di usare un’espressione regolare per rimuovere determinati modelli. Risolve il caso 1, ma non il caso 2.

Modifica: Scusa, ho dimenticato di menzionare l’ambiente: è essenzialmente lo stack MS:

  • SQL Server 2005
  • C # 3.5 (ASP.NET)
  • Javascript (ovviamente) e jQuery.

Vorrei che il chokepoint fosse il livello ASP.NET: chiunque può creare una richiesta HTTP errata.

Modifica 2:

Grazie per i link a tutti. Supponendo di poter definire la mia lista (il contenuto includerà molti costrutti matematici e di programmazione, quindi una lista bianca sarà molto fastidiosa) Ho ancora una domanda qui:

Che tipo di parser mi permetterà di rimuovere solo le parti “cattive”? La parte ctriggers potrebbe essere un intero elemento, ma che dire di questi script che risiedono negli attributi. Non riesco a rimuovere willy-nilly.

Solutions Collecting From Web of "Come prevenire gli attacchi di injection JavaScript all’interno di HTML generato dall’utente"

Pensi che sia? Dai un’occhiata a questo .

Qualunque approccio tu abbia, devi assolutamente usare una whitelist. È l’unico modo per avvicinarsi a quello che stai permettendo sul tuo sito.

MODIFICA :

Purtroppo non ho familiarità con .NET, ma puoi verificare la battaglia dello stackoverflow con XSS ( http://blog.stackoverflow.com/2008/06/safe-html-and-xss/ ) e il codice che era scritto per analizzare HTML pubblicato su questo sito: link Archive.org – ovviamente potrebbe essere necessario cambiarlo perché la tua lista bianca è più grande, ma dovrebbe iniziare.

La whitelist per elementi e attributi è l’ unica scelta accettabile secondo me. Tutto ciò che non è incluso nella tua lista bianca dovrebbe essere rimosso o codificato (cambia <> & “nelle entità). Assicurati anche di controllare i valori all’interno degli attributi che permetti.

Nulla di meno e ti stai aprendo ai problemi: exploit noti o quelli che verranno scoperti in futuro.

L’unico modo davvero sicuro per andare è usare una white-list. Codifica tutto, quindi ricontrolla i codici consentiti.

Ho visto tentativi piuttosto avanzati di non consentire codice pericoloso e non funziona ancora bene. È piuttosto difficile provare a catturare in modo sicuro tutto ciò a cui chiunque possa pensare, ed è incline a fare noiose sostituzioni di alcune cose che non sono affatto pericolose.

Fondamentalmente, come ha detto Paolo, dovresti cercare di concentrarti su ciò che gli utenti sono autorizzati a fare, piuttosto che cercare di filtrare le cose che non dovrebbero fare.

Mantieni un elenco di tag HTML consentiti (cose come b, i, u …) e filtra tutto il resto. Probabilmente vuoi anche rimuovere tutti gli attributi ai tag HTML consentiti (a causa del tuo secondo esempio, ad esempio).

Un’altra soluzione potrebbe essere quella di introdurre il cosiddetto codice BB, che è quello che molti forum usano. Ha una syntax simile a HTML, ma inizia con l’idea di una whitelist di codice consentito, che viene poi trasformato in HTML. Ad esempio, [b] esempio [/ b] risulterebbe nell’esempio . Assicurati quando usi il codice BB per filtrare anticipatamente i tag HTML.

Attualmente l’opzione migliore è utilizzare un’intestazione di Content Security Policy come questa:

 Content-Security-Policy: default-src 'self'; 

Ciò impedirà il caricamento di script, stili, immagini, ecc. Inline e esterni, quindi solo le risorse dalla stessa origine verranno caricate ed eseguite dal browser.

Tuttavia, non funzionerà con i vecchi browser.

quale codice lato server stai usando? A seconda di quale sia il numero o il modo in cui è ansible filtrare lo script dannoso ma è un territorio pericoloso. Anche i proffesionals esperti vengono catturati: http://www.codinghorror.com/blog/archives/001167.html

È ansible utilizzare questa funzione di limitazione.

 function restrict(elem){ var tf = _(elem); var rx = new RegExp; if(elem == "email"){ rx = /[ '"]/gi; }else if(elem == "search" || elem == "comment"){ rx = /[^az 0-9.,?]/gi; }else{ rx = /[^a-z0-9]/gi; } tf.value = tf.value.replace(rx , "" ); }