Entrambi i casi sono gravi vulnerabilità e l'approccio alla sicurezza è sbagliato.
Prima di tutto, il modulo stesso non dovrebbe sfuggire a nulla. Potresti voler controllare l'input, ma non manipolarlo. L'escaping è fatto in uno specifico contesto come una query di database, non globalmente.
No, non è sicuro semplicemente anteporre un backslash a virgolette singole nell'applicazione:
- I sistemi di database supportano codifiche di caratteri diverse che potrebbero o meno corrispondere alla codifica utilizzata dall'applicazione. Se non corrispondono, il tentativo di fuga è essenzialmente uno sparo al buio e potrebbe non funzionare affatto. C'è un famoso attacco di iniezione che sfrutta le differenze tra due codifiche di caratteri comuni . L'unico modo per essere sicuri è utilizzare una funzione di libreria con conoscenza della codifica del proprio sistema di database. Ad esempio, MySQL ha
mysql_real_escape_string()
.
- Il backslash-escape è un meccanismo non standard che funziona solo in alcune modalità speciali di alcuni sistemi di database (come MySQL). Se la configurazione del server o il database sottostante cambiano, potresti perdere di nuovo tutta la protezione.
- Ci sono molti più caratteri di cui devi occuparti. Ciò dipende anche dal sistema di database e dalla sua configurazione.
L'escape manuale di SQL è in realtà un approccio piuttosto scadente, perché è complicato, noioso e soggetto a errori (come puoi vedere). Una soluzione più moderna consiste nell'usare istruzioni preparate e non inserire dati utente in query SQL in primo luogo. Se, per qualche motivo, le istruzioni preparate non sono un'opzione, assicurati di utilizzare la funzione di libreria corretta invece di provare a inventare la tua soluzione.
Il tuo secondo caso è una vulnerabilità di scripting cross-site in piena regola, quindi un utente malintenzionato può eseguire qualsiasi cosa che è possibile con XSS (come rubare un cookie di sessione). No, XSS non è limitato agli URL in alcun modo. L'hai appena dimostrato. Un attacco XSS si verifica quando un utente è in grado di iniettare dati in un contesto HTML. Da dove provengono i dati è irrilevante; potrebbe essere l'URL, potrebbe essere un paramater di modulo, potrebbe essere un cookie, un'intestazione HTTP, una stringa di database, qualsiasi cosa.