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

    Sicurezza siti in PHP: XSS, MySQL Injection, CSRF...

    Ciao a tutti, mi scuso se ho sbagliato la sezione, ma non sapevo quale fosse quella più idonea..

    So che è impossibile proteggere al 100% un sito scritto in puro php, ma continuo a informarmi per prevenire i possibili attacchi. Sono arrivato a questa conclusione e avrei bisogno di conferme:

    - Prevenire XSS: ogni campo di input dovrebbe avere dei filtri php che eliminino tag, caratteri speciali, simboli e spazi inutili;

    - Prevenire MySQL injection: scrivere le query con "prepare";

    - Prevenire attacchi CSRF: implementare i campi di login con dei token;

    In più:

    - aggiungere il CAPTCHA ai login e ai campi di ricerca;

    - criptare le password degli utenti registrati nel database, in SHA512.

    Sono sufficienti queste prevenzioni? A parte i settaggi del server (firewall, password complessa, disabilitazione di allow_url_fopen, ecc) cosa posso fare di più?

    Grazie

  2. #2
    Utente di HTML.it L'avatar di MySQL
    Registrato dal
    May 2015
    Messaggi
    729
    Quote Originariamente inviata da magic_key Visualizza il messaggio
    - Prevenire XSS: ogni campo di input dovrebbe avere dei filtri php che eliminino tag, caratteri speciali, simboli e spazi inutili;
    E soprattutto controllare i tipi dei campi, e pure la lunghezza, e mai e poi mai "stampare a video" (cioè fare l'echo) una query
    - Prevenire MySQL injection: scrivere le query con "prepare";
    vale come sopra
    - Prevenire attacchi CSRF: implementare i campi di login con dei token;
    se per "login" intendi... un classico login nome utente e password, torni sempre al primo punto, cioè consentire solo caratteri alfanumerici e simboli che decidi tu.
    Tutto il resto => via
    In più:

    - aggiungere il CAPTCHA ai login e ai campi di ricerca;
    Dipende dai casi, se la ricerca la fai già loggato non ha un grandissimo senso. Anche per il login se "sanitizzi" brutalmente non è indispensabile
    - criptare le password degli utenti registrati nel database, in SHA512.
    Pressochè inutile per la sicurezza, riguarda un problema diverso (cioè la privacy degli utenti qualora il database venga rubato).
    Per inciso non basta usare un algoritmo, qualsiasi algoritmo, altrimenti il brute force è troppo facile.
    Bisogna avere un sale, ed in più iterare molte volte, e magari con algoritmi diversi e lenti (tipo 3des), e magari un numero di volte diverso per ogni utente (sale2)
    Sono sufficienti queste prevenzioni? A parte i settaggi del server (firewall, password complessa, disabilitazione di allow_url_fopen, ecc) cosa posso fare di più?
    Tante cose.
    Puoi ad esempio bloccare col firewall IN USCITA tutte le porte che non ti interessano (così se si infetta il provider non ti disattiverà perchè partono scansioni a raffica).
    Puoi disattivare la password del tutto, a favore di un login SSH solo con chiavi.
    Puoi cambiare la porta ssh per ridurre gli scriptkiddie.
    Puoi usare meccanismi di ban su login al server dopo N tentativi.
    Puoi togliere bash del tutto (esempio su BSD, ma si può fare anche su Linux con un po' di sbattimento in più).
    Sul database (a seconda dei casi) mysql puoi disattivare del tutto il networking, a favore di accesso solo con pipe locali
    E 1000 altre cose.

    Lato sicurezza invece dell'applicazione normalmente mi rileggo questo
    http://cwe.mitre.org/top25/index.html

    Non sarà la bibbia, ma meglio di niente.

  3. #3
    Grazie per la risposta ho provato anche Acunetix per rilevare la presenza di vulnerabilità.. i suoi alert sono attendibili? (ovvio che non può fare controlli a livello server..)

  4. #4
    Vorrei evitare di aprire un nuovo topic simile e spero che la discussione non sia troppo datata.

    Una domanda: il prepared statement ha senso usarlo più nei casi di dati in entrata con $_GET o $_POST ? In tutti gli altri casi è sufficiente la query normale?

    Ho sempre usato il prepared statement in tutti i casi, anche quando non sono previste variabili nel bind, ma non so se è "inutile" fare così..

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.