Come testare la sicurezza di un CMS

[IMMANUEL_KANT]

Ciao a tutti.
Dovrei testare la sicurezza di qualche piattaforma cms nuke based.
Per intenderci php-nuke,postnuke xoops, envolution e forse qualcos'altro. Non so però da dove iniziare .

Avevo pensato, una volta installati in remoto su uno stesso server di sottoporli a portscanning. I miei dubbi:
- Con un portscanning riesco a testare la sicurezza dell'applicazione o solo del server (che non mi interessa)?
- Devo chiedere il permesso all'amministratore dello spazio (che nel caso di lycos immagino che sia negativa ammesso che mi rispondano)?

Che alternative ho per raggiungere lo scopo?

Ciao a tutti e grazie

[xdesign]

Da quel che ho capito, vuoi testare la sicurezza delle applicazioni php installate su uno spazio web gratuito. La sicurezza dello spazio web non è di tua competenza, quindi non puoi farci nulla. Per quanto riguarda gli script in PHP, basta informarsi sulle vulnerabilità conosciute e controllare che non siano presenti (o semplicemente aggiornare all'ultima versione disponibile).
Il port scan non ti serve

[IMMANUEL_KANT]

E' già un punto di partenza ma non è propriamente ciò che cerco.
Le vulnerabilità conosciute di una piattaforma come sono state a loro tempo rilevate?
Mi servirebbe ottenere dei report autonomamente...

[xdesign]

Le vulnerabilità sono di diverso tipo, quindi non c'è un unico metodo per rilevarle. Nel caso degli script si tratta solitamente di sviste nel codice, sfruttabili via browser. Non esistono scanners in grado di rilevarle autonomamente.

[IMMANUEL_KANT]

Ok... prendiamo la questione sotto un'altra ottica (sempre se non abuso della tua pazienza) .
Cosa è la solidità di un database? Si può testare?
2 db Mysql hanno la stessa vulnerabilità/solidità? O cambia, come credo da applicazione ad applicazione (che lo utilizza)?

[xdesign]

Ok

La sicurezza di un database (inteso come file contenente dei dati, non come applicazione) dipende da vari fattori.

Solitamente i database sono inseriti in una cartella non accessibile da un browser, ma solo da utenti autorizzati sul sistema (amministratore, processo di scripting, ecc). Inoltre alcuni sono protetti da password.

Nel caso che proponi, se esistono questi accorgimenti, e se il sever utilizza una versione di MySQL non buggata, la (in)sicurezza del DB può dipendere esclusivamente dallo script che lo utilizza.

Un esempio: due giorni fa è stata scoperta una vulnerabilità di postnuke.php, un addon per PHP Nuke. Questa falla permette di leggere i files sul sistema su cui è installato. Mettiamo caso che io uso questa falla per leggere i tuoi files di PHP Nuke, trovando il login di accesso al database. Ecco un sistema totalmente compromesso da un piccolo script in PHP

[IMMANUEL_KANT]

Finalmente un po' di luce!
Grazie mille.

Ti chiedo un'opinione. Come porteresti avanti un confronto tra piattaforme nuke-based?

[xdesign]

Un confronto per stabilire cosa?

[IMMANUEL_KANT]

Il confronto dovrebbe essere generale.
Riguardare:
-Sicurezza (e qui sono dolori)
-Usabilità (qui tutto ok. Sono abbastanza preparato ed ho tutti gli studenti che voglio per sottoporli a test di usabilità).
-Facilità di installazione (anche qui usabilità)
-Presenza di moduli, blocchi ecc. (si trova in rete).

A te chiedo come affronteresti il tema del confronto della sicurezza (a cui implicitamente però hai risposto).

Inoltre:
Se una piattaforma è diffusa, è più vulnerabile o lo è meno percheè ci sono molte correzioni di bug di sicurezza?

[xdesign]

Se si tratta di due script della stessa versione, installati sullo stesso server e con le medesime configurazioni, allora non c'è molto spazio per un confronto: è presumibile che il risultato sarà identico.
Al massimo potrai stabilire se i due script sono vulnerabli o meno, cercando exploit per quella versione specifica.

Se invece variano gli elementi oggettivi, il risultato può essere molto diverso. Basta infatti una falla per compromettere tutto il sistema.

Il discorso della diffusione è complesso. Solitamente la diffusione di una piattaforma va di pari passo con la sua qualità: più persone vedono il codice, maggiore è la probabilità che vengano scovati gli errori e le falle. Se è un prodotto a pagamento, probabilmente sarà più curato e più sicuro.
Ma esiste anche l'altra faccia della medaglia: se un hacker trova una falla importante potrebbe decidere di sfruttarla, invece che avvisare gli sviluppatori. In questo caso, avrebbe a disposizione migliaia di sistemi vulnerabili da attaccare.