Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1

    [php] identificazione univoca del browser

    Sono alla ricerca di un modo per assicurarmi che l'utente che accede sia sempre lo stesso, in altre parole voglio assicurarmi che nessun altro provi a usare lo stesso ID di sessione per ereditare le credenziali di accesso.

    Premessa: il livello di sicurezza che cerco è definibile come 'paranoico' per il semplice motivo che verrebbe usato in un software gestionale scritto in php e pubblicato su internet, per cui la sicurezza sarebbe un problema decisamente cruciale.

    ora le alternative sono:
    - tenere traccia dell'ip dell'utente nella sessione. Non accettabile, c'è troppo rischio di falsi positivi e falsi negativi (gente che naviga dietro router/proxy/proxy anonimi/TOR)

    - tenere traccia dello user agent. Non accettabile. E' abbastanza facile che due persone usino lo stesso browser sullo stesso sistema operativo. E non è neanche così difficile riuscire a rilevare lo user agent di un qualunque utente (basta fargli visitare una qualunque pagina preparata ad-hoc)

    - qui si dice di salvare una firma del tipo md5('user-agent'.'stringa segreta') e poi passare questa stringa tramite POST e/o tramite GET, e confrontarla con quella nella sessione.
    Ma ho dei dubbi sulla efficacia, per due motivi: finchè la stringa è basata sullo user agent, sarà sempre uguale anche per altri utenti con lo stesso user agent.
    Inoltre non credo sia così impossibile riuscire a "farsi mandare" e/o "carpire" questa stringa a un altro utente.

    - Uso di mod_unique_id (modulo di apache)
    Trattasi di un id casuale generato a ogni pagina da apache.
    sarebbe bello, peccato sia senza memoria. Quindi dovrei salvarlo ogni volta nella sessione e nella pagina e confrontarlo, con il rischio che venga sgamato. D'accordo che è monouso, ma il rischio cmq c'è.
    A meno che non ci sia un modo più furbo di usarlo, che al momento mi sfugge.

    - invio di una qualunque stringa casuale da confrontare con quella salvata nella sessione (vedi sopra per i problemi).

    Il punto è che nessuno di questi sistema mi piace, per cui vorrei trovare un modo più sicuro.
    L'ideale penso sia una signature generabile ogni volta combinando gli header che arrivano dal browser, in modo che possano essere calcolati e confrontati per ogni singola pagina senza far viaggiare nessuna stringa avanti e indietro tra browser e server, ma rimane il problema che due persone con lo stesso browser generano la stessa stringa ..

  2. #2
    Forse sono superficiale io, ma ti dico quello che penso... Secondo me dovresti affrontare il problema più a livello sistemistico che non di programmazione web. Io penso che già HTTPS sia abbastanza sicuro (il totalmente sicuro non esiste), ma se credi potresti anche fare un sistema in Tunneling con VPN o simili (non sono un eperto), quindi il server gestisce gli accessi riconoscendo proprio il pc con le varie chiavi pubbliche private etc... Poi fai un sistema di login al programma, magari con captcha ed a quel punto sei abbastanza tranquillo. Dovrebbero riuscire ad entrare sulla VPN (e non è cosa semplicissima) o dovrebbero avere accesso proprio ad un computer predisposto per la VPN... Per esperienza, a parte gli attacchi esterni, le maggiori cag**e le vedi fatte all'interno del sistema. Noi ci si sbatte per rendere password sicure, e poi loro le lasciano in vista sul browser o nei programmi, quindi non ti ammazzare perchè non serve! Cmq per una sicurezza altissima VPN e simili con controllo da firewall per accesso sul server, poi HTTPS e password al software.
    Di più non so...
    Ciao
    Rino

  3. #3
    HTTPS lo uso già, e quando posso uso anche i certificati per guadagnarsi l'accesso.

    Il problema nasce ora con il fatto che ho gente che vuole potersi collegare anche dagli internet point, per cui sia portarsi dietro il certificato che collegarsi a una VPN sono operazione scomode e rischiose.

    E' questo il motivo per cui stavo cercando un metodo per rendere più sicuro il codice.

    Confido anch'io nel fatto che HTTPS sia già abbastanza sicuro, ma proprio per il motivo che la gente deve poter accedere anche da pc pubblici vorrei per lo meno evitare problemi di session hijacking e session fixation.

    E una volta che trovo un buon metodo per identificare il browser posso ritenermi più tranquillo.

    E' chiaro che se poi sul pc c'è un keylogger allora siamo punto a capo .. per questo però non si può fare altro che incrociare le dita :-(

  4. #4
    ma quanti utenti possono entrare? se sono un numero limitato puo fornire di un sistema "portable" su chiave USB da dove leggi qualche file e quindi solo chi ha quella chiave può entrare... Potrebbe essere una idea no? Poi non saprei bene come svilupparla e neanche se si può... bisognerebbe vedere se possibile far leggere al browser un file (su IE si, ma mozilla o Opera?)

  5. #5
    far leggere il file non sarebbe un problema in qualsiasi browser, ma al momento non mi stavo preoccupando dell'autenticazione in sè, quanto di come evitare problemi con la sessione. Se qualcuno riuscisse a fregare l'id di sessione di un utente già autenticato ogni tentativo per rendere più robusta possibile l'autenticazione sarebbe inutile ..

    Cmq leggendo in giro pare che l'unico modo attendibile sia salvare nella sessione l'md5 di una combinazione degli header inviati dal browser, che possono essere ricalcolati ogni volta, in combinazione all'id di sessione salvato in un cookie e stringhe random passate via GET.

    A questo punto per fare il session hijacking è necessario passare gli stessi header, leggere i cookie e vedere se viene passata qualche stringa tramite GET. L'unione di queste 3 cose dovrebbe essere abbastanza complicata.

    Oltre ad altre astuzie come inizializzare la sessione solo dopo che la procedura di login è stata effettuata e solo dopo aver rigenerato l'id di sessione, per bloccare tentativi di session fixation.

    se trovo qualcosa di risolutivo lo posto qui in ogni caso

    in ogni caso grazie per l'attenzione :-)

  6. #6
    io però intendevo dire che ad ogni passaggio rileggi il file con il codice che magari cambia di volta in volta, quindi è come se ti logassi ogni pagina, ma lo fa lui in automatico. Poi non so...
    Facci sapere però cosa farai!

  7. #7
    Utente di HTML.it L'avatar di kodode
    Registrato dal
    Sep 2002
    Messaggi
    1,896
    ciao, avrei +o- lo stresso problema, hai risolto? io pensavo anche di registrare qualche parametro univoco della macchina usata... ma nn ho idea di come si fa
    se riesci ad aiutarmi!!! grazie

  8. #8
    io fare session_id random con hash di una stringa confrontandola con qualcosa che proviene dal browser tipo ip e useragent secondo me hai già un buon livello di sicurezza poi se sei dentro un https .. tecnicamente sei protetto nel tunnel ssl

    il massimo se fosse possibile sarebbe un codice basato sul seriale del disco rigido ma php non centra nulla dovrebbe essere tipo una chiave software fatta per lanciare le pagine php

  9. #9
    Originariamente inviato da ringo_mato
    io fare session_id random con hash di una stringa confrontandola con qualcosa che proviene dal browser tipo ip e useragent secondo me hai già un buon livello di sicurezza poi se sei dentro un https .. tecnicamente sei protetto nel tunnel ssl

    il massimo se fosse possibile sarebbe un codice basato sul seriale del disco rigido ma php non centra nulla dovrebbe essere tipo una chiave software fatta per lanciare le pagine php
    sono idee mezze buone, ma solo a metà.

    Premetto che lo scopo delle mia paranoie è evitare problematiche di session hijacking e session fixation, che sono ben più subdole e insidiose di semplici tentativi di sniffare nome utente e password (per evitare questo basta SSL).

    l'ip può essere comune a più utenti (vedi pc dietro a un nat o gli utenti fastweb che escono un ip unico) oppure può variare durante la connessione (alcuni provider a volte lo fanno, ma sono pochi).

    gli header inviati dal browser invece possono essere sniffati (basta che ti faccio visitare una mia pagina).

    Https sicuramente è una cosa in più ed è molto robusto, ma se riesce a fare una code injection un estraneo riesce comuqnue a leggere i cookie e altra roba.

    Invece la lettura di un qualche parametro hardware (seriale del disco, file su una chiavetta usb, ecc) sarebbe una figata, ma trovare un sistema cross browser e cross platform è un incubo.

    quindi al momento uso un accrocchio di tecniche viste in rete, ma non sono ancora soddisfatto al 100%

  10. #10
    Originariamente inviato da barx78
    sono idee mezze buone, ma solo a metà.

    Premetto che lo scopo delle mia paranoie è evitare problematiche di session hijacking e session fixation, che sono ben più subdole e insidiose di semplici tentativi di sniffare nome utente e password (per evitare questo basta SSL).

    l'ip può essere comune a più utenti (vedi pc dietro a un nat o gli utenti fastweb che escono un ip unico) oppure può variare durante la connessione (alcuni provider a volte lo fanno, ma sono pochi).

    gli header inviati dal browser invece possono essere sniffati (basta che ti faccio visitare una mia pagina).

    Https sicuramente è una cosa in più ed è molto robusto, ma se riesce a fare una code injection un estraneo riesce comuqnue a leggere i cookie e altra roba.

    Invece la lettura di un qualche parametro hardware (seriale del disco, file su una chiavetta usb, ecc) sarebbe una figata, ma trovare un sistema cross browser e cross platform è un incubo.

    quindi al momento uso un accrocchio di tecniche viste in rete, ma non sono ancora soddisfatto al 100%
    adesso non so che stai gestendo però sembrano veramente troppe paranoie comunque puoi portarti le sessioni su db così non ci sono problemi

    parti dal presupposto che sul web non c'è nulla di sicuro e che il 100% non esiste.. la sicurezza esiste solo con il cavo della rete staccato..

    la chiave hw servirebbe solo in fase di startup e comunque non sarebbe sicuro lo stesso visto che comunque dovrebbe partire una richiesta o sul db o come parametro appeso all'url oppure come cookie..
    siamo sempre lì .. qualsiasi sia la soluzione che adotti sarai sempre soddisfatto a metà..

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.