Codifica / Obfuscate HTTP parametri

Question

Al momento stiamo lavorando su un semplice Webapp, e vorremmo "offuscare" (quale sarebbe il termine giusto?) O codificare in qualche modo il parametro di richiesta, in modo che possiamo ridurre il rischio un utente di inattività di inviare i dati arbitrariamente.

Per esempio, gli sguardi URL tipo /webapp?user=Oscar&count=3

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

Prima di entrare nei implementare qualcosa di simile a noi stessi (e probabilmente facendo male) vorrei sapere se c'è qualcosa da fare questo già?

Abbiamo Java sul server e JavaScript sul client.

Answer 1

No, non farlo. Se si può costruire qualcosa nel codice del client di offuscare i dati che vengono trasmessi al server, poi così può un hacker intenzionale. Semplicemente non è possibile i dati di fiducia di essere inviati al server, non importa quale sia il vostro client ufficiale fa. Stick a fughe di dati del cliente e la convalida contro una whitelist sul lato server . Usa SSL, e se è possibile, mettere i parametri di richiesta in un POST invece di GET.

Ampliamento modifica

Il tuo confusione nasce 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 coinvolgono usando una combinazione di autenticazione, privilegio e la gestione delle sessioni, audit trail, la convalida dei dati, e di canali di comunicazione sicuri.

Utilizzo di SSL non impedisce al client di manomissione dei dati, ma non evitare che gli intermediari di vedere o manomissione con esso. Si incarica anche i browser ben educati a non memorizzare nella cache i dati sensibili nella storia URL.

Sembra di avere una sorta di semplice applicazione web che non ha l'autenticazione, e passa intorno parametri della richiesta che la controllano direttamente nel GET, e quindi alcune persone non smaliziati probabilmente potrebbe accorgersi che user=WorkerBee può essere semplicemente modificato per user=Boss nella loro barra del browser, e quindi possono accedere ai dati per non vedere, o fare cose che non dovrebbero fare. Il vostro desiderio (o il desiderio del cliente) per offuscare quei parametri è ingenuo, in quanto è solo andare a sventare la persona meno smaliziati. Si tratta di una misura di cotto a metà e la ragione per cui non hai trovato una soluzione esistente è che non si tratta di un approccio buona . È meglio spendere tempo l'implementazione di un sistema di autenticazione decente con un audit trail per buona misura (e se questo è davvero quello che fai, marchio risposta di Gary come corretto).

Quindi, per concludere in su:

1. Security di offuscamento non è sicurezza a tutti.
2. Non ti puoi fidare i dati degli utenti, anche se è oscurato. Convalida i dati .
3. Utilizzo di canali di comunicazione sicuri (SSL) aiuta bloccare altre minacce correlate.
4. dovrebbe abbandonare il vostro approccio e fare la cosa giusta. La cosa giusta, in il vostro caso, probabilmente significa aggiungere un meccanismo di autenticazione con un sistema di privilegi per gli utenti Impedire l'accesso cose che non sono il privilegio di vedere - compreso cose che potrebbero tentare di accesso da parte manomissione parametri GET. Gary risposta di R, così come Dave e la volontà di commentare colpo questo uno sulla testa.

Answer 2

Se il vostro obiettivo è quello di "ridurre la possibilità di un utente di inattività di inviare arbitrariamente i dati," c'è un altro approccio più semplice che vorrei provare. Fai una chiave di crittografia privata e conservarlo nel vostro lato server applicazioni. Ogni volta che l'applicazione genera un URL, creare un hash del URL utilizzando la chiave di crittografia privata e mettere quella hash nella stringa di query. Ogni volta che un utente richiede una pagina con i parametri nell'URL, ricalcolare l'hash e vedere se corrisponde. Questo vi darà una certa sicurezza che l'applicazione calcola l'url. Lascerà i parametri di stringa di query però leggibile. 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 3

Se si sta cercando di limitare l'accesso ai dati quindi utilizzare un qualche tipo di meccanismo di login con un cookie che fornisce un Single Sign On chiave di autenticazione. Se il client invia il cookie con la chiave allora possono manipolare i dati in accordo con le autorità associati con il proprio account (admin, utente pubblico, ecc). Basta guardare Primavera di sicurezza, CAS ecc per facile da usare implementazioni di questo in Java. I token forniti nel cookie di solito sono cifrati con la chiave privata del server di emissione e sono a prova di manomissione in genere.

In alternativa, se volete che il vostro utente pubblico (non autenticato) per essere in grado di inviare alcuni dati al vostro sito, tutte le scommesse sono spenti. È necessario convalidare sul lato server. Questo significa che limitano l'accesso ad alcuni URI e fare in modo che tutti gli input viene pulita.

La regola d'oro è qui respingere tutto, tranne cose che conosci è sicuro.

Answer 4

Se l'obiettivo è di prevenire gli URL "statici" di essere manipolato, allora si può semplicemente cifrare i parametri, o firmare. E 'probabile "abbastanza sicuro" per virare su un MD5 dei parametri URL, insieme ad un pizzico di sale. Il sale può essere una stringa casuale memorizzato nella sessione, dice.

Poi si può semplicemente:

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

Questa tecnica espone i dati (cioè esse possono "vedere" che xyz = 123), ma non possono modificare i dati.

C'è è un vantaggio di "cifratura" (e uso questo termine in senso lato). Questo è dove si crittografare l'intera sezione di parametro dell'URL.

Qui si può fare qualcosa di simile:

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

La cosa bella utilizzando la crittografia è di due volte.

Una protegge i dati (non utente può mai vedere che xyz = 123, per 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, solo che non cambia i dati esistenti.

Si può fare lo stesso tramite la tecnica di firma, si sarebbe solo bisogno di consolidare l'intera richiesta per un unico "blob", e che è implicitamente blob firmato. Che sia "efficace" criptati, solo una crittografia debole.

Ovviamente non si vuole fare nulla di tutto questo sul client. Non ha senso. Se si può fare, "loro" possono farlo e non si può dire la differenza, quindi potrebbe anche non farlo a tutti - a meno che non si vuole crittografare i dati "" nel corso di un normale porta HTTP (vs TLS, ma poi la gente sarà saggiamente chiedersi "perché preoccuparsi").

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

Se si desidera, è possibile effettuare il back-end completamente isolato dal questo con un filtro in uscita che la crittografia maniglie l'URL / firma sulla via d'uscita.

Questo è anche quello che ho fatto.

Il lato negativo è che è molto coinvolto per farlo bene e performante. Hai bisogno di una luce parser HTML peso a tirare fuori gli URL (ho scritto un parser in streaming per farlo al volo in modo che non ha copiato l'intera pagina in RAM).

Il lato positivo è tutto del lato contenuti "solo opere", in quanto non sanno nulla al riguardo.

C'è anche un po 'di un trattamento speciale quando si tratta di Javascript (come il filtro non sarà facile "sapere" dove c'è un URL per crittografare). Ho risolto questo richiedendo gli URL per essere firmato per essere precisi "var signedURL = '....'", in modo da poter trovare quelli facilmente in uscita. Non come la frantumazione di un onere per i progettisti come si potrebbe pensare.

L'altro lato positivo del filtro è che si può disabilitarlo. Se avete un po ' "strano comportamento" accadendo, semplicemente spegnerlo. Se il comportamento continua, di aver trovato un bug relativo alla crittografia. E lasciare che anche gli sviluppatori lavorano in testo normale e lasciano la crittografia per test di integrazione.

Il dolore da fare, ma è bello nel complesso, alla fine.

Answer 5

Qualcosa di simile jCryption?

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

Answer 6

Si può codificare dati utilizzando base64 o qualcosa di simile. Vorrei codificare gli argomenti inself in JSON per serializzare loro.