va bene "ripetutamente" xss-pulire i dati in CodeIgniter?

Question

I seguenti sono modi per dati XSS-pulite in Codeigniter:

• set global_xss_filtering in config per TRUE
• uso xss_clean()
• uso xss_clean come una regola di convalida
• impostare il secondo parametro a TRUE in $this->input->post('something', TRUE)

Va bene usare tutti o più di uno su un unico pezzo di dati?

Per esempio, sarebbe bene se ho ancora usato $this->input->post('something', TRUE) anche se i dati sono già stati disinfettati da regola di convalida global_xss_filtering e xss_clean?

Answer 1

Sì. Presumi, il tuo contributo è 'A'. Quindi, diciamo che si esegue un xss_clean per ottenere contenuti XSS-safe:

B = xss_clean(A) 

Ora, consente di dire che lo faccio di nuovo per ottenere C:

C = css_clean(B) 

Ora, se B e C differiscono, allora deve significare che B aveva un contenuto xss-non sicuro. Il che significa chiaramente che xss_clean è danneggiato in quanto non ha pulito correttamente A. Quindi, se si presume che la funzione restituisca contenuto xss-safe, sei a posto.

Un argomento che si può fare è cosa succede se la funzione modifica anche i contenuti xss-safe? Beh, quello sarebbe succhiare e significherebbe comunque che la funzione è rotta, ma non è questo il caso (dicendo solo per esperienza, come non l'ho mai visto comportarsi come mai).

L'unico inconveniente che vedo è il sovraccarico di elaborazione aggiuntivo, ma farlo due volte va bene (una volta con il filtro globale, e una volta esplicitamente, nel caso in cui il filtro globale è disattivato a volte da qualcuno), ed è un bel ok spese generali per la sicurezza.

Inoltre, se posso aggiungere, i codeigniters xss clean in realtà non analizzano l'HTML e rilasciano tag e cose. Semplicemente converte lo < e > in < e >. Con questo in mente, non vedo nulla che possa andare storto.

Answer 2

Non ti farà del male, ma è sicuramente inutile.

Ci sono ottime possibilità che alla fine raggiungerai un punto in cui il filtro XSS globale sarà ingombrante. Dal momento che non può essere disabilitato per controller senza hack estesi, e l'accesso ai dati grezzi $_REQUEST sarà impossibile, sarà necessario disabilitarlo globalmente. Ciò accadrà nel momento in cui desideri elaborare un singolo pezzo di dati attendibili o dati che non sono output HTML e devono rimanere intatti.

L'utilizzo come regola di convalida dei moduli è inutile e potenzialmente distruttivo. Immagina come sarebbe questo sito se ogni volta che hai digitato <script> è stato sostituito con [removed], senza possibilità di ripristinarlo in futuro.Per un altro esempio, cosa succede se un utente utilizza un contenuto "XSS" nella sua password? La tua applicazione finirà per alterare l'input in silenzio.

Usa il filtro XSS dove ti serve: sul tuo output HTML, dove può essere eseguito javascript.

Answer 3

L'utilizzo di xss_clean anche una volta è negativo per quanto mi riguarda. Questa routine tenta di disinfettare i dati rimuovendo parti o sostituendo parti. È una perdita e non è garantito il ritorno dello stesso contenuto quando viene eseguito più volte. È anche difficile da prevedere e non agirà sempre in modo appropriato. Data la quantità di cose che fa per cercare di disinfettare una stringa, c'è un enorme riscontro di prestazioni nell'usare questo in input. Anche il più piccolo bit di input come a = b causerà una raffica di attività per xss_clean.

Mi piacerebbe dire che non si dovrebbe mai usare xss_clean ma realisticamente non posso dirlo. Questo sistema è pensato per gli sviluppatori inesperti che non sanno come gestire in sicurezza i contenuti degli utenti. Sono uno sviluppatore esperto, quindi posso dire che nessun progetto su cui sto lavorando dovrebbe mai usare xss_clean. Il fatto è, però, che i problemi di corruzione saranno meno problematici per gli sviluppatori di inesperienza con un utilizzo più semplice e, in definitiva, probabilmente renderanno il loro codice più sicuro anche se dovrebbero rendere il loro codice più sicuro essi stessi piuttosto che affidarsi a hack veloci ed economici. D'altra parte, xss_clean non è garantito per rendere il tuo codice completamente sicuro e può peggiorare ultramoderno dando un falso senso di sicurezza. Ti consigliamo di studiare davvero per assicurarti di capire esattamente tutto ciò che fa il tuo codice in modo da renderlo veramente sicuro. xss_clean non compensa gli errori di codice, compensa gli errori del coder.

Idealmente xss_clean vuole essere fatto solo in uscita (e vuole essere sostituito con htmlentities, ecc) ma la maggior parte delle gente non perdete tempo con questo come è più semplice per loro di violare la purezza dei dati semplicemente filtrando tutti gli input, piuttosto che di filtraggio di uscita (qualcosa può essere inserito una sola volta ma emesso dieci volte). Ancora una volta, uno sviluppatore indisciplinato potrebbe non mettere xss_clean per uno di quei dieci casi di output.

Realisticamente tuttavia, l'unico vero modo decente è codificare correttamente tutto nella vista nel momento in cui deve essere visualizzato su una pagina. Il problema con la codifica preventiva consiste nel fatto che si memorizzano dati che potrebbero essere codificati in modo errato e che è possibile raddoppiare i dati se sono inseriti, quindi restituiti in un modulo, quindi immessi di nuovo. Se pensi a qualcosa come una casella di modifica, puoi avere alcuni problemi seri con la crescita dei dati. Non tutti i servizi igienico-sanitari rimuovono il contenuto. Ad esempio, se si aggiungelash questo aggiungerà il contenuto. Se si dispone di una barra nel contenuto ogni volta che si esegue addslashes, viene aggiunta una nuova barra che ne determina la crescita. Sebbene ci siano buone possibilità che i tuoi dati finiscano per essere incorporati nell'HTML, non puoi sempre sapere veramente dove finiranno i dati. All'improvviso ottieni un nuovo requisito che si applica ai dati precedenti e il gioco è fatto, sei fottuto perché hai applicato e hai perso il filtro sui dati in arrivo prima della memorizzazione. In perdita, in questo caso, ciò potrebbe significare il tuo lavoro dopo aver corrotto tutti i dati dell'utente nel tuo database. I tuoi dati sono solitamente la cosa più preziosa per un'applicazione web. Questo è un grosso problema con la codifica preventiva. È più facile lavorare con te se sai sempre che i tuoi dati sono puri e possono sfuggirli in base alla situazione, ma se i tuoi dati potrebbero essere in qualsiasi condizione, potrebbe essere molto problematico. Il filtraggio può anche causare rotture logiche occasionali. Poiché la sanificazione può rimuovere il contenuto, ad esempio, è possibile creare due stringhe che non corrispondono.

Molti dei problemi con xss_clean in ingresso sono uguali o simili a quelli per magic_quotes: http://en.wikipedia.org/wiki/Magic_quotes

Sintesi: Si consiglia di non usarlo, ma invece bloccare dati non corretti su input dell'utente e la fuga correttamente in uscita. Se si desidera disinfettare i dati dell'utente, dovrebbe avvenire nel client (browser, convalida del modulo) in modo che l'utente possa vederlo. Non si dovrebbe mai avere un'alterazione dei dati invisibile. Se è necessario eseguire xss_clean. Dovresti eseguirlo solo una volta, in uscita.Se hai intenzione di usarlo per la convalida dell'input, fai $ posted_data! == xss_clean ($ posted_data) quindi rifiuta.