Pagina 3 di 3 primaprima 1 2 3
Visualizzazione dei risultati da 21 a 28 su 28

Discussione: Creare array da query

  1. #21
    Quote Originariamente inviata da ANTAGONIA Visualizza il messaggio
    No, scusami, non funziona.
    In pratica non mi riconosce la funzione array_diff_key.
    Su php.net indica come versioni del php installato >5.1.0, e poi 7 o 8.
    Quella che ho è la
    5.6.40 quindi maggiore delle 5.1.0, ma non la riconosce.
    Ah, e un'altra piccola segnalazione: NON usare più versioni così vecchie di php, la versione che stai usando è non più supportata da più di 3 anni, che in informatica sono una eternità!

    Vedi qui:

    https://www.php.net/eol.php

    Vedi qui per le versioni supportate:

    https://www.php.net/supported-versions.php

    Nota che passare dalla 5.6 all 8.1 è probabilmente molto più indolore di quello che pensi, io fossi in te farei qualche test, secondo me probabilmente scopriresti che tutto funziona immediatamente... E il php moderno è MOLTO più veloce del 5.6!
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  2. #22
    punto 1) ok

    punto 2a), mai fatto nulla del genere

    punto 2b) gi� faccio come dici te.
    La funzione str_crypt crea una stringa di questo genere 56525E0755290C0D5400
    La store procedure fa questo:
    Codice PHP:
    BEGIN    SELECT *  FROM table where UserName vNomUte and PwsOri VPwd;END 
    Cosi � come genero la password criptata
    $user= generateRandomString($nome,$length = 10);
    $pass= generateRandomString($nDocumento,$length = 10);
    $this->cPassword= str_crypt($user, $password);

    E la salvo nella tabella con una normale INSERT
    Codice PHP:
    //ho eliminato i campi che non servivano, per questo esempio
    $query$this->connect->query("INSERT INTO tabella 
    ("
    ."UserName,Pwd".") VALUES ("."  \"".$user."\"".", \"".$this->cPassword."\""."  )"); 
    punto 3) i tipi di dato che solitamente invio per GET, per una ricerca tramite link sono sia interi che stringa
    per esempio, ho un "codice" di ricerca, che pu� essere sia numerico che alfanumerico esempio:
    1234567890 oppure 1ABC235678.
    Oppure ho soltanto un valore stringa esempio:
    Codice PHP:
    page.php?tipo=FI 
    punto 4) far� come dici con le funzioni native HTMLawed o HTMLPurifier

  3. #23
    1) ok

    2a) Nel senso che vuoi farlo ma non sai come fare?

    2b) Quello che stai facendo è ESATTAMENTE quello che NON dovresti fare!

    Primo: aver usato una stored procedure non cambia il fatto che stai cercando l'utente nella tabella degli utenti usando sia la username che la password, e questo NON va fatto, per tante ragioni...
    Secondo: la funzione str_crypt NON fa parte di PHP, quindi è una tua funzione, e per dirti se possa essere sicura (ma, francamente, visto come è difficile la crittografia, ne dubito) dovrei vederne il codice...
    Terzo: essendo la sicurezza della criptazione della password tutta data dalla sola funzione str_crypt, nuovamente siamo da capo, potresti stare salvandola in db con una criptazione troppo debole.
    Quarto: anche la generazione casuale della password iniziale non è chiaro come tu la faccia, visto che di nuovo anche generateRandomString() è una tua funzione non parte di PHP; anche questo può aprire a falle di sicurezza, dato anche che non la fai cambiare, se ho capito bene...

    Il modo corretto è questo: che la password venga scelta dall'utente (meglio, ma devi imporre un po' di clausole di complessità minima) o generata casualmente (ma allora devi usare delle vere funzioni random, NON vanno bene rand() o mt_rand(), DEVI usare cose come
    random_int(), random_bytes(), o openssl_random_pseudo_bytes()) in ogni caso devi salvarla nel db dopo averla fatta criptare da password_hash().
    Quando dovrai verificare un utente, lo cercherai SOLO tramite la sua username, ed userai password_verify($password_fornita_dall_utente,$pas sword_criptata_letta_dal_db) per verificare le credenziali.

    3) Come dicevo, CIASCUN parametro dev'essere ripulito e reso non pericoloso secondo le sue regole: se un parametro è un codice numerico intero, allora può bastare intval, ma se il codice deve contenere anche lettere, allora ti devi premurare di filtrarlo in altro modo, usando per esempio le espressioni regolari per stabilire che sia fatto solo di certi caratteri e nient'altro.
    Se invece il parametro dev'essere solo uno di una possibile serie di valori, allora devi controllare che sia uno di essi (per esempio, le provincie FI/BO/MI etc, le devi controllare in una lista di provincie).

    4) strip_tags è nativa di php, ma è debole, gli altri sono librerie esterne, HTMLawed lo trovi qui
    https://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/
    E HTMLPurifier lo trovi qui
    http://htmlpurifier.org/
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  4. #24
    Utente di HTML.it
    Registrato dal
    Oct 2011
    Messaggi
    189
    Cross-site scripting (XSS): https://en.wikipedia.org/wiki/Cross-site_scripting
    Self cross-site scripting (Self-XSS): https://en.wikipedia.org/wiki/Self-XSS
    Mentre devi vanificare o rendere nullo SQL Inejction (poiché agisce per l'istruzione SQL, ergo "il tuo Database"): https://en.wikipedia.org/wiki/SQL_injection
    Se la codifica input e output è conosciuta ti è utile i Preparated Statement (giustamente se la tua applicazione usa Mysqli di php, qui (in sostanza devi assolutamente essere sicuro che il cliente e il database e i Preparated Statement parlano la stessa codifica, altrimenti non funziona ) https://www.php.net/manual/en/mysqli.set-charset.php e potrebbe variare con la versione in uso del RDBMS Mysql a seconda le specifiche del manuale online Mysql (se le tabelle hanno diverso charset del database o una Collacation o Collate diversa o altro se provi il vecchio php).
    Comunque sia una sequenza numerica inviata da una variabile esterna ($_GET o $_POST, $_REQUEST o anche il $_COOKIE per brevità etc. ) è una stringa che invia l'agente utente e la trovi in php come stringa
    Codice PHP:
    //se l'agente utente
    //$_GET['id'] // con valore 1
    if(isset($_GET['id']) && is_string($_GET['id']) && '' !== $_GET['id']) {
    $variabile_dal_programmatore_del_mio_programma urlencode($_GET['id']) === '0' (: '' === trim(urlencode($_GET['id']), '0123456789') ? $_GET['id'] : NULL);
    //supponendo che il tuo sistema operativo usa la corretta rappresentazione del carattere 0 o 1 o 2 o 3 o 4 o 5 o 6 o 7 o 8 o 9 o una sequenza tra di essi (le funzioni php native poiché non leggiamo direttamente il codice potrebbe differire dal comportamento utente voluto e dal codice applicato). Se nel sottoinsieme US-ASCII sicuramente funziona si
    }
    if(isset(
    $variabile_del_programmatore_del_mio_programma) && NULL !== $variabile_del_programmatore_del_mio_programma) {
    //Inserire connessione al database con i dati corretti
    $mysqli = new mysqli("example.com""user""password""database");
    $sql 'SELECT nome_campo FROM nome_tabella WHERE id = ' $variabile_del_programmatore_del_mio_programma;
    var_dump($sql); //Nota l'assenza di apici singoli ergo sintassi "SQL", l'output della sintassi stringa php da non confondere
    //Myslq se il campo id è memorizzato nel type int senza apici singoli lo vede che è già intero, storicamente tra apici singoli indica stringa in Mysql modificata successivamente con l'eccezione se è un valore intero stringa lo interpreta come type int.
    $mysqli->prepare($sql);
    $stmt->execute();
    $result $stmt->get_result();
    $row $result->fetch_assoc();
    var_dump($row['id']); // type int // è spegiato al link precedente per Preparated Statement

    Come suggerito da Shores "lista di province" significa lista bianca (poiché tu crei la stringa si suppone lo fai per la sintassi corretta per l'istruzione SQL). Lista bianca in questo caso significa se è una stringa dello stesso valore applico il valore della mia lista bianca invece di una probabile variabile esterna.
    In realtà non sono funzioni native ma bensì funzioni dall'area utente (cioè non direttamente fornite da php). HTMLPurifier etc.
    Ultima modifica di darbula; 24-01-2022 a 13:04

  5. #25
    Buongiorno a tutti. Sto cercando di capire e mettere in pratica, le magnifiche informazioni che mi avete dato. Di sicuro vi chiederò di aiutarmi a capire più di qualcosa. Nel frattempo vi ringrazio infinitamente.

  6. #26
    Buongiorno di nuovo a tutti.
    Vi ringrazio ancora e ancora per l'aiuto che mi state dando.

    Allora:
    1) per la ricerca dell'utente, nella query, ho fatto come suggerito, soltanto con la username, poi la password la utilizzo come suggerito in uno dei post precedenti, con password_verify().
    Ho convertito le password con password_hash().

    2) qui si dice: "ma se il codice deve contenere anche lettere, allora ti devi premurare di filtrarlo in altro modo, usando per esempio le espressioni regolari per stabilire che sia fatto solo di certi caratteri e nient'altro."
    Devo utilizzare una regular expression come questa?
    Codice PHP:
    ^([a-z]|[A-Z]|[0-9]){4,8}$
    if (
    preg_match("/php/i""PHP is the web scripting language of choice.")) {    echo "A match was found.";} else {    echo "A match was not found.";} 
    Domanda: se ho un campo di ricerca, nel quale digiteranno una o pi� stringhe alfanumeriche, come lo faccio il controllo?


    3) per quanto riguarda il Cross-site scripting (XSS), nell'htaccess ho scritto questo di seguito, � corretto o c'� dell'altro?
    Codice PHP:
    #XSS(Cross-site scripting)Header set X-XSS-Protection "1;mode=block"
    #Frame e click-jacking 
    #Header set X-Frame-Options DENY
    #Server header(nascondere le informazioni del server)
    Header unset X-Powered-By
    #Content-sniffing(sfrutta questa falla per iniettare del codice malevolo all�interno del file e farlo renderizzare dal browser come codice HTML)
    Header set X-Content-Type-Options nosniff 
    Per il momento solo questo, per� ho altro da chiedervi.
    Grazie mille a tutti.
    Ultima modifica di ANTAGONIA; 31-01-2022 a 12:57

  7. #27
    1) Ottimo, se vuoi poi mostraci esattamente il codice così possiamo dirti se notiamo altro che non va.

    2) L'idea è che devi rifiutare tutti i caratteri che non siano sensati o siano pericolosi, per esempio:

    codice:
    //a string made only of a-z, A-Z, digits, spaces, _ or |
    $newParamValue = preg_replace('/[^0-9a-zA-Z _|]/u',"",strval($newParamValue));
    che accetta nella variabile $newParamValue solo i tipi di caratteri indicati , eliminando tutti gli altri.

    Naturalmente, devi studiare le espressioni regolari per scriverne di adatte al tuo specifico tipo di parametro.

    3) Allora, la prima serve solo a nascondere la versione di Php in uso, ma è poco utile, visto che comunque, a meno tu non stia usando anche lo url rewriting, si vedrà comunque dalla estensione.php che usi php...

    La seconda è utile per mitigare UNO dei tanti vettori di attacco XSS, ma non basta certamente.

    Per quel che riguarda XSS e le altre forme di attacco, la cosa migliore è scaricarsi OWASP ZAP e provare a fargli attaccare il proprio sito (naturalmente NON quello in produzione, ma una copia identica di testing): dopo aver lavorato per parecchio tempo, OWASP restituirà tutta una serie di avvisi, ognuno riguardante una vulnerabilità trovata, e ognuno con un link alle spiegazioni corrispondenti su come mitigarla o risolverla.

    Diciamo che una volta riusciti a correggere tutte le segnalazioni di ZAP NON sarai sicuro che il tuo sito sia impenetrabile, ma almeno che sia ben più robusto della maggior parte dei siti in circolazione, cosa che sarà sufficiente perché i rompiscatole scelgano altri bersagli più facili!
    Ultima modifica di Shores; 31-01-2022 a 16:22
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

  8. #28
    Buongiorno a tutti.
    Ho questo quesito, anche se la risposta credo di saperla.
    1) Ho criptato con
    Codice PHP:
    $pss "kwta0eFD8X";
    password_hash($pssPASSWORD_DEFAULT);
    //ottenendo la relativa stringa che ho inserito nella tabella nel campo psw_hash, tipo: text e codifica caratteri: latin1_swedish_ci
    //ditemi per favore se il tipo e la codifica vanno bene oppure li devo cambiare 
    2) Nella tabella tb_utenti ho 3 campi: username, psw(non criptata), psw_hash
    3) facendo questo controllo con password_verify($PASSWORD, $risultato['psw_hash']) come di seguito, il campo psw(non criptato) non ha motivo di esistere nella tabella giusto?
    Codice PHP:
    $USERNAME $this->connect->real_escape_string($USER);$USERNAME preg_replace('/[^0-9a-zA-Z]/u',"",strval($USERNAME));$PASSWORD $this->connect->real_escape_string($PWS);$PASSWORD preg_replace('/[^0-9a-zA-Z]/u',"",strval($PASSWORD));if($USERNAME!="" && $PASSWORD!=""){    $stmt $this->connect->prepare("SELECT * FROM ".TB_UTENTI." WHERE UserName = ?");    $stmt->bind_param('s'$USERNAME); // 's' specifies the variable type => 'string'    $stmt->execute();    $result = $stmt->get_result();    $risultato = $result->fetch_assoc();    if($risultato!=NULL){        if (password_verify($PASSWORD, $risultato['psw_hash'])) {
                          
    $_SESSION['login'] = true;
                          
    //etc etc
                    
    }
                    else{        echo 
    "Non è abilitato.";        }
              }      else{        echo 
    "Non sei registrato oppure i dati inseriti per l'autenticazione non sono validi";       }    $stmt->free_result();} 
    4) la password che sceglie l'utente, mi serve soltanto per creare quella criptata con password_hash($pss, PASSWORD_DEFAULT), e quindi non la devo memorizzare da nessuna parte. Giusto?
    Quindi, nel caso, l'utente la dimentica, glie ne faccio scegliere una nuova, ma che verrà utilizzata soltanto per generare una nuova password criptata. Giusto?

    Poi, vi scriver� per altro.
    Grazie ancora e ancora.
    Ultima modifica di ANTAGONIA; 02-02-2022 a 13:51

  9. #29
    1) A parte che non bisogna mai usare delle password fisse come questa, si, la password_hash ti restituisce la password criptata da salvare nel campo del DB, che va bene avere con quel tipo e codifica.

    2) NON BISOGNA MAI MAI MAI salvare una password non criptata da NESSUNA parte.

    3)A parte il fatto che sulla password NON DEVI fare NESSUNA di quelle verifiche/modifiche, che la cambiano rispetto a quanto digitato dall'utente, ma devi passarla così come è alla password_verify(), il codice va sostanzialmente bene, io aggiungerei per maggiore sicurezza una verifica che la query restituisca UNA sola riga, così da essere certi che abbiamo trovato l'unico utente di cui verificare la password con password_verify().

    4) Esatto, quando ricevi la nuova password scelta dall'utente, al massimo confrontala con il doppio campo password se lo hai previsto (quello "digita di nuovo la password", per capirci) dopodichè trasforma subito la password con password_hash e elimina quella non criptata. Questo, come dici giustamente, significa che NON sarà possibile recuperare quella password, ma dovrai farne scegliere un'altra all'utente nel caso in cui l'abbia dimenticata.

    Solo un'ultima nota, ricorda che le maschere di login DEVONO SEMPRE essere via POST e MAI via GET, e meglio se sono su https.
    "Le uniche cose che sbagli sono quelle che non provi a fare."
    Atipica

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