Sicurezza applicazioni web

[ilNotturn0]

Salve a tutti,
non mi reputo un esperto di sicurezza per quanto riguarda le applicazioni web e quindi cerco spesso consigli / suggerimenti per migliorarmi.

Volevo sapere se secondo voi quel che faccio per evitare problemi possa essere sufficiente per scongiurare bachi di sicurezza nelle mie applicazioni web, vedo tra voi tanti esperti ed un confronto mi farebbe molto piacere.

Documentandomi tra le guide e seguendo alcuni script / consigli di questo forum (grazie anzitutto per quanto creato e condiviso), questo è quanto faccio:

Criptazione password di accesso

function criptpass ( $pass ) 
{
     $passaggio = md5($pass);
     $password_criptata = md5($passaggio);
     return $password_criptata; 
} 

Eliminazione vulnerabilità XSS e HTML

function killHTML($html)
{
    $myReg = '/<[^>]*?[^>]*?>/';
    if(preg_match($myReg, $html))
    {
        $var = preg_replace($myReg, '', $html);
    }
    else
    {
        $var = $html;
    }
    $badHTML = array("<", ">", "//", "/>");
    $var = str_replace($badHTML, '_', $var);
    return $var;
}

function killXSS($var)
{
    $badString = array('<javascript', '<script', '</script', '<iframe', 'onload = ', '<layer', '<meta http', '<object', '</object>', '<input', 'background = ', '<bgsound', '<style', 'http');
    $goodString = array('jav-asc-rip-t', '', '', 'fr-a-me', 'onl-oad', 'la-y-er', '', '', '', '', '', '', '', 'ht_tp');
    $var = str_replace($badString, $goodString, $var);
    foreach($badString as $badWord)
    {
        if(stristr($var, $badWord))
    {
            $var = str_replace($badString, $goodString, strtolower($var));
        }
    }
    return $var;
}

function killALL($var)
{
    $var = killXSS($var);
    $var = killHTML($var);
    $var = addslashes($var);
    return $var;
} 

Recupero variabile POST o GET

if(isset($_GET["variabile"])) $variabile = killALL($_GET["variabile"]); 

Quanto ripetuto lo eseguo per ogni variabile passata tramite form o querystring e poi utilizzo le mie variabile recuperate all'interno della pagina o delle query per recuperare informazioni dal database.

Per quanto riguarda invece l'accesso alla sezione riservata ho di base nome utente e una password (criptata come visto) nel mio db. All'atto del login:

Login

// Eseguo la ricerca nel db ed estraggo i dati dell'utente
if(utente_esiste)
{
    $_SESSION['login'] = "$prefisso.$valoreDiAutenticazione";
    $_SESSION['nickname'] = $nickname;
    $_SESSION['password']= $password;
} 

Recupero informazioni nelle pagina interne (dopo aver effettuato il login)

if(isset($_SESSION['login']) && $_SESSION['login']=="$prefisso.$valoreDiAutenticazione")
{
        $nick_utente_loggato = $_SESSION['nickname'];
        $pass_utente_loggato = $_SESSION['password']; #criptata
        
        # Cerco l'utente con i dati salvati nella sessione ed estraggo i dati

        $_SESSION['utente_autorizzato'] = "$prefisso.$nickname.$valoreDiAutenticazione";
        $utente_autorizzato = $_SESSION['utente_autorizzato'];
    }
} 

Secondo voi possono andare bene come sistemi di sicurezza oppure quanto imparato fin'ora non serve a nulla?
Grazie per la pazienza, spero quanto scritto possa servire a qualcuno ed aiutarmi a migliorare

[daniele_dll]

beh ...

# Criptazione password di accesso
------

Codificare i dati di accesso presenti nel database è utile ma il problema principale sta comunque nell'evitare di arrivare a questi dati!

L'MD5 è ormai un algorittimo fragile ed insicuro, vi sono strumenti che usano la GPU della scheda video per forzare la password tramite bruteforce cosi come vi sono algorittimi che usano le collisioni per trovare i possibili canditati e sono INFINITAMENTE veloci.

Lo stesso problema lo ha anche lo SHA1 in realtà, per fortuna le versioni successive, vedasi SHA256 e SHA512 sono più sicure.

In realtà per stare più tranquilli ancora ci vorrebbe usare un HMAC-SHA512 ... è difficile risalire all'originale

Detto questo, in realtà, tu non stai crittografando la password bensì stai generando un HASH ovvero un codice di uscita che darà sempre lo stesso risultato per il codice di entrata ma non permette di risalire tramite il codice di uscita al codice di entrata. La crittografia, invece, ti permette di codificare e decodificare un dato valore in base a dei parametri.

In ogni caso, considera che se qualcuno entra nel database, della password in MD5 non te ne fai ASSOLUTAMENTE nulla perché possono leggere TUTTO quello che vogliono, però, se qualcuno dovesse entrare tramite sql injection è possibile che per esempio riesca ad accedere ESCLUSIVAMENTE alla tabella degli utenti e la password sotto forma di hash o crittografata limiti comunque i danni.

Personalmente preferisco usare la crittografia, piuttosto che un hash, per poter recuperare la password dell'utente.

# Eliminazione vulnerabilità XSS e HTML
------

Per quanto riguarda queste problematiche esiste la funzione strip_tags che ti permette di eliminare N tags, solo che questa funzione, cosi come il tuo codice, non su preoccupano degli attributi!

Basterebbe fare un
<b onclick="azione malevola">Ciao![/b]

e rischieresti GROSSO!

(Ad es leggo il cookie della tua sessione e lo spedisco ad una pagina web malevola tramite un redirect con il risultato che l'attaccante ha la tua sessione e può accedere come fossi tu ... tranne se vengono effettuati controlli anche sull'ip ma non tutti li fanno ... anzi ......)

Un primo controllo è possibile effettuarlo tramite strip_tags, lasciando eventuali tag ammessi e poi un secondo controllo per rimuovere tutti gli attributi dei tag

un qualcosa del genere

<([^ ]+) ([^>]+)>([^<]+)</\\1>
in
<$1>$3</$1>

non ho provato l'espressione regolare e so per certo che farebbe non pochi casini scritta cosi, ma serve per farti un esempio

in realtà basterebbe
<([^ ]+) ([^>]+)>
in
<$1>

già a risolvere il problema attributi

# Recupero variabile POST o GET
------

Dipende che devi farci, personalmente ho una funzione che utilizza stripslashes che rimuove (anche ricorsivamente in presenza di array) le backeslash da GET, POST, COOKIE, FILES, SERVER e REQUEST in caso che magic_quote_gpc sia attivo

cosi che da avere i valori puliti e pericolosi e poi li tratto di conseguenza nel resto del codice

# Login
------

Sicurezza e di sessioni di php sono due cose che non vanno per NIENTE d'accordo! Dovresti togliere proprio di mezzo ai piedi le sessioni di php e farti la tua gestione sessione.

Una volta che hai il SID ed il SID è valido (perché ne controlli la scadenza) sei anche sicuro che l'utente sia loggato con quei dati di accesso

# Recupero informazioni nelle pagina interne (dopo aver effettuato il login)
------

Non capisco a che ti serva ... se usi le sessioni di php già $_SESSION contiene tutto quello che hai memorizzato e se non vuoi usare più le sessioni di php con una semplice classe che on demand estrae i parametri che hai salvato (solo la prima volta, poi le richieste successive ripassa gli stessi valori) e buona notte

[ilNotturn0]

Ciao Daniele e anzitutto grazie mille per reply e delucidazioni.

Allora:

# Criptazione password di accesso
---------------
Hai ragione a dire che si parla di hash e non di criptazione, nella fretta di scrivere non ho pensato a sottolinearne la differenza.
Il fatto è per salvare i dati nel db mi serve necessariamente un sistema per non inserire la password in chiaro e leggendo un pò in giro un doppio hash con md5 sembrava abbastanza sicuro.
Del recupero password non mi importa più di tanto, anzi è che "a naso" sapere di non poter recuperare la password mi rende anche più tranquillo.
Il tuo consiglio è quindi di prendere informazioni riguardo a HMAC-SHA512? Come soluzione potrebbe andare?
Per l'entrata nel database dubito sia possibile con quanto ho scritto sinora, l'accesso diretto è altrove e la connessione al db la utilizzo solo per select nell'area pubblica o insert, update, delete nell'area riservata (sempre delimitate ad un solo record, mai a gruppi) a cui si accede tramite nickname e password, ma qui torniamo al punto di partenza.


# Eliminazione vulnerabilità XSS e HTML
---------------
Quindi fammi capire (e grazie per la pazienza): il problema non è nel recupero di variabili (in quanto i tag vengono filtrati a dovere) ma negli attributi di tali tag.
Ma la domanda è: anche passando un valore come dici tu, ovvero <b onclick="azione malevola">Ciao![/b], come può l'attributo creare danni se già di suo il tag html [b] è filtrato?
Grazie della delucidazione perchè mi sfugge il passaggio


# Recupero variabile POST o GET
----------------
Quindi anzichè usare le funzioni: killXSS, killHTML e poi addslashes sulla variabile mi consigli solamente le stripslashes? Ottengo lo stesso risultato o sono poi vulnerabile a qualcosa?


# Login
----------------
La cosa mi interessa molto: hai magari qualche articolo che spieghi come fare o almeno per approfondire? Già che ci sono potrei imparare qualcosa


# Recupero informazioni nelle pagina interne (dopo aver effettuato il login)
-----------------
Hai ragione

Grazie ancora e scusa per le domande stupide che ti ho posto, ma da qualche parte bisogna pur incominciare

[daniele_dll]

# Criptazione password di accesso
------

Possono sempre bucare il database tramite SQL Injection, ad esempio, e, in base alla query utilizzata per la SQL Inject si può come non si può accedere a dei dati

# Eliminazione vulnerabilità XSS e HTML
------

il momento in cui dovrai usare un editor HTML semplificato cosa farai?

la totale ELIMINAZIONE a prescindere dei tag non è sempre fattibile, dipende dal progetto, e con la soluzione proposta hai maggiore sicurezza perché ti da la possibilità di eliminare a prescindere tutti i tag, ma se ti dovesse servire lasciarni alcuni puoi far saltare gli attributi

# Recupero variabile POST o GET
------

Ehm, con solo stripslashes ovviamente diventi vulnerabile ma non è delle variabili esterne che ti devi preoccupare bensì del loro inserimento nel database!

Per intenderci, se fai i controlli su cosa contiene il testo, ad esempio il nome od il cognome, non potrà mai starci un \ ... deve saltare, cosi come non ci dovranno stare tag o altro ... ma questo controllo va effettuato ad hoc per il campo

# Login
------

Se cerchi sul forum c'è di tutto e di più riguardo alle sessioni su database

------------------

Detto tutto questo, ricordati sempre che la sicurezza va applicata ma non deve compromettere il funzionamento o la logica di funzionamento (ad esempio eliminare tutti i tag html o lasciare le backslash a priori, secondo me, è sbagliato!)

[ilNotturn0]

# Criptazione password di accesso
------
Capito, quindi per impedirlo devo comunque stare attento a come gestisco i parametri che mi vengono passati altrimenti se non filtro a dovere le variabili in arrivo possono capitare SQL Injection e quindi che la password sia criptata (o hash) o meno mi serve a ben poco.

# Eliminazione vulnerabilità XSS e HTML
------
Quella dell'editor semplificato in effetti mi era sfuggita, hai ragione!
Quindi va bene evitare attributi, ma penso che tanto prima o poi arriverà il momento in cui mi debba "fidare" della mia applicazione e permettere qualcosa agli utenti, e lì credo sarà fondamentale capire se il lavoro compiuto per evitare login estranei sia buono o meno.

# Recupero variabile POST o GET
------
Capito

# Login
------
Non attendo oltre e mi metto alla ricerca

------------------

Ottima l'osservazione finale, forse essere troppo maniacale non porta a nulla alla fine.
Grazie per la pazienza, mi hai dato molto materiale su cui lavorare e documentarmi, spero mi aiuti a diventare migliore in questo campo.

Grazie mille e buona giornata

[daniele_dll]

ultima cosa

per le query uso una combinazione di vsprintfs con l'escape

in pratica leggo i parametri passati al metodo/funzione usando func_get_args, elimino il primo usando l'unshift, array_unshift (se non ricordo male), poi ciclo l'array facendo l'escape (dato che già le variabili non contengono backslash o altro) ed infine lo passo a vsprintfs come secondo parametro mentre come primo passo la query che contiene ad es %s per le stringhe, %d per i numeri e cosi via

con questo giochino non esiste, a priori, il rischio che la query contenga qualcosa che non deve: vsprintf effettua la conversione dei valori quindi se metti %d ma scordi di controllare che il valore sia un numero ... in ogni caso diviene un numero, sballato magari, errato, ma è un numero che comunque non ti fa rischiare di farti mettere giù il lavoro!

printf è molto potente e ti permette di fare varie combinazioni tra cui anche quelle posizionali (ergo se devi mettere il secondo parametro in 3 posti diversi ed è un numero con una lunghezza di 6 posizionando degli zeri davanti ad esempio fai %2$06d in tutti e 3 i posti dove lo devi andare a mettere!)

ci vogliono tanti accorgimenti però questo, già da solo riduce il rischio delle sql injection ad una percentuale bassissima!!! Ovvero a quei casi dove non passi direttamente il valore alla funzione della query ma costruisci la stringa della query a pezzi e quindi devi effettuare l'escape tu manualmente

[ilNotturn0]

Accidenti, questa cosa mi giunge nuova: Ottima davvero, mi devo documentare veramente tanto!
Vediamo se il caro vecchio google può venirmi incontro e grazie ancora!

[ilNotturn0]

Ciao daniele_dll,
ho seguito qualche consiglio e ho messo da parte le sessioni: documentandomi anche qui su html.it ho trovato un metodo alternativo alle sessioni che sfrutta i database, l'ho modificato secondo le mie esigenze ed ora il token per controllare la connessione attiva viene passato via querystring (e non tramite cookie come scritto nella guida), filtrato e i dati che mi servono estratti dal database.

Già così credo di aver migliorato il mio bagaglio culturale, ci tenevo quindi a ringraziarti

[daniele_dll]

figurati

PS: non avere timore ad usare i cookie! considera che passare il token della sessione via query string è una consistente seccatura (tranne che lo fai automaticamente tramite un filtraggio effettuato tramite ob_start)

[ade_v]

Ciao daniele_dll, ho seguito qualche consiglio e ho messo da parte le sessioni: documentandomi anche qui su html.it ho trovato un metodo alternativo alle sessioni che sfrutta i database, l'ho modificato secondo le mie esigenze ed ora il token per controllare la connessione attiva viene passato via querystring (e non tramite cookie come scritto nella guida), filtrato e i dati che mi servono estratti dal database.

Mi passeresti il link di quanto hai trovato per favore ? Mi piacerebbe capire meglio di che procedimento si tratta.

Grazie