Iniezione di e commerciale nell'URL

7

Diciamo che c'è un programma che invia alcuni dati al server tramite GET:

http://server.com/gateway?value1=abc&value3=def

Quindi il server invia questi valori ulteriormente, aggiungendo value2: (python code)

SECURED_VALUE = "safe"
"http://externalAPI.com/?value1={0}&value2={1}&value3={2}".format ( get['value1'], SECURED_VALUE, get['value2'] )

E il mio punto è, posso iniettare un altro attributo a quest'ultima richiesta in un modo come:

http://server.com/gateway?value1=abc&&value2=hacked&value3=def&&value2=hacked

quindi il server - > La richiesta API è simile a:

http://externalAPI.com/?value1=abc&value2=hacked&value2=safe&value3=def&value2=hacked

L'API esterna molto probabilmente leggerà solo l'ultima o la prima occorrenza della chiave ripetuta.

Quindi ho due domande, la principale, se tale modifica è possibile e si dovrebbe proteggere le sue app contro di essa. Secondario, come farlo realmente, non solo con il metodo GET, ma forse con il POST, o modificando una stringa codificata JSON. Decodificare JSON con una e commerciale o punto e virgola mi dà un errore, mettendo la e commerciale nel metodo POST si comporta come nel metodo GET.

Chiedo questo, perché ho trovato un problema di sicurezza e sto attualmente scrivendo un esempio di un tentativo di hacking di successo nel caso uno sviluppatore di server non togliesse le e commerciali e altri personaggi rischiosi. Non voglio diventare uno stupido che non sa che una tale iniezione non può essere eseguita e sta solo perdendo tempo di amministratori, quindi ho pensato di chiederti prima.

In terzo luogo, mini-domanda, conosci qualche buona fonte di saggezza su come proteggersi dall'iniezione (quali funzioni utilizzare per questo) in Google App Engine, python, framework webapp2?

    
posta Markus von Broady 28.04.2012 - 19:01
fonte

1 risposta

6

Panoramica. Sì. Hai ragione. Molto bravo ad averlo notato.

Dettagli. Si tratta fondamentalmente di un'istanza di Inquinamento dei parametri HTTP vulnerabilità. Si tratta fondamentalmente di una vulnerabilità di iniezione (analoga a XSS, tranne che è l'iniezione nei parametri HTTP piuttosto che l'iniezione in HTML).

Difese. Per difenderci da ciò, ti suggerisco di fare due cose:

  1. Disinfetta i valori dei parametri. Crea una whitelist di caratteri che dovrebbero comparire nelle tue query e che sono noti per essere sicuri in questo contesto (assicurati che non includa & , ? , = , # , % ) e rimuove tutto il valore del parametro che non è nella whitelist.

  2. L'URL codifica i valori dei parametri prima di interpolarli nella nuova query.

Ricerca correlata. Vedi anche il seguente documento di ricerca:

risposta data 28.04.2012 - 23:44
fonte

Leggi altre domande sui tag