Ogni elemento di output dovrebbe essere filtrato o solo quelli che contengono dati modificabili dall'utente? [duplicare]

5

Sto sfogliando un'app legacy che aggiorna SQL per prevenire le iniezioni e le vulnerabilità XSS. So di applicare PHP 's htmlspecialchars() a tutto ciò che viene passato direttamente a uno script e visualizzato su una pagina.

Devo rimuovere il campo di ogni database non numerico anche se proviene da una tabella di ricerca generalmente non modificabile? Sto pensando che potrebbe fornire una protezione più strong - si presume che qualcuno abbia ignorato il proprio database e lavori da lì.

    
posta a coder 12.11.2014 - 15:11
fonte

2 risposte

12

Se non esiste un'interfaccia esterna alla tabella di ricerca, probabilmente non è necessario scrubare i dati che escono da tali tabelle per motivi di sicurezza. Ma potrebbe essere più facile per sempre fregare i dati che stai presentando piuttosto che aggiungere eccezioni.

Inoltre, se i dati nelle tabelle di ricerca sono sicuri per l'output HTML, cosa succede quando si passa all'output CSV? È ancora sicuro? Sei ancora fuggito correttamente?

"Difesa in profondità". Non devi necessariamente presupporre che il tuo database sia stato violato, ma sicuramente dovresti programmare in modo difensivo e non assumere che il database non contenga caratteri, dati e così via.

Ti consiglio di inserire la convalida dei dati in arrivo, convalidare l'output su qualsiasi cosa stia scrivendo e fare ognuno di quelli su ogni livello del sistema (ad esempio, browser web server, database dell'applicazione).

    
risposta data 12.11.2014 - 16:34
fonte
1

La risposta dipende da cosa c'è in quella colonna della tabella e da come deve essere usata. Nella maggior parte dei casi sfuggire i dati prima di inserirli in html è la cosa giusta da fare.

Potrebbero esserci situazioni in cui lo scopo di una tabella è quello di memorizzare frammenti di html che un amministratore può aggiornare per visualizzare determinati dati sul sito. Di solito questo sarebbe chiamato CMS. Se è quello che stai costruendo, allora non vorrai fuggire prima di includerlo in html. In tale situazione, essere in grado di inserire uno script sarebbe una caratteristica, non un bug.

Ovviamente in tale contesto devi stare attento a ciò che viene inserito in quel tavolo. Dovrebbe essere ugualmente impossibile per un estraneo mettere i dati in quella tabella come mettere un file html statico sul server.

Anche quando un amministratore autorizzato immette i dati nella tabella, la sua disinfezione sarebbe una buona idea per rilevare errori di sintassi e tag non bilanciati.

Quello che ho descritto qui è ovviamente l'eccezione alla regola secondo cui tutte le stringhe non-costanti devono essere precedute da escape prima di essere incluse in html.

Ignorare l'escape solo perché "conosci" quelle stringhe dal database non possono mai contenere tag html sarebbe pigrizia che tornerà e morderà in seguito. In caso di dubbi, utilizza l'escaping.

    
risposta data 12.11.2014 - 23:58
fonte

Leggi altre domande sui tag