Visualizzazione dei risultati da 1 a 9 su 9
  1. #1

    Evitare l'SQL Injection

    So che questa domanda è già stata posta ma non sono riuscito a trovare una risposta che mi convincesse, ho letto delle tecniche più svariate per evitare l'SQL injection ma qualcuno di voi saprebbe dirmi la più sicura o almeno quella che secondo voi è la scelta migliore?

  2. #2
    il metodo PIU' SICURO è quello di correggere il proprio codice seguendo apposite pratiche e metodologie di sviluppe

    tutte le altre soluzioni sono palliativi al problema
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  3. #3
    Sì ok ma quali sarebbero queste metodologie?

  4. #4
    http://www.google.it/search?rlz=1C1G...re+programming

    Qui alcuni consigli utili
    http://www.cgisecurity.com/lib/php-secure-coding.html
    http://www.dwheeler.com/secure-progr...HOWTO/php.html

    Qui tanti consigli utili
    http://devzone.zend.com/search/resul...p+security+tip

    Detto questo, google è pieno di esempi utili!

    Per quanto riguarda l'sql ... devi SEMPRE filtrare TUTTO quello che passi alle query ... SEMPRE

    se devi passare un numero, ad esempio, devi SEMPRE convertirlo in numero cosi da essere sicuro che non si possano far danni
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  5. #5
    Ok grazie!

  6. #6
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    3,709
    concordo con i consigli e aggiungo: per EVITARE le "injections" bisogna NON mettere mai parametri passati in "maniera aperta"... se ci sono selezioni multiple si usa un bello "switch" per gestire i casi possibili e inserire nel codice le alternative, se invece ci sono valori non inquadrabili a priori in una lista chiusa si convertono i contenuti con "escape" e conversioni di tipo (per esempio per i numeri)

    esempi:
    - campo di una tabella che può valere "T" o "F":
    essendo un range preciso userò uno switch tipo:
    $x = $_GET['field']; $x = funzionediescape($x);
    switch ($x) {
    case 'T': $p = 'true';
    case 'F': $p = 'false';
    default: $p = valoredidefault;
    };

    - campo numerico:
    $x = $_GET['field']; $x = funzionediescape($x);
    $p = intval($x);

    e così via...

  7. #7
    Originariamente inviato da eiyen
    concordo con i consigli e aggiungo: per EVITARE le "injections" bisogna NON mettere mai parametri passati in "maniera aperta"... se ci sono selezioni multiple si usa un bello "switch" per gestire i casi possibili e inserire nel codice le alternative, se invece ci sono valori non inquadrabili a priori in una lista chiusa si convertono i contenuti con "escape" e conversioni di tipo (per esempio per i numeri)
    sono "parzialmente" d'accordo con questo consiglio perché mentre per certi parametro (che so, se ti serve includere un file in base ad un certo parametro non è il caso di passare il nome del file da includere) sono pienamente d'accordo ma per ove non è strettamente necessario è meglio evitare altrimenti diventa il caos assoluto!

    E' meglio correggere i parametri (tramite espressioni regolari, conversioni del valore e via dicendo), male che va non restituisce nulla ma non si fanno danni!
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  8. #8
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    3,709
    Originariamente inviato da daniele_dll
    è meglio evitare altrimenti diventa il caos assoluto!

    E' meglio correggere i parametri (tramite espressioni regolari, conversioni del valore e via dicendo), male che va non restituisce nulla ma non si fanno danni!
    perchè?

    Specifico che io NON dico di fare sempre così: l'indicazione che ho riportato vale se si vuole EVITARE con certezza l'injection (infatti si ha la certezza se nessuna query viene creata direttamente dai parametri passati dall'utente)... dopodichè qualunque sistema di controllo ben verificato può andar bene... per il fatto del caos non credo (ma forse ho capito male cosa intendevi): di fatto conviene secondo me crearsi una funzione tipo "FilterParameter($name)" eventualmente con ulteriori parametri aggiuntivi (p.es. un "$cast" cui si passa il tipo di valore che il parametro deve avere) che preleva il parametro ($_GET o $_POST o altro), lo filtra ed eventualmente lo pulisce.

  9. #9
    Forse sto sbagliando qualcosa perché io sto utilizzando le espressioni regolari per limitare i caratteri inseribili dall'utente ma se inserisco delle istruzioni php queste vengono eseguite!
    Vi faccio un esempio: ho creato un campo in cui inserire un codice di controllo a 5 cifre, solo numeri o lettere minuscole, quindi nel file php scrivo:

    Codice PHP:
    session_start();
    $code $_GET['code'];
    $pattern "/[a-z0-9]{5}/";

    if (
    preg_match($pattern,$code)) {
      if(
    $code == $_SESSION['captcha']) {
        echo 
    "true";
      }
      else {
        echo 
    "false";
      }
    }
    else {
      echo 
    "false";

    Il codice funziona ma se nel campo input inserisco:

    Codice PHP:
    $code "12345"
    allora mi ritorna true.
    Non capisco come fare per evitare che il codice php venga letto.

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.