Pagina 2 di 3 primaprima 1 2 3 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 25
  1. #11
    Vi allego i file che ho creato....

    Scarica file

  2. #12
    1) Sei molto vulnerabile da una SQL injection
    2) le password dovrebbero essere in hash
    3) fai un https per la criptazione
    4) spero che il $_SESSION[autorizzato] derivi da un sessionid();
    Se ti va fai un'elenco preciso di cosa dovrebbe avere un login sicuro..

    session_id() lo usi per verificare se l'id dell'utente è sempre lo stesso?

    Per proteggersi dall'SQL injection bastano questi accorgimenti:
    L'unica possibilità di protezione è un controllo sui dati ricevuti da parte del programmatore, durante lo sviluppo del programma. Bisogna cioè assicurarsi che l'input ricevuto rispetti le regole necessarie, e questo può essere fatto in diversi modi:

    * controllare il tipo dei dati ricevuti (se ad esempio ci si aspetta un valore numerico, controllare che l'input sia un valore numerico);
    * forzare il tipo dei dati ricevuti (se ad esempio ci si aspetta un valore numerico, si può forzare l'input affinché diventi comunque un valore numerico);
    * filtrare i dati ricevuti attraverso le espressioni regolari (regex);
    * sostituire i caratteri pericolosi con equivalenti caratteri innocui (ad esempio in entità html);
    * effettuare l'escape dei dati ricevuti (ogni linguaggio, solitamente, mette a disposizione particolari funzioni per questo scopo).

    Ovviamente, questi metodi possono essere applicati anche insieme sullo stesso dato in input. La scelta varia proprio a seconda delle tipologie di questi dati. Occorre, quindi, prestare particolare attenzione a tutte le varianti di un input, tenendo conto di ogni possibile (oppure improbabile) ipotesi.
    Da wikipedia

  3. #13
    Nessuno sa dirmi perchè non va ????

    Ho postato tutte le mie pagine...

  4. #14
    Originariamente inviato da bonzox
    Se ti va fai un'elenco preciso di cosa dovrebbe avere un login sicuro..

    session_id() lo usi per verificare se l'id dell'utente è sempre lo stesso?

    Per proteggersi dall'SQL injection bastano questi accorgimenti:
    Da wikipedia
    Quando arriva la password in post la prima verifica è questa:

    Codice PHP:
    if (ereg("^[A-Za-z0-9]+$"$_POST[password])){
        
    $password=md5($_POST[password]);

    elimina eventuali injection e passa in hash la password per il controllo alla query (nel db la password è già in hash)

    poi prima di attivare la sessione con

    Codice PHP:
    $_SESSION['sessionid']= session_id(); 
    si fanno altri controlli a cascata come ad esempio se esiste un livello utente o anche una chiave di accesso ulteriore.

  5. #15
    Originariamente inviato da bonzox
    session_id() lo usi per verificare se l'id dell'utente è sempre lo stesso?
    Scusa...giusto per...come fai a verificare che il session_id sia sempre lo stesso? lo confronti con cosa?

  6. #16
    Ma dove è sbagliato il mio script ???

    Help me !!!!

  7. #17
    Originariamente inviato da silverwings
    Quando arriva la password in post la prima verifica è questa:

    Codice PHP:
    if (ereg("^[A-Za-z0-9]+$"$_POST[password])){
        
    $password=md5($_POST[password]);

    elimina eventuali injection e passa in hash la password per il controllo alla query (nel db la password è già in hash)
    Cioè controlla che la password sia fatta di lettere e numeri?
    Ce caratteri non si devono far mettere nelle pwd ad un utente quando si registra?

    Originariamente inviato da silverwings
    poi prima di attivare la sessione con

    Codice PHP:
    $_SESSION['sessionid']= session_id(); 
    si fanno altri controlli a cascata come ad esempio se esiste un livello utente o anche una chiave di accesso ulteriore.
    Quindi tu tieni in una variabile di sessione l'id dell'utente e verifichi sia sempre lo stesso nelle pagine di accesso protetto?

    P.S.
    Argomento interessante, molte grazie

  8. #18
    Nelle injection è necessario inserire un '=' o altri elementi esterni a i semplici a-z o numeri per fare dei crack quindi con ereg già elimini eventuali attacchi.

    Se il login è effettuato in modo corretto in https puoi sempre controllare se la $_SESSION['sessionid'] esiste ed eventualmente anche altri parametri come la $_SESSION[level] che io uso per i livelli degli utenti, per livelli intendo permessi.

  9. #19
    Originariamente inviato da silverwings
    Nelle injection è necessario inserire un '=' o altri elementi esterni a i semplici a-z o numeri per fare dei crack quindi con ereg già elimini eventuali attacchi.
    Ok, ma quando un utente si registra quindi non mi deve mettere '=' come carattere?
    la Password la devo permettere solo con caratteri tipo numeri, lettere e poi?
    _ - possono metterli?

    Originariamente inviato da silverwings
    Se il login è effettuato in modo corretto in https puoi sempre controllare se la $_SESSION['sessionid'] esiste ed eventualmente anche altri parametri come la $_SESSION[level] che io uso per i livelli degli utenti, per livelli intendo permessi.
    Ok, faccio così anche io per i permessi, però uso anche $_SESSION['username'] in cui metto l'user dell'utente e la uso se devo prelevare i suoi dati dal DB per fare controlli.

  10. #20
    ok in sessione puoi salvare tutte le variabile che vuoi per dei controlli e quelle che ritieni importanti per il sito come quelle della lingua ad esempio.

    E' chiaro che in registrazione devi dare dei controlli sulla password io non faccio inserire nessun tipo di carattere tranne caratteri alfanumerici per sicurezza. Ogni sito può scegliere i suoi metodi negli e-commerce faccio inserire almeno 8 caratteri per la passwrod che deve contenere caratteri e anche numeri.

    Per i siti minori va bene una passwrod a 6 caratteri anche con solo lettere

    Io comunque per gli e-commerce gestisco sia registrazione che login in https

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 © 2026 vBulletin Solutions, Inc. All rights reserved.