I problemi comprendono le vulnerabilità di accesso

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.

OWASP offre alcuni consigli solidi sul loro sito: link Sarai più sicuro e migliore usando un pozzo -respected resource di inventare la propria soluzione attraverso tentativi ed errori.

Tuttavia, apprendere come funziona un aggressore attraverso la sperimentazione come si sta facendo, è uno dei modi migliori per imparare come funziona e perché è così importante. Questo ti renderà uno sviluppatore migliore.

se sei ancora confuso dal secondo esempio e vuoi pensare a un attacco non-URL, immagina che a un utente del sito venga richiesta l'autenticazione secondaria, ma è già autenticato (come in un sito web della banca quando ti viene chiesto spesso di entrare la password nuovamente per autorizzare un trasferimento). La persona chiede un'azione da completare (come l'esempio del bonifico bancario) e non si accorge che l'azione non è ancora stata completata ma viene portata alla pagina di autenticazione con il modulo di accesso per l'autenticazione secondaria. Si allontanano dalla loro scrivania perché pensano erroneamente che tutto sia ora completo (molte persone non si disconnettono da sole che è un problema!) Un attaccante che passa si avvicina al loro schermo e inserisce uno script nella casella di login che ritorna il cookie di sessione, scrive la sessione verso il basso (o semplicemente usa il client di posta elettronica per inviarlo via email a se stesso) e scompare in un computer vicino e usa quel cookie per iniziare a utilizzare il sito web.

Cattivo! Uno dei cento esempi sono sicuro che tu possa pensare senza coinvolgere URL (pensa a qualcuno che chiede a un utente di digitare qualcosa nella loro casella di login "come prova della tua sicurezza, signore, vorrei proprio che tu scrivessi blah blah ".. e così via!

Inoltre, ricorda che molti sistemi controlleranno le voci di nome utente e password (quest'ultimo in forma crittografata spero!) nei file di registro e nei database, quindi con questa vulnerabilità un utente arbitrario può inserire codice di script nel database o nel file di registro e un l'utente tecnico con clienti che non sono necessariamente privi di iniezione o difetti XSS potrebbero leggere tali dati e attivare un attacco al loro sistema.