Ho un campo di testo che consente all'utente di digitare qualsiasi cosa lui / lei vuole. Dopo il salvataggio, i risultati vengono in seguito visualizzati sullo schermo a un numero potenzialmente elevato di persone.
XSS mi sembra un po 'come la magia nera, quindi mi chiedo quali sono le migliori pratiche attuali per gestire questa situazione (da modi specifici per disinfettare l'input a modi specifici di codificare html da visualizzare)?
Esca le virgolette, filtra la parola javascript, limita le lettere consentite, ecc.
Potresti semplicemente leggere le linee guida OWASP su XSS .
Questa pagina aggiuntiva su OWASP dovrebbe essere utile, tratta i problemi di codifica nelle nostre discussioni di seguito.
Dato che vuoi le attuali best practice e l'ultima risposta qui è agosto 2012, ho pensato che potrei anche pesare e aggiornarlo.
Best practice per prevenire il tipo qualsiasi di attacco XSS (persistente, riflesso, DOM, qualunque cosa).
X-XSS-Protection: 1; mode=block per attivare la protezione del browser XSS riflettente in modalità di blocco anziché in modalità filtro. La modalità di blocco blocca gli attacchi come questo . X-Content-Type-Options: nosniff per impedire che JavaScript venga inserito in immagini e altri tipi di contenuto. Content-Security-Policy: con almeno script-src e style-src di almeno. Non consentire unsafe-inline o unsafe-eval . Questo è il papà delle intestazioni per uccidere XSS. <body data-foo="@foo" /> genererà una versione codificata HTML della variabile. per esempio. @foo darebbe " />
<body data-foo="" />" />
var foo = $("body").data("foo"); , altrimenti potresti introdurre una vulnerabilità. Idealmente, però, utilizza document.write o le funzioni textContent e text() di JQuery. Affrontali in ordine inverso. Concentrati su # 3 come questa è la mitigazione primaria per XSS, # 2 dice al browser di non eseguire nulla che sfugga e # 1 è una buona misura di difesa in profondità (se i caratteri speciali non possono entrare, possono ' t uscire). Tuttavia, il # 1 è più debole perché non tutti i campi possono essere validati rigorosamente e può compromettere la funzionalità (immagina Stack Exchange senza la possibilità di consentire " attr() " come input).
function escapeHtml(str) {
return String(str)
.replace(/&/g, "&")
.replace(/</g, "<")
.replace(/>/g, ">")
.replace(/"/g, """)
.replace(/'/g, "'")
.replace(/\//g, "/")
}
Componi il tuo codice HTML utilizzando un linguaggio modello di escape automatico che, per impostazione predefinita, sfugge per te input non attendibili.
Ad esempio, i modelli di Django sfuggono ai caratteri speciali HTML :
Clearly, user-submitted data shouldn't be trusted blindly and inserted directly into your Web pages, because a malicious user could use this kind of hole to do potentially bad things. This type of security exploit is called a Cross Site Scripting (XSS) attack.
To avoid this problem, you have two options:
- You can make sure to run each untrusted variable through the escape filter, which converts potentially harmful HTML characters to unharmful ones. This was the default solution in Django for its first few years, but the problem is that it puts the onus on you, the developer / template author, to ensure you're escaping everything. It's easy to forget to escape data.
- You can take advantage of Django's automatic HTML escaping. The remainder of this section describes how auto-escaping works. By default in Django, every template automatically escapes the output of every variable tag.
Ci sono anche una varietà di modelli autoesclusi contestuali che sono un po 'più intelligenti e possono prevenire XSS anche quando i tuoi modelli contengono JavaScript, CSS e URL incorporati.
Modelli di chiusura dice:
Contextual autoescaping works by augmenting Closure Templates to properly encode each dynamic value based on the context in which it appears, thus defending against XSS vulnerabilities in values that are controlled by an attacker.
Il linguaggio dei modelli di Go utilizza l'autoescapazione contestuale:
HTML templates treat data values as plain text which should be encoded so they can be safely embedded in an HTML document. The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.
La singola best practice: controllare rigorosamente il tipo e disinfettare i dati.
Usa sempre il metodo corretto per l'output dei dati in base al tipo: non rendere mai ciò che è stato inserito come testo in HTML (ad esempio, assegna i dati di testo immessi dall'utente alla proprietà .data del nodo di testo in DOM, non a mag%%% di%). Non utilizzare mai input in .innerHTML -like construction o come sottostringa della query del database: gli strumenti appropriati sarebbero rispettivamente parser di espressioni e segnaposti.
Rifiuta o ripulisci tutto ciò che arriva al tuo programma da fonti esterne (inclusi i tuoi database interni molto personali, che potrebbero essere anche compromessi!) a un set rigoroso di pattern consentiti.
Utilizza protocolli e serializzatori collaudati e collaudati per trasportare dati, preferibilmente uno che ha un'implementazione nativa sia su invio che su ricezione (serializzatore JSON, protobuf, memorizzabile in Perl, ecc.) invece di quotazioni fatte in casa.
I have a text field that allows the user to type whatever he/she wants. After saving, the results are later displayed on the screen to potentially many people.
Questo è il problema. Fai NOT input dell'utente fidato ... Per evitare XSS devi disinfettare l'input dell'utente prima di memorizzarlo nel DB.
Alcune cose che dovresti controllare:
Non consentire tag HTML. Una volta che tutti i tag sono vietati, puoi consentire ad alcuni di essi (come questo sito) come <hr> <b> ecc. Oppure creare il tuo sistema di tag, [img] [b] ...
Non consentire " o ' , sostituirli con il loro codice HTML " e '
Se prevedi di consentire collegamenti ipertestuali, assicurati che l'URL sia valido. In altre parole, devono iniziare con http:// o https://
Probabilmente, la lingua su cui si sta sviluppando l'applicazione ha funzioni per controllare la maggior parte dei punti precedenti (almeno, controllare preventivi e tag HTML).
Se il server serve solo entità e valori (quindi non serve le parti DOM), e non crea html, i valori di codifica creano problemi di codifica perché la parte che integra questi valori nel DOM è già supposta di non fidarsi del suo input, che si traduce in problemi di doppia codifica.
Penso che il ruolo di un tale server (che non costruisce DOM ma memorizza e serve solo dati) non è quello di disinfettare gli input. Tuttavia, può ancora convalidare gli input in anticipo e restituire una 400 Bad Request se viene rilevato un pattern di attacco. In questo modo, il server contribuisce alla protezione dall'XSS senza tutti i problemi di modifica dei dati dovuti alla disinfezione.
Penso che i servizi di sanitizzazione lato server debbano essere riservati ai server che creano DOM lato server: che servono pagine HTML o parti di pagine HTML.
Ma se DOM viene modificato sul lato client, il codice JS non deve fidarsi del suo input e impedire le iniezioni XSS.
Il problema è: in Java, le librerie di sicurezza OWASP offrono API per disinfettare l'HTML, ma non solo per valorizarlo. Per farlo, ho trovato l'annotazione di ibernazione @SafeHtml che utilizza JSoup e può essere facilmente utilizzata sui campi DTO con annotazione @Valid per abilitare la convalida su una classe / metodo / parametro.
Scusami se non sono molto chiaro. L'inglese non è la mia lingua madre. Il modo migliore per garantire un elevato livello di sicurezza nel tuo prodotto è seguire la regola d'oro: " Non fidarti mai degli input utente "
Quindi devi sempre dare per scontato che un utente proverà a inviare dati inattesi alla tua app, che non seguirà i protocolli (ad esempio: falsificherà alcuni campi, farà la richiesta di risposta, ecc.) E devi pronosticare il suo comportamento.
Per il punto XSS dovresti
- > Convalida l'input dell'utente (es .: se prevedi di ottenere un nome, dovresti bloccare tutti i valori che contengono caratteri speciali come% o ", se prevedi un numero di telefono dovresti bloccare i valori che contengono lettere, un così via)
- > Disinfetta l'input dell'utente (es .: sfugge a tutti i caratteri che hanno una semantica specifica per l'interprete nel backend. Per l'XSS è usualmente html / javascript quindi dovresti preoccuparti di ", & lt ;, > priorità)
Come hanno detto i nostri compagni, l'OWASP offre un'ottima guida sulla prevenzione dell'XSS: link
Leggi altre domande sui tag xss