problema di protezione accesso area riservata

[micR]

Sto creando per un nuovo sito una sezione clienti ad accesso limitato,
protetta tramite login.
Il metodo che vorrei usare per la protezione (con ASP) funziona andando a prelevare
username e password da un database, confrontando i dati inseriti nella pagina di login
con la lista degli utenti presenti nel database.
Il codice ASP che dovrei usare è più o meno questo:

.....
sql="SELECT * FROM tabella_login WHERE user='" & Replace(username,"'","''") & "' AND _
password='" & Replace(password,"'","''") & "'"
Set RecordsetDB = ConnessioneDB.Execute (sql)

If Not RecordsetDB.EOF AND Not RecordsetDB.BOF then
'utente riconosciuto
Session("UtenteRiconosciuto")="OK"
Response.Redirect("paginariservata.asp")
Else
'utente non riconosciuto
Response.Redirect("errore.asp")
End If
......

Nella pagina riservata la protezione invece funziona così: nell'intestazione

If Session("UtenteRiconosciuto")<>"OK" Then
Response.Redirect("login.asp")
End If
......

Quello che ora vorrei chiedervi è un parere sul grado di sicurezza e affidabilità di questo
sistema di protezione... se và migliorato, se và scartato completamente, o se ha qualche
bug innato... ecc.
Grazie per la collaborazione....

[steno12]

Se è solo un pare che vuoi:

usando la session nel global.asa, nessuno può andare sulla pagina riservata, se non si logga con username e password, in quanto anche digitando l'indirizzo della pagina riservata, verrebbe redirecto alla pagina del login.

Il sistema è sicuro e affidabile.

L'unica cosa è eseguire il download del db, all'indirizzo dove esso risiede, e aprendolo, avere le pws e id a disposizione. Per questo motivo è sempre opportuno munire il db di password, per accedervi.

[micR]

infatti il db è protetto in una cartella in cui se si tenta di accedere da errore 403:forbidden..
ma quello che mi chiedo... non ci sarà qualche magagnetta che permetta comunque il login...
grazie cmq

[Maldito]

Un minimo di sicurezza c'è... però ricorda che tutto ciò da la possibilità all'utente di inserire qualcosa che va poi ad essere eseguito ( mi spiego meglio: il nome utente che va a finire nella query se viene "ripulito" solo degli apicetti può essere utilizzato per incularti... per esempio effettuando una query nidificata che crei tramite un sottoinsieme un record fittizio...blabla )

comunque... il discorso verte sul fatto che per aumentare questa sicurezza devi controllare le dimensioni dei campi in ingresso, intercettare anche i doppi apici, le parentesi e i codici char() corrispondenti.

ciao ciao

[sebamix]

Originariamente inviato da steno12
Per questo motivo è sempre opportuno munire il db di password, per accedervi.

Non è affatto opportuno se il db è Access.
La password di un db access si ricava in pochi secondi.
La soluzione migliore è appunto disabilitare il listing della cartella dove risiede il db (anche se uno, facendo delle prove) può riuscire a scaricarlo comunque se riesce a ricavarne l'indirizzo esatto.
Comunque vedo che hai evitato un minimo di SQL injection (username = ' or '' = ' :quipy: ).
Quello che non so dirti è se comunque le variabili di sessione sono sicure (IMHO dovrebbero essere cookies).

[micR]

grazie per le vostre risposte... in effetti i miei dubbi erano proprio su eventuali "sql injection" ... e che le variabili di sessione non sono altro che dei cookies...
per quanto riguarda la cartella del db questa è protetta dallo scaricamento (da errore 403_forbidden), salvo se non c'è qualche altra magagnetta per eludere le protezioni di IIS...
a questo punto come potrei migliorare la protezione da cosiddette sql injection (doppi apici, char...) c'è quelche sito a cui attingere info?
oppure il metodo non è proprio da usare?
queste cose microsoft sono piene di bugs...