Il carattere commerciale ( & ) non è realmente proibito, ma poiché è il separatore per i parametri della stringa di query, utilizzarlo senza caratteri di escape in un nome o valore di parametro causerà un comportamento indesiderato, ad esempio se si dispone di un parametro foo=bar&baz e un altro quux=1 , un ingenuo tentativo di cuocere un URL potrebbe risultare in http://www.example.com/home?foo=bar&baz&quux=1 ; i parametri della stringa di query verranno analizzati come (scusa lo pseudo-JSON) { "foo": "bar", "baz", "quux": 1 } . Un effetto simile può essere causato da altri caratteri speciali ( = , @ , + , % ), se concatenati in una stringa di query senza caratteri di escape.
Mischiare in modo errato (o meglio, costruire erroneamente) i parametri di una stringa di query come questa è spesso solo una seccatura (i valori non finiscono dove li si aspetta), ma spesso possono essere abusati per ingannare un'applicazione Web per fare qualcosa piuttosto non dovrebbe - quale sarebbe una vulnerabilità di sicurezza.
Tutte le piattaforme di programmazione web forniscono un modo per sfuggire ai parametri della stringa di query e molti altri hanno altri modi di costruire stringhe di query per te che si occupano dell'escaping. L'altro modo, BTW, è gestito automaticamente: praticamente ogni stack web decodifica i parametri della stringa di query prima di passarli al codice, quindi quando li rileggi, sono già tornati nella loro forma originale.
La cosa <b> è una storia diversa: di per sé, inserire l'HTML (o cose che assomigliano all'HTML) in un parametro stringa di query non è affatto un problema e potrebbero esserci anche usi legittimi per questo. Tuttavia, i parametri della stringa di query vengono spesso inseriti nella risposta HTML e, quando ciò accade, fa ha un problema. Un esempio che ho visto in the wild ha utilizzato un parametro stringa di query per passare un messaggio di errore, che è stato poi inserito in una bella finestra di errore rossa; il messaggio di errore è stato inserito senza ulteriori verifiche o elaborazioni, quindi un utente malintenzionato potrebbe inserire% tag% d_deput ed eseguire javascript dannosi, ad esempio leggendo il cookie di sessione corrente e pubblicandolo nella casella personale dell'attaccante, che consentirebbe quindi all'attaccante di assumere il controllo la sessione della vittima. Questo vettore di attacco viene comunemente definito Scripting cross-site (XSS) ed è una vulnerabilità sia comune che seria.
Tuttavia, l'eliminazione del codice potenzialmente pericoloso dai parametri della stringa di query è una difesa piuttosto debole e costosa. Il modo corretto di impedire XSS è di uscire ('html-encode'; ancora, ogni stack di programmazione web che conosco fornisce una funzione per fare ciò) dati non attendibili durante l'output di HTML, non durante la lettura. Quindi, nel mio esempio precedente, la correzione corretta sarebbe stata quella di codificare html il messaggio di errore prima di scriverlo nella pagina HTML.