Come posso migrare da filter-on-output a filter-on-input?

Question

Come posso migrare da filter-on-output a filter-on-input?

#1 da (5 voti)

3

Recentemente sono entrato in una società con un milione di app PHP in più code di codice. L'approccio alla sicurezza di XSS sembra essere quello di filtrare l'output ogni volta che lo sviluppatore ci pensava. Non sorprendentemente, non hanno catturato tutto, e abbiamo alcune vere opportunità XSS dozzine.

In una vita passata ho utilizzato l'approccio sostenitori di Rasmus : filter tutti gli input per essere protetti da XSS, e non sudare sul display. Questo approccio ha funzionato bene: la maggior parte dei dati funziona perfettamente la maggior parte del tempo e il codice che utilizza filter(UNSAFE_RAW) non è esattamente vietato, ma sicuramente riceve un'attenzione ulteriore nelle revisioni del codice.

Il problema che sto avendo è: come si fa a migrare da un approccio all'altro? Sembra che ora dovrò codificare tutti i contenuti del database e giocare a whack-a-mole per rimuovere tutti i nuovi bug a doppia codifica che scoprirò. (Dovrebbe essere un piccolo più facile dato che posso grep per l' esistenza di htmlspecialchars() ma non posso grep per la sua assenza .: ))

Una risposta davvero utile potrebbe essere un blog su un progetto di successo o addirittura un post-mortem.

php xss

posta Jeremy Wadhams 18.09.2013 - 23:39

fonte

1 risposta

Leggi altre domande sui tag php xss

Gestione chiavi AES App di controllo parentale sicura per Android?

score 5 · Answer 1

Il filtro sull'output è il metodo preferito di difesa XSS. Uno dei motivi per cui questo metodo di difesa XSS è popolare è perché non dipende dai dati nel database che si conformano a un set di codifica arbitrario. Filter-on-input significa che la vista dell'applicazione deve fidarsi del database, poiché si presuppone che questi dati siano già stati "filtrati". Se il database è compromesso con SQL Injection, un utente malintenzionato potrebbe introdurre dati contaminati nel database. Ecco un exploit che ho scritto che utilizza SQL Injection per ottenere XSS persistente su un'applicazione filter-on-input , XSS persistente non sarebbe stato possibile su un paradigma filtro su output.

Filter-on-output è anche un approccio più sicuro alla difesa XSS, e ti darò un esempio in PHP.

Diciamo che abbiamo un'applicazione PHP che usa htmlspeicalchars($var, ENT_QUOTES); alla cieca, su tutti gli input. Nella maggior parte dei casi, il classico caso di un utente malintenzionato che introduce <script>alert(1)</script> verrà impedito (un'operazione di decodifica come base64decode() eseguita dopo che htmlspeicalchars() risulterebbe in dati macchiati). Tuttavia, questa misura di sicurezza generale non previene tutti gli XSS nell'applicazione, soprattutto non impedisce il XSS in DOM eventi . Ad esempio:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);alert(document.cookie);//');" />

O ecco un altro esempio, dove javascript:alert(1) è il carico utile:

<a href=javascript:alert(1)>go back</a>

Non tutti i dati vengono utilizzati allo stesso modo, quindi è impossibile applicare una misura di sicurezza generale. Gli URL sono conformi a una diversa regola XSS rispetto a quella dei gestori di eventi ed entrambi sono molto diversi dal caso generale di XSS.

Quindi, come si esegue la migrazione da un filtro su output a filtro su input? NON . Il modo migliore per evitare che XSS utilizzi un sistema allettante compatibile con XSS come Twig . XSS è un problema con la vista, quindi hai bisogno di una vista che sia sicura.