Codifica/offuscamento dei parametri HTTP

Question

Attualmente stiamo lavorando a una Webapp molto semplice e vorremmo "offuscare" (quale sarebbe il termine giusto?) O codificare in qualche modo il parametro di richiesta, in modo da ridurre la possibilità un utente inattivo dall'invio di dati arbitrari.

Ad esempio, l'URL sembra /webapp?user=Oscar&count=3

Vorremmo avere somthing come: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT e che hanno il valore decodificato nel server con la reale richiesta informazioni.

Prima di implementare qualcosa di simile (e probabilmente farlo male) mi piacerebbe sapere se c'è già qualcosa da fare?

Abbiamo Java sul server e JavaScript sul client.

Answer 1

No, non farlo. Se riesci a creare qualcosa nel tuo codice cliente per nascondere i dati trasmessi al server, allora anche un hacker ostinato. Semplicemente non puoi fidarti dei dati che vengono inviati al tuo server, indipendentemente dal tuo client ufficiale. Attacca per sfuggire i dati del client e convalida contro una whitelist sul lato server. Utilizza SSL e, se possibile, inserisci i parametri della tua richiesta in un POST anziché in GET.

espansione modificare

vostra confusione deriva dal l'obiettivo di impedire agli utenti di manomissione dati di richiesta, con la necessità di attuare misure di sicurezza standard. Le misure di sicurezza standard per le applicazioni Web implicano l'utilizzo di una combinazione di autenticazione, gestione di privilegi e sessioni, audit trail, convalida dei dati e canali di comunicazione sicuri.

L'utilizzo di SSL non impedisce al client di manomettere i dati, ma impedisce agli utenti del settore di visualizzarli o manometterli. Indica anche ai browser ben educati di non memorizzare nella cache dati sensibili nella cronologia degli URL.

Sembra che tu abbia una sorta di semplice applicazione web che non ha autenticazione e passa i parametri di richiesta che la controllano proprio nel GET, e quindi alcune persone non tecnicamente esperte potrebbero probabilmente capire che user=WorkerBee può essere semplicemente cambiato a user=Boss nella barra del browser, e quindi possono accedere ai dati che non dovrebbero vedere o fare cose che non dovrebbero fare. Il tuo desiderio (o il desiderio del tuo cliente) di offuscare quei parametri è ingenuo, in quanto sta solo sventando la persona tecnicamente meno esperta. È una misura scadente e il motivo per cui non hai trovato una soluzione esistente è che non è un buon approccio. È meglio passare il tempo ad implementare un sistema di autenticazione decente con una pista di controllo per una buona misura (e se questo è davvero quello che fai, contrassegna Gary's answer come corretto).

Quindi, per concludere in su:

1. Security di offuscamento non è sicurezza a tutti.
2. Non ci si può fidare dei dati utente , anche se sono oscurati. Validate your data.
3. Utilizzo di canali di comunicazione protetti (SSL) consente di bloccare altre minacce correlate.
4. Si si dovrebbe abbandonare il proprio approccio e fare la cosa giusta.La cosa giusta, nel tuo caso, probabilmente significa l'aggiunta di un meccanismo di autenticazione con un sistema di privilegio per impedire agli utenti di accedere cose non sono il privilegio di vedere - tra cui cose che potrebbero tentare di accesso da parte manomissione Ottieni parametri. Gary R's answer, così come il commento di Dave e Will ha colpito questo sulla testa.

Answer 2

È possibile codificare i dati utilizzando base64 o qualcosa di simile. Vorrei codificare gli argomenti presenti in JSON per serializzarli.

Answer 3

Se il tuo obiettivo è "ridurre la possibilità che un utente inattivo invii dati arbitrariamente", c'è un altro approccio più semplice che vorrei provare. Creare una chiave di crittografia privata e memorizzarla sul lato del server delle applicazioni. Ogni volta che la tua applicazione genera un url, crea un hash dell'URL usando la tua chiave di crittografia privata e inserisci l'hash nella stringa della query. Ogni volta che un utente richiede una pagina con parametri nell'URL, ricalcola l'hash e verifica se corrisponde. Questo ti darà la certezza che la tua applicazione ha calcolato l'url. Tuttavia lascerà leggibili i parametri della stringa di query. In pseudo-codice,

SALT = "so9dnfi3i21nwpsodjf"; 

function computeUrl(url) { 
    return url + "&hash=" + md5(url + SALT); 
} 

function checkUrl(url) { 
    hash = /&hash=(.+)/.match(url); 
    oldUrl = url.strip(/&hash=.+/); 
    return md5(oldUrl + SALT) == hash; 
} 

Answer 4

Qualcosa come jCryption?

http://www.jcryption.org/examples/

Answer 5

Se l'obiettivo è di prevenire gli URL "statici" di essere manipolati, allora si può semplicemente cifrare i parametri, o firmare. Probabilmente è "abbastanza sicuro" da virare su un MD5 dei parametri URL, insieme a un po 'di sale. Il sale può essere una stringa casuale memorizzata nella sessione, ad esempio.

allora si può solo:

http://example.com/service?x=123&y=Bob&sig=ABCD1324 

Questa tecnica espone i dati (vale a dire che possono "vedere" che xyz = 123), ma non può modificare i dati.

C'è un vantaggio di "crittografia" (e io uso questo termine liberamente). Qui è dove si cripta l'intera sezione dei parametri dell'URL.

Qui si può fare qualcosa di simile:

http://example.com/service?data=ABC1235ABC 

La cosa bella utilizzando la crittografia è duplice.

Uno protegge i dati (l'utente non può mai vedere che xyz = 123, ad esempio).

L'altra caratteristica tho è che è estendibile:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc 

Qui, è possibile decodificare il payload originale, e fare un (sicuro) si fondono con i nuovi dati.

Quindi, le richieste possono AGGIUNGERE i dati alla richiesta, basta non modificare i dati ESISTENTI.

È possibile eseguire lo stesso tramite la tecnica di firma, basta consolidare l'intera richiesta in un singolo "blob" e tale blob viene firmato in modo implicito. Questo è "efficacemente" crittografato, solo una debole crittografia.

Ovviamente non si vuole fare nulla di questo sul client. Non ha senso.Se puoi farlo, "loro" possono farlo e non puoi dire la differenza, quindi potresti anche non farlo affatto, a meno che tu non voglia "cifrare" i dati su una normale porta HTTP (vs TLS, ma poi la gente si chiederà saggiamente "perché preoccuparsi").

Per Java, tutto questo lavoro va in un filtro, è così che l'ho fatto. Il back-end è isolato da questo.

Se lo si desidera, è possibile rendere completamente isolato il back-end con un filtro in uscita che gestisce la crittografia/firma dell'URL in uscita.

Questo è anche quello che ho fatto.

Il lato negativo è che è molto impegnato a farlo bene e performante. È necessario un parser HTML leggero per estrarre gli URL (ho scritto un parser di streaming per farlo al volo in modo da non copiare l'intera pagina nella RAM).

Il lato positivo è tutto il lato contenuto "funziona", in quanto non ne sa nulla.

C'è anche un trattamento speciale quando si ha a che fare con Javascript (poiché il filtro non "saprà" facilmente dove c'è un URL da crittografare). Ho risolto questo problema richiedendo che gli URL fossero firmati per essere specifici "var signedURL = '....'", quindi li trovo facilmente nell'output. Non è un peso schiacciante per i designer come potresti pensare.

L'altro lato positivo del filtro è che è possibile disabilitarlo. Se si verifica un "comportamento strano", basta spegnerlo. Se il comportamento continua, hai trovato un bug relativo alla crittografia. Permette inoltre agli sviluppatori di lavorare in testo semplice e lasciare la crittografia per i test di integrazione.

Dolore da fare, ma nel complesso è bello alla fine.

Answer 6

Se si sta tentando di limitare l'accesso ai dati, utilizzare una sorta di meccanismo di accesso con un cookie che fornisce una chiave di autenticazione Single Sign On. Se il cliente invia il cookie con la chiave, può manipolare i dati in conformità con le autorità associate al proprio account (amministratore, utente pubblico, ecc.). Basta guardare Spring Security, CAS ecc per implementazioni di questo tipo in Java. I token forniti nel cookie sono solitamente crittografati con la chiave privata del server di emissione e sono generalmente a prova di manomissione.

In alternativa, se si desidera che l'utente pubblico (non autenticato) sia in grado di pubblicare alcuni dati sul proprio sito, tutte le scommesse sono disattivate. È necessario convalidare sul lato server. Ciò significa limitare l'accesso a determinati URI e assicurarsi che tutti gli input siano puliti.

La regola d'oro qui è non consentire tutto, tranne le cose che sai essere al sicuro.