Quanto è valido convalidare la fonte con request.referer di checksum?

2

Ho 2 portali (entrambi sono sotto il mio controllo e i nomi di dominio sono diversi)

Nel primo portale, c'è un link sul clic di cui l'utente può accedere direttamente al secondo portale.

Il collegamento che verrà colpito nel primo portale per accedere al secondo portale è simile a quanto segue (Its a GET)

https://SecondPortalDomain/someServlet?param1=base64Encoded

Questo URL presenta problemi come può essere memorizzato nella cache e aggiunto ai segnalibri. Inoltre, se un utente non viene autenticato nel mio 1 ° Portal, ma preme sopra l'URL direttamente, può anche accedere (contro il mio desiderio).

Quindi, sto pensando di mettere un assegno usando Referente . Se l'URL di origine è così e così quindi consentire solo il login.

Quanto è strong l'utilizzo di Referer rispetto alla verifica del checksum tra sorgente e target? Referer è un valore controllato dal cliente e può quindi essere parodizzato a qualcosa di completamente diverso o addirittura rimosso. Ma, anche un valore di checksum può essere studiato e falsificato.

    
posta Vikas V 30.04.2013 - 06:26
fonte

3 risposte

1

Hai ragione che l'intestazione del referrer può essere facilmente falsificata o completamente mancante. Esistono plug-in del browser che bloccano l'invio del referrer, quindi se aggiungi un controllo sul referrer, dovresti impedire agli utenti di utilizzare tali plug-in dal tuo sito.

Un'opzione migliore sarebbe che il primo portale generasse un token casuale lungo per ciascun utente e in qualche modo condividesse quel token con il secondo portale. Quindi il portale 1 mostra all'utente un collegamento che include il token come parametro, ad esempio https://SecondPortalDomain/someServlet?token=13a82b00-b17e-11e2-9e96-0800200c9a66 . Hai a disposizione molte opzioni su come i portali potrebbero condividere il token - ad esempio potrebbero condividere un database, o il portale 1 potrebbe inviarlo al portale 2 tramite SOAP o un post RESTful.

Se questa opzione non funziona per te, allora un'altra alternativa sarebbe fare qualcosa in base al tempo. Portal 1 potrebbe crittografare l'ora corrente e usarlo come token in un collegamento al portale 2. Quindi il portale 2 lo decodificherebbe e controllerà se l'ora dal token è stata negli ultimi 10 minuti (o quale sia la tolleranza desiderata).

    
risposta data 30.04.2013 - 12:25
fonte
0

Non fidarti affatto dei referenti. Come hai giustamente sottolineato, possono essere facilmente falsificati e sono quindi risibili come una "misura di sicurezza".

Implementare una sorta di meccanismo di single-sign-on tra i due portali. Una soluzione semplice come un token a tempo limitato sarebbe altamente raccomandata per questo tipo di funzionalità.

Se i tuoi portali condividono infrastrutture comuni o servizi applicativi, le funzionalità SSO sono disponibili in molte delle popolari piattaforme applicative, link o < a href="http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Setting_up_single_sign-on_for_WebSphere_Application_Server"> link per un esempio.

    
risposta data 30.04.2013 - 12:30
fonte
0

In generale , Non fidarti di alcuna cosa (intestazioni, modulo nascosto, convalida, ecc.) Che dipendono dal browser (lato client)

usa Burpsuite, WebScarab o qualsiasi altro proxy per intercettare la tua richiesta, vedrai quanto è pericoloso.

Puoi immaginare che se la tua autorizzazione dipende da "referer" e l'utente cambia il refere a quello valido durante la navigazione, otterrà l'autorizzazione che non è quello che stai cercando.

semplice regola? l'utente è il tuo nemico.

Questo link è utile - (OWASP)

link

    
risposta data 02.05.2013 - 14:24
fonte