Condivisione del sistema di accesso tra ASP classico e ASP.Net

Question

Un client utilizza ASP classico per accedere al proprio backoffice basato sul Web.

Ho scritto una nuova app ASP.Net da includere nel backoffice, e ho bisogno di utilizzare il sistema di login già esistente, in modo che quando sono loggati lì, non hanno bisogno di accedere di nuovo nella nuova app ASP.Net.

Gli accessi e le password vengono archiviati come testo in chiaro in un db di SQL Server, a cui posso accedere dalla mia app ASP.Net.

Quale sarebbe un modo efficace per integrare questi sistemi?

La mia migliore idea attuale è: Nel collegamento alla mia app ASP.Net, collego a una pagina di accesso "gateway" con i loro userid e una password hash + common secret nella querystring. Paragone quindi con la password dell'utente nel database ... Ma il problema è che, se questa querystring viene intercettata, può essere utilizzata per accedere al sito asp.net, senza conoscere effettivamente il nome utente e la password ...

Sono molto probabilmente trascurato qualcosa di semplice.

Answer 1

Penso che la tua idea sia sulla strada giusta.

Come probabilmente già saprete, asp classico e asp.net non possono condividere lo stesso stato di sessione, quindi è necessario disporre di un meccanismo per accedere da uno all'altro.

Cosa farei: quando qualcuno effettua l'accesso, crea un GUID univoco che si salva nel database per quell'utente. Quando si passa da un sito all'altro, passare tale GUID nella stringa di query. Quando si tenta di eseguire il log automatico nell'altro sito, cercare tale GUID e verificare se è collegato a chiunque. Se lo è, collegali.

In questo modo non stai passando nulla che un utente possa indovinare o decodificare.

Answer 2

In che modo il sistema ASP classico mantiene lo stato di accesso? "Piggy-backing" sarebbe la soluzione migliore, di gran lunga.

Tutti i sistemi ASP classici su cui ho lavorato hanno utilizzato i cookie per tracciare le informazioni di autenticazione, quindi basta leggerli e confrontarli con il database a cui è possibile accedere.

---

Come le informazioni sono memorizzate in una sessione Classic ASP, è possibile aggiungere una "pagina redirect" verso il lato ASP classico di cose che è il "ingresso" al nuovo modulo, e causare questo per scrivere il dati utili come cookie o attivare un POST alla tua pagina iniziale? Utilizzando i cookie o una richiesta POST, si riduce al minimo la preoccupazione di avere l'URL "dirottato" che consente a qualcuno di accedere al sito ASP.net senza nome utente/password.

Answer 3

Non potresti inviarlo tramite Modulo e non tramite Querystring? Ciò eliminerebbe la possibilità che venga intercettato nell'URL.

Answer 4

Se l'intercettazione è un problema grave, è necessario eseguire il sito su HTTPS. In caso contrario, l'utilizzo di UserID + Nonce che viene quindi sottoposto a hashing tramite la password è ragionevolmente forte.

In alternativa, è possibile ottenere l'applicazione ASP per aggiungere un cookie di sessione GUID dopo aver effettuato l'accesso e archiviare tale GUID in una tabella DB. ASP.NET può cercare il GUID dal cookie per vedere se l'accesso è stato raggiunto. Se si include il valore del cookie della sessione ASP nella tabella, è possibile essere ragionevolmente sicuri che la sessione ASP corrente sia la stessa sessione utilizzata al momento della creazione del GUID.

Answer 5

Sei giustamente preoccupato per un attacco di tipo MITM, probabilmente tramite avvelenamento della cache DNS o simili. A seconda delle circostanze, potrebbe essere sufficiente attenuare i potenziali effetti di ciò aggiungendo un vincolo temporale al token di accesso che viene passato attraverso i limiti dell'applicazione.

Il "GUID nell'approccio al database" è qualcosa che ho utilizzato con successo in passato, sia per il passaggio degli utenti tra due applicazioni che condividono lo stesso database di autenticazione, sia per gli scenari di tipo "reimpostazione della password". Si potrebbe "scadere" con una colonna aggiuntiva sul record che specifica la data in cui è stato aggiunto il GUID e modificando il codice dell'applicazione per accedere solo agli accessi GUID che sono meno di x minuti/ore/giorni.

Un'alternativa potrebbe essere quello di evitare ulteriori campi del database concatenando qualcosa come:

UserId + [Value representing current time to nearest x minute/hour /day] + Salt 

.. hashing, quindi poi duplicare il vostro algoritmo sul l'altra applicazione e confrontando i due valori generati.

In generale, penso che la soluzione proposta sia appropriata al problema. Non è certamente troppo complicato.