Guardando in giro cosa il mondo IT ci offre quando cerchiamo un CMS ( Content Management Systems )
troviamo tante soluzioni GPL o meno...Quello che spesso pero' forse non ci rendiamo conto di
avere davanti ai nostri occhi e' una infinita' di sistemi con un design bene o male comune...

Un sistema CMS pare debba necessariamente funzionare nel seguente modo:

Server Web (Apache|Tomcat|IIS)
|
CMS <-- Accesso al CMS tramite sistema multi utente.
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite UserDB PasswordDB
|
Database CMS

-------------------
Fig. 1
-------------------

Cioe':

Le funzionalita' di un CMS si basano sulla possibilita' (giusta) di permettere ad
un certo gruppo di utenti privilegiati e non di accedere, modificare e inserire
contenuti all'interno di un DBMS (Database Management System), sia esso Mysql, Postgres, MSSql
e chi piu' ne ha piu' ne metta.

Questo tipo di struttura viene detta accesso multi utente.

Tali contenuti vengono cosi' pubblicati dal CMS e visualizzati dal browser di turno.

Per fare cio' il CMS e' strutturato in tabelle nel DB che permettono di organizzare il contenuto
per tipologie.

In particolare gli utenti sono che hanno accesso ai contenuti avranno a disposizione uno username
e una password che permettera' loro di agire su una categoria di dati.

Username, password e privilegi saranno immagazzinate in una tabella appartenente al DB del CMS.

Domanda: Dove e' l'errore?

NB: Per non incorrere in confusione chiamero' Utenti CMS gli utenti che hanno accesso a CMS e alle
funzioni amministrative sul contenuto e Utenti DB gli utenti che fisicamente accedono al DMBS.

Risposta: L'accesso multi utente e' ad un solo livello!

Se (e accade spesso) il CMS risulta avere una vulnerabilita' di tipoSQL injection,
il cracker che si approfittera' di tale
bug avra' a disposizione la tabella degli utenti CMS e quindi la possibilita' eventuale di
scoprire quali sono gli utenti piu' privilegiati e soprattutto le loro password...
Da questo momento in poi le possibilita' di movimento all'interno del DB aumentano in proporzione
a cio' che il CMS lascia fare sul DB e/o sul sistema una volta acquisita la password di amministratore
del CMS stesso.

La soluzione e il design.
Molti (quasi tutti) DBMS permettono di creare viste, accesso (non) privilegiato a tabelle e a
DataBase in maniera selettiva, a seconda dell'utente che vi accede (Granularita degli accessi).

Questo vuol dire che in un CMS che rispetti queste caratteristiche devono esistere almeno per due tipologie di utenti del DB.
Una amministrativa e uno generica.
Quella amministrativa dovra' essere quella che permettera' agli utenti CMS di accedere alle tabelle
di contenuto e di amministrazione (tabella utenti CMS) in inserimento, selezione e modifica.

Quella generica servira' a tutti coloro i quali si collegano col loro browser al CMS per visionare ( privilegi di SELECT) i contenuti del sito.

Quindi il design di un CMS secondo il sottoscritto dovrebbe essere il seguente:

Server Web (Apache|Tomcat|IIS)
|
CMS / Pagine per Visualizzazione
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite UserDB PasswordDB
| con Privilegi di Select sulle tabelle (viste|DB) dei contenuti
|
Database Contenuti

-------------------
Fig. 2
-------------------

Server Web (Apache|Tomcat|IIS)
|
CMS / Pagine per Amministrazione
|
Linguaggio di scripting (php|asp|perl)
|
DBMS <-- Accesso al DBMS tramite User2DB Password2DB
| con Privilegi di Modifica|Inserimento|Cancellazione
| sui DB (o tabelle) del CMS
|
Database CMS

------------------
Fig. 3
------------------

Cosa succede con un design di questo tipo?

Una SQL Injection non avra' effetto sulla tabella degli utenti CMS perche' l'utente DB di visualizzazione non
avra' accesso (neanche in SELECT) alla tabella degli utenti CMS.

Domanda: E se c'e' una SQL Injection nell'intefaccia di amministrazione?
Risposta: Vabbe'.....cambiate CMS.

Comments:

No comments yet.

Comments are disabled

Admin login | This weblog is from www.mylittlehomepage.net

Wisec - Un'Idea sviluppata e mantenuta da...

Wisec è scritto e mantenuto da Stefano Di Paola.

Wisec usa standard aperti, inclusi XHTML, PHP e CSS2.