I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio
drugomatera
drugomatera
il 17 marzo 2014 alle 17:35
404 messaggi dal 09 maggio 2012
Ciao Ragazzi ! ... vorrei confrontare con una delle vostre soluzioni ... qual'è il metodo più sicuro per creare e gestire una sessione utente. Il mio scenario, al quale sto lavorando, è semplicemente questo:

- l'utente tramite form viene autenticato e subito dopo viene creata una sessione con valore il suo ID prelevato da DB.

- nelle pagine protette vi è una sub che verifica l'esistenza della sessione. Se esiste la pagina viene caricata altrimenti si rimanda alla pagina di login

Ora vorrei sapere quanto sia sicuro questa procedura. Ad esempio, esiste la possibilità "dall'esterno" di riuscire a manipolare o a ricreare la sessione utilizzata ... e magari impostarli anche un ID ?

Vorrei che la mia applicazione fosse il più sicura possibile.
Avete dei consigli da applicare facilmente a questo paradigma? Grazie
Modificato da drugomatera il 17 marzo 2014 18.48 -
RispondiQuoting
BrightSoul
BrightSoul
il 18 marzo 2014 alle 20:05
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Francesco,
ASP.NET conserva le variabili di sessione lato server quindi l'utente non potrà alterarne i valori. In nessun caso potrà modificare l'ID che gli hai assegnato.

Quando ASP.NET crea una nuova sessione per l'utente, emette un cookie contenente solo un SessionID, che è una stringa alfanumerica generata casualmente.
Il browser restituirà il cookie ad ogni successiva richiesta, ed in questo modo ASP.NET può riconoscere l'utente.

Anche se il cookie di sessione può essere modificato, la sicurezza di questo sistema risiede nel fatto che è praticamente impossibile per un utente indovinare la stringa alfanumerica di qualcun altro per usarla nel proprio cookie.

Detto questo, non dovresti comunque usare le variabili di sessione per proteggere le tue pagine.
  • Il cookie di sessione non è persistente e quindi l'utente sarà obbligato a loggarsi di nuovo ad ogni apertura del browser
  • nelle pagine protette vi è una sub che verifica l'esistenza della sessione
    Se per qualche motivo questa sub non va in esecuzione (vuoi per un bug o perché hai dimenticato di eseguirla), allora la pagina sarà aperta anche ad utenti anonimi.


Una soluzione migliore consiste nell'usare la FormsAuthentication, che è integrata in ASP.NET e semplicissima da usare.
Funziona così: al login, dopo aver verificato che username e password sono corretti, emetti un cookie di autenticazione con questo metodo:
FormsAuthentication.RedirectFromLoginPage(NomeUtente, True)
il "True" sta ad indicare un cookie persistente, che sopravvive alla chiusura del browser.

Fatto questo, le tue pagine saranno automaticamente protette (non devi eseguire alcuna sub) se nel nodo system.web del web.config metti questo:
    <authentication>
      <forms loginUrl="~/paginaLogin.aspx">
      </forms>
    </authentication>
    <authorization>
      <deny users="?" />
    </authorization>

Vedrai che se provi ad accedere ad una pagina protetta quando sei sloggato, il browser ti reindirizzerà automaticamente alla pagina di login.

Nel nodo forms indichi il percorso della pagina di login, che sarà l'unica a non essere protetta. Le restanti, saranno inaccessibili dagli utenti anonimi grazie alla direttiva deny[i] del nodo authorization.

Infine, quando vuoi sloggare l'utente, invoca questo metodo e il cookie di autenticazione verrà rimosso.
FormsAuthentication.SignOut()


Qui altri articoli per esplorare le altre funzionalità della FormsAuthentication.
http://www.aspitalia.com/focuson/640/Speciale-Forms-Authentication-ASP.NET.aspx

ciao,
Moreno
Modificato da BrightSoul il 18 marzo 2014 20.08 -
Enjoy learning and just keep making
RispondiQuoting
drugomatera
drugomatera
il 18 marzo 2014 alle 21:00
404 messaggi dal 09 maggio 2012
Ho utilizzato questa procedura se nell'area protetta vi deve accedere un numero definito di utenti (ad esempio un area admin), quindi imposto nel web.config user e password e il discorso mi è chiaro.
In questo caso gli utenti sono registrati in un DB con ruoli diversi. Quindi deve essere effettuato un controllo prima e pertanto a questo punto una sub deve comunque esserci ... come si procede in questo caso ?
RispondiQuoting
BrightSoul
BrightSoul
il 18 marzo 2014 alle 21:09
11.886 messaggi dal 09 febbraio 2002
Contributi
Gli utenti non devono per forza trovarsi nel web.config. Quando l'utente clicca "Accedi" dalla pagina di login, tu raccogli il suo username e password e li cerchi nel database per verificare che siano validi. Se lo sono, invoca il FormsAuthentication.RedirectFromLoginPage.

Il primo parametro di questo metodo è il nome utente, ma tu puoi metterci il suo ID o qualsiasi altro valore ti sia utile ad identificarlo.

Nelle successive richieste, potrai rileggere il valore che hai passato come username da questa proprietà.
Page.User.Identity.Name


ciao,
Moreno
Modificato da BrightSoul il 18 marzo 2014 21.10 -
Enjoy learning and just keep making
RispondiQuoting
drugomatera
drugomatera
il 21 marzo 2014 alle 21:09
404 messaggi dal 09 maggio 2012
Ciao Moreno, il problema è questo. Nella mia applicazione esiste già una path protetta con autenticazione basata su form. Nel web config ho inserito i soli utenti autorizzati ad accedervi etc ... tutto ok.
Adesso ho un'altra path da proteggere sempre nella stessa applicazione ma con un form di login differente. Purtroppo pare che l'applicazione gestisca solo un form di login. Ho questo errore:

Messaggio di errore del parser: Non è possibile utilizzare una sezione registrata come allowDefinition='MachineToApplication' al di sotto del livello di applicazione. L'errore può essere dovuto alla presenza di una directory virtuale non configurata come applicazione in IIS.


Questo è il web.config con l'aggiunta della nuova path da proteggere

<location path="g-comm">
        <system.web>
            <authentication mode="Forms">
                <forms name=".formComm" protection="All" path="g-comm" loginUrl="g-login.aspx">
                    
                </forms>

            </authentication>
            <authorization>
                <deny users="?" />
            </authorization>
        </system.web>

    </location>


Come posso procedere? Grazie
RispondiQuoting
BrightSoul
BrightSoul
il 21 marzo 2014 alle 23:20
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao Francesco,

drugomatera ha scritto:

Adesso ho un'altra path da proteggere sempre nella stessa applicazione ma con un form di login differente.

Il fatto che esistano due form di login differenti mi fa pensare che questa non sia un'unica applicazione, ma due applicazioni distinte che potresti configurare come tali all'interno di un sito IIS.
http://technet.microsoft.com/en-us/library/cc772042(v=ws.10).aspx
A quel punto, le due applicazioni possono avere una propria configurazione per la forms authentication.

Se comunque preferisci mantenere i due form di login all'interno della stessa applicazione, potresti provare con questo overload di SetAuthCookie, che ti lascia indicare l'ambito di validità del cookie.
Nell'ultimo parametro, la path, puoi scrivere ad esempio "/g-comm" per fare in modo che il browser usi quel cookie solo quando l'utente naviga in pagine situate nella sottocartella /g-comm.

In questo modo l'utente, se si autentica da entrambe le form, disporrà di due cookies di autenticazione che saranno ben isolati tra loro grazie alle path distinte.

Se decidi di seguire questa strada poi dimmi se funziona, è una cosa che non ho mai provato :)

ciao,
Moreno
Modificato da BrightSoul il 21 marzo 2014 23.21 -
Enjoy learning and just keep making
RispondiQuoting

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.