Crittografia URL e codifica

Question

Crittografia URL e codifica

#1 da (4 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Al momento le informazioni non sensibili / semi-sensibili vengono inviate da una pagina all'altra tramite GET sulla nostra applicazione web. Come ID utente o numero di pagina richiesto ecc. A volte vengono trasmesse informazioni leggermente più sensibili come il tipo di account, i privilegi dell'utente ecc.

[EDIT: potrei averlo scritto male, non sto passando sessionID o effettivi privilegi utente, solo semplici dati NON-sensibili - Non voglio che l'utente veda le parole facilmente, non importa se un un utente più tecnico può leggerlo poiché non può fare alcun danno e causare problemi di sicurezza. leggi la chat con @delnan ]

Al momento utilizziamo base64_encode () e base64_decode () solo per disumanizzare le informazioni in modo che l'utente finale non sia interessato.

È buona pratica o luogo comune in cui un URL deve essere crittografato anziché semplicemente PHP base64_encoded?

Forse usando qualcosa di simile, questo:

$encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));

$decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($encrypted), MCRYPT_MODE_CBC, md5(md5($key))), "$encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));

$decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($encrypted), MCRYPT_MODE_CBC, md5(md5($key))), "%pre%");
");

È troppo o troppo affamato di qualcosa di così comune come l'URL GET.

programming-practices php encryption efficiency text-encoding

posta hozza 31.03.2012 - 14:40

fonte

3 risposte

Leggi altre domande sui tag programming-practices php encryption efficiency text-encoding

Gestisci le stringhe di query nei metodi JDBC Approccio ingegneristico per l'architettura basata sui metadati

score 4 · Answer 1

Perché stai usando GET in primo luogo? Basta caricare i dati sensibili su HTTPS e aggiungere una protezione CSRF adeguata.

Si presume che l'informazione sia sensibile nel senso che l'utente autorizzato e il server possono vederla, ma altri (altri utenti e autori di attacchi) non devono.

Se l'utente non è autorizzato a vedere le informazioni, quindi non inviarlo in primo luogo. Tenerlo sul server; se è necessario collegarlo all'utente, passare un ID sessione avanti e indietro (con le consuete precauzioni e misure di sicurezza in vigore) e memorizzare le informazioni sensibili nella sessione (cioè lato server).

L'invio di informazioni riservate a un client non autorizzato è trascurato, perché offre all'aggressore un'opportunità per i metodi di cracking off-line.

score 0 · Answer 2

0

Se passi solo UserID qualcosa come Numero di pagina, allora solo URL GET va bene. Se non hai bisogno di alcuna protezione esplicita su di loro, sarebbe un overhead per te.

risposta data 31.03.2012 - 14:45

fonte

score 0 · Answer 3

Passare informazioni in questo modo è un rischio in attesa di essere sfruttato. Devi pensare su ciò che qualcuno che ha capito il traffico potrebbe fare al sito che sta accettando il GET.

Dovresti usare POST
Se vengono trasmessi dati sensibili, devono essere crittografati.
Dovresti eseguire il checksum e firmare il pacchetto di dati in modo che non possa essere modificato e pacchetti simili non possono essere costruiti.