Ha senso hash un id di sessione prima di passarlo a un partner pubblicitario?

Question

Ha senso hash un id di sessione prima di passarlo a un partner pubblicitario?

#1 da (10 voti)
#2 da (0 voti)

16

La mia azienda gestisce un negozio online. Collaboriamo con un partner che offre buoni sconto ai nostri clienti dopo l'acquisto (i buoni possono essere utilizzati in altri negozi online) e offre anche buoni per il nostro negozio ai clienti di altri negozi. A tale scopo, il partner ci chiede di inviare loro alcuni dati sui nostri clienti e il loro rispettivo ordine sulla nostra pagina di pagamento completa. Vogliono che lo facciamo impostando alcune variabili javascript e includendo un javascript dal loro server, che mostrerà anche un banner pubblicitario sulla nostra pagina di pagamento completa.

Ho già imparato che compresi gli annunci pubblicitari i banner sono a rischio . Sembra che la nostra azienda abbia già preso la decisione di accettare questo rischio per questo partner.

Ora sono preoccupato per un particolare punto. I dati che il partner vuole che inviamo includono anche l'ID di sessione del nostro cliente, al fine di "riconoscere le doppie richieste" come afferma il partner. Penso che non dovremmo inviare l'ID di sessione reale al partner, perché con queste informazioni il partner potrebbe falsificare l'identità del cliente sul nostro sito. Pertanto, vorrei inviare un hash dell'ID di sessione. Con questo, il partner dovrebbe essere ancora in grado di riconoscere le doppie richieste senza essere in grado di simulare l'identità del cliente.

Ha senso? Oppure il partner, dal fatto che includiamo un javascript dal proprio server, ha già modi per fare più danni di quanto potrebbe fare conoscendo l'ID della sessione? Memorizziamo l'ID di sessione in un cookie HttpOnly (per la connessione tra il nostro server e il nostro cliente).

Se ha senso cancellare l'id della sessione, quale funzione di hash sarebbe una buona scelta?

javascript web-application attacks session-management

posta user26315 23.05.2013 - 10:27

fonte

2 risposte

0

È possibile generare facilmente un "token di sessione" diverso da pubblicare per l'inserzionista e inserire tale token nell'archivio di sessione standard. In. Net, qualcosa di semplice come:

void Session_Start(object sender, EventArgs e) 
{
   // assign a random GUID for the ad partner
   Session["AdToken"] = Guid.NewGuid().ToString();
}

Successivamente, puoi ottenere il valore da distribuire con <%=(string)Session["AdToken"]%> (per le pagine ASPX).

risposta data 30.05.2013 - 20:18

fonte

Leggi altre domande sui tag javascript web-application attacks session-management

Qualcuno ha davvero inserito un iphone o sono questi i sintomi di un tentativo di exploit? Mailing list crittografata con GPG e altri approcci alla comunicazione sicura

score 10 · Accepted Answer

Sì, quello che dici ha un senso.

Impostando il tuo cookie come un HttpSolo cookie , stai mitigando il rischio che il JavaScript del tuo partner abbia accesso all'ID di sessione dell'utente. Dal momento che il tuo partner insiste per ottenere un identificatore univoco per i tuoi clienti, non vedo nulla di sbagliato nell'invio di una versione hash sicura dell'ID di sessione.

Il punto chiave qui è che tu non usi la versione hash dell'ID di sessione come identificatore, quindi il tuo partner non sarà in grado di usarlo per impersonare i tuoi clienti, ma a allo stesso tempo, la versione hash è abbastanza unica da consentire al tuo partner di riconoscere i tuoi clienti.

Per quanto riguarda l'hashing, non importa quale algoritmo di hashing usi, purché la sua lunghezza di uscita sia uguale o superiore all'ID di sessione. In questo caso, ovviamente, devi usare un sale fisso (un pepe) sempre perché vuoi che lo stesso ID di sessione produca lo stesso hash.