Soluzione per consentire l'input JavaScript ma prevenire XSS

Il link riguarda la crittografia e garantisce l'identità del server per impedire ad altre persone di ascoltare il traffico. Quindi non aiuta affatto contro il codice JavaScript malevolo entro i limiti della stessa politica di origine.

C'è un flag sui cookie chiamato link che impedisce al semplice codice JavaScript del browser moderno di accedere al cookie. Ma questo non risolve il problema , ma rende gli exploit un po 'meno semplici: il codice JavaScript può attivare direttamente gli invii di moduli con le autorizzazioni dell'utente corrente. Poiché JavaScript si trova sullo stesso dominio, ha accesso ai token CSRF . Il browser includerà il cookie sull'invio del modulo senza il codice JavaScript che deve accedervi. (E c'è una serie di bug attorno a HttpOnly, ad esempio alcuni browser consentono di leggere il cookie da un oggetto XMLHttpRequest.)

Inoltre, l'autore di JavaScript può sostituire il contenuto della pagina corrente con "La tua sessione è scaduta, effettua nuovamente il login" e il suo modulo di accesso . Ma il modulo che aggiunge non punta all'URL di login del tuo server ma a un server che controlla. O ancora più sottile, potrebbe esserci una chiamata Ajax interdominio nel gestore di eventi del pulsante di invio.

C'è una soluzione piuttosto semplice in due passaggi:

1. Filtra tutto il markup non affidabile , incluso tutto il codice JavaScript. Se stai utilizzando PHP, puoi utilizzare HTML-Purifier . Esistono librerie simili per tutte le lingue comuni.
2. Fornisci segnaposti innocui ("widget"). Quindi, invece di lasciare che i tuoi utenti incorporino direttamente il codice JavaScript, devono scrivere qualcosa come <div id="googleadd">identifier</div> . Un pezzo di codice JavaScript globale attendibile può sostituire quei frammenti di codice con il vero codice di aggiunta. Assicurati di sfuggire correttamente ai parametri di input. Ciò limiterà un po 'gli utenti in ciò che possono fare, ma è abbastanza facile coprire tutti i casi di utilizzo comuni.

Ha senso un po 'google in quanto ci sono già un certo numero di librerie di widget là fuori; anche se molti richiedono ancora chiamate JavaScript.

HTTPS non impedisce il furto di cookie, fa HTTPOnly flag . Vorrei raccomandare (se è possibile) di avere una libreria di "widget" che gli utenti possono includere nella pagina e configurare. Quindi puoi semplicemente inserire il codice JavaScript con i parametri configurati senza consentire all'utente di scrivere il codice JavaScript.

Se abiliti i tuoi utenti a inserire il proprio codice JavaScript, possono fare cose come aggiornare il modulo di accesso del tuo sistema di blog per inviare le credenziali a un altro server, in modo che se un utente visita la pagina del blog dannoso e decide di accedere al tuo sistema su quella pagina, le sue credenziali potrebbero essere compromesse.

No, HTTPS non blocca questa minaccia.

Se ai tuoi utenti deve essere consentito includere JavaScript che hanno scritto nella pagina, questo è un problema molto impegnativo. Quello che vuoi è una specie di sandbox Javascript . @Mike Samuel's raccomandazione di Caja è una buona scelta della tecnologia sandboxing Javascript. Altre possibilità in questo spazio includono Sandbox Web di Microsoft, AdSafe di Yahoo, FBJS di Facebook e probabilmente altri che ho perso.

Per favore comprendi che mentre le soluzioni esistono, non saranno del tutto banali da implementare. Ti sei imbattuto in un grosso problema nella sicurezza web; il web non è stato progettato per supportare questo tipo di cose e, di conseguenza, le soluzioni finiscono necessariamente per essere una tecnologia piuttosto complessa. Quindi probabilmente avrai bisogno del supporto di uno sviluppatore capace per implementare e integrare una di queste soluzioni nel tuo sito web.

Plug vergognoso ma pertinente:

Da code.google.com/p/google-caja/

Caja allows websites to safely embed DHTML web applications from third parties, and enables rich interaction between the embedding page and the embedded applications. It uses an object-capability security model to allow for a wide range of flexible security policies, so that the containing page can effectively control the embedded applications' use of user data and to allow gadgets to prevent interference between gadgets' UI elements.

Se consenti il monitoraggio di google, autorizzi già XSS, perché google-analitics è per definizione un XSS.

Potresti impostare un modello in cui l'utente dovrebbe incollare solo il suo ID che potresti disinfettare correttamente.

Non puoi mai consentire l'input javascript ed essere al sicuro. Prova a lavorare con il codice qui sotto. Pensi che sia sicuro? Ha alcune parole chiave che suggeriscono il pericolo? :)

$=''|'',_=$+!"",__=_+_,___=__+_,($)[_$=($$=(_$=""+{})[__+__+_])+_$[_]+(""+_$[-__])[_]+(""+!_)[___]+($_=(_$=""+!$)[$])+_$[_]+_$[__]+$$+$_+(""+{})[_]+_$[_]][_$]((_$=""+!_)[_]+_$[__]+_$[__+__]+(_$=""+!$)[_]+_$[$]+"("+_+")")();

Spoiler: è alert(1)

Per definizione, l'archiviazione di javascript e il rendering nel browser è XSS

1) Aggiungi identità

2) Aggiungi una norma di utilizzo: link

3) Sono contrario alla whitelisting / blacklisting del filtro dei siti server perché è una soluzione al problema principale, è difficile fare bene e può rilasciare input che non devono essere eliminati. Quando hai HTML5, CSS3 e JS in continua evoluzione, dovrai continuare ad aggiornare la tua lista bianca / lista nera fino al punto che il disinfettante in atto diventa semplicemente una pace di codice che consente tutto e quindi arriverà a un punto che sconfigge il suo scopo , ma se insisti su questa traccia OWASP HTML Sanitizer, JSoup è un altro esempio oltre a quello sopra citato.

4) Invece di 3) usa link e rilascia il supporto per i browser antichi, che è il modo corretto di risolverlo come sul server si memorizzerebbe il contenuto ma si eseguirà nel contesto del browser

5) Puoi aggiungere tag / segnaposti di template per ridurre il rischio (ad es. markdown), questo aiuterà anche gli strumenti di pentesting a non tornare indietro; alert (1); come il server si aspetterebbe input diversi per archiviare e inviare il javascript

6) Avviare AV e rafforzare l'analizzatore di codici statici sul server e spostarlo su

7) Convalida incorporata per errori: JSLint / JSHint / CSSHint, ecc.

8) Infine, se non ti fidi di nessuno degli automatismi sopra elencati, aggiungi il fattore umano per esaminare e approvare il passaggio prima della pubblicazione