Newsgroup: it.comp.www.php
Titolo: Sicurezza: chi è costui?

Questo thread, che spero si sviluppi il più possibile, prende spunto da
un'esigenza personale (quella di apprendere per diletto ;) php/mysql) e
dalla mia esperienza in ambito di programmazione "sicura".
Ho letto qualche post e mi sono reso conto che a volte, forse troppo
spesso, il grafico web, i programmatori più o meno web oriented, ovvero lo
studente, approciano la progettazione di siti/applicazioni senza tener
conto della sicurezza.
Non si tratta di paranoia, ma semplicemente di imparare a proteggere in
modo adeguato i dati di cui si dispone: non avrebbe senso usare
Blowfish/RSA per proteggere il db delle ricette della nonna, come anche
sarebbe necessario non memorizzare  le password in chiaro nel db (o
applicando banali algoritmi di shifting/permutazione etc.).
Esistono strumenti e funzioni (che penso siano implementate anche in php)
che possono dare una grossa mano a scoraggiare scriptkiddies, lamer ed
black hack alle prime armi.
Sarebbe bello poter iniziare una discussione sulle tematiche di sicurezza
legate al web, ai database, al flusso di dati
sicuro(autenticazione/autorizzazione), firma digitale, sistemi a chiave
simetrica, PKI.
L'argomento mi sembra più che mai vasto.
Se si potesse trarre, partendo da interessi personali, una mini-faq  che
raccolga link, esempi di codice (funzionante! ;) ) e spiegasse in modo
semplice e diretto le basi dell'argomento, ritengo potrebbe essere di
grande aiuto.
Getto lì qualche argomento per iniziare:
-Login (autenticazione a chiavi asimmetriche, autenticazione mediante
hashing md5, connessione al db, instanziare una sessione https)
-problemi di sql-injection, uso della register_globals = on (suggerite da
Chinaski FDB)
Si potrebbe, penso, andare all'infinito.
L'importante è che si arrivi ad una conclusione per ciascun tema
affrontato per concretizzare il "lavoro" fatto.
So di non essere praticamente mai apparso sul forum, e, forse, questo
thread può risultare pretenzioso, ma io la penso così: è come con Java,
c'è tutto quello che si vorrebbe per programmare, ma è un bagno di sangue
trovarlo ed organizzarlo.
Proviamo ad organizzare una mini-faq sull'argomento.
Ho lanciato il sasso...
..aspetto feedback.
Un saluto a tutti.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 hashing md5, connessione al db, instanziare una sessione https)
Provo ad aprire sull'argomento "Login" con i miei ricordi di Reti II, 
relativi soprattutto alla autenticazione HTTP.
Nelle sue prime versioni, il protocollo HTTP, essendo nato per la 
collaborazione dei gruppi di ricerca sparsi per il mondo, non teneva in 
considerazione il problema della sicurezza; tantomeno tali meccanismi 
erano presenti nei protocolli del TCP/IP.
Però l'interesse commerciale che offriva la rete ha decisamente cambiato 
la filosofia iniziale del progetto, portando all'introduzione, a livello 
HTTP, di alcuni meccanismi di autenticazione.
Nel protocollo HTTP/1.0 compare infatti la BASIC AUTHENTICATION, che 
fornisce l'accesso a informazioni private, sulla base di un meccanismo 
di gestione di password.
Sul server web vengono mantenuti in opportuni file di configurazione una 
liste di REALM (stringhe di testo rappresentanti porzioni di filesystem 
che si vogliono proteggere) e per ogni REALM una lista di utenti e 
relative password che possono accedervi.
Il processo funziona così:
Quando il client richiede una risorsa che appartiene ad un REALM, il 
server invece di restituire il documento, restituisce un messaggio fatto 
così:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="NomeRealm"
Server: .....
Date: .....
Content-type: .....
Content-length: 0
Di conseguenza sul client appare una finestra di dialogo che richiede 
all'utente l'immissione di username e password.
A seguito delle informazioni inserite dall'utente il client rinnova la 
sua richiesta al browser in questo modo:
GET url(la stessa di prima) HTTP/1.0
Authorization: Basic *****************
User-agent: .....
Accept: .....
ecc.
dove al posto degli *** vi è una codifica (codificata col metodo 
base64encoding) della coppia utente/password.
E' da notare che DI FATTO la coppia utente/password è come se viaggiasse 
in chiaro, dato che l'operazione eseguita su esse è una semplice 
codifica e non una cifratura. Và da se che chiunque sia in grado di 
intercettare tale richiesta (ad esempio un proxy interposto tra client e 
server) può agevolmente recuperare login e password inserite.
Quando il server riceve questa nuova richiesta applica la decodifica 
alla stringa, confronta utente/password con quelle in suo possesso e se 
combaciano restituisce il documento, altrimenti fornisce una pagina 
d'errore (403 FORBIDDEN).
Per ovviare al problema di tenere segrete utente/password, nel 
protocollo HTTP/1.1 si è introdotta la DIGEST AUTHENTICATION.
Quest'ultima funziona pressappoco come la BASIC, con la differenza che 
viene calcolata una funziona hash per "nascondere" i dati in transito.
Funziona così:
Quando il server riceve la richiesta per un documento che deve essere 
protetto, invia al client un valore detto NONCE che è ogni volta diverso.
Il client nuovamente fà apparira la finestra di dialogo per 
l'inserimento di utente/password, ma stavolta invece di inviarle in 
codifica base64encoding, esegue una funzione chiamata MD5 basata su:
- il NONCE inviato dal server
- il nome utente
- la password
La funzione MD5 è una funzione hash che è facile da calcolare, ma molto 
difficile da invertire.
Il server calcola anche lui MD5 su username/password/nonce e li 
confronta con quelli ricevuti dal client.
Se è tutto OK restituisce il documento, altrimenti un messaggio d'errore 
(403 forbidden).
Con questo si chiude la trattazione dell'argomento autenticazione HTTP, 
se riesco a mettere insieme qualche riga di codice per spiegare meglio 
con esempi li posterò in seguito.
Ciao
Alesi_27

Mi contatti in privato, per favore? 
a_b_o_n_d_i@i_j_k.it
ovviamente, senza gli underscore.... dato che

 Alesi_27
Wow, bellissimo :D
Ma semplicemente a chi programma che cambia?
cioč, per usare questa codifica che bisogna fare?
Io uso la codifica md5 solo quando salvo la password nei cookies
(praticamente salvo un md5 di password+stringa definita da me, e poi faccio
lo stesso per la pass nel db).
Grazie, fossero tutti cosě i post che si leggono in giro :)

 cioè, per usare questa codifica che bisogna fare?
Devi sfruttare le funzione Header di PHP e far mandare un richiesta di 
login verso il client.
Un esempio di come fare puoi trovarlo qui:
http://www.xiven.com/blog-data/auth_source.php
ciao
alesi_27

> problemi di sql-injection
a proposito di sql-injection, ho fatto delle prove ma non sono riuscito a
trovare vulnerabilitŕ nel pacchetto php/mysql, il che ovviamente non vuol
dire che non ci sono ma solo che non sono molto abile.
sul sito di mysql ci sono alcune raccomandazioni generali (in inglese) che
incollo qui:
Do not keep any plain-text passwords in your database. When your computer
becomes compromised, the intruder can take the full list of passwords and
use them. Instead use MD5(), SHA1() or another one-way hashing function.
Do not ever give anyone (except the mysql root user) access to the user
table in the mysql database! This is critical. The encrypted password is
the real password in MySQL. Anyone who knows the password which is listed
in the user table and has access to the host listed for the account can
easily log in as that user.
(questo č curioso, raccomandano di non mettere password in chiaro nel db
ma loro lo fanno! NdA)
Do not choose passwords from dictionaries. There are special programs to
break them. Even passwords like ``xfish98'' are very bad. Much better is
``duag98'' which contains the same word ``fish'' but typed one key to the
left on a standard QWERTY keyboard. Another method is to use ``Mhall''
which is taken from the first characters of each word in the sentence
``Mary had a little lamb.'' This is easy to remember and type, but
difficult to guess for someone who does not know it.
Do not trust any data entered by your users. They can try to trick your
code by entering special or escaped character sequences in web forms,
URLs, or whatever application you have built. Be sure that your
application remains secure if a user enters something like ``; DROP
DATABASE mysql;''. This is an extreme example, but large security leaks
and data loss may occur as a result of hackers using similar techniques,
if you do not prepare for them. Also remember to check numeric data. A
common mistake is to protect only strings. Sometimes people think that if
a database contains only publicly available data that it need not be
protected. This is incorrect. At least denial-of-service type attacks can
be performed on such databases. The simplest way to protect from this type
of attack is to use apostrophes around the numeric constants: SELECT *
FROM table WHERE ID='234' rather than SELECT * FROM table WHERE ID=234.
MySQL automatically converts this string to a number and strips all
non-numeric symbols from it.
Checklist:
o Try to enter `'' and `"' in all your web forms. If you get any kind of
MySQL error, investigate the problem right away.
o Try to modify any dynamic URLs by adding %22 (`"'), %23 (`#'), and %27
(`'') in the URL.
o Try to modify datatypes in dynamic URLs from numeric ones to character
ones containing characters from previous examples. Your application should
be safe against this and similar attacks.
o Try to enter characters, spaces, and special symbols instead of numbers
in numeric fields. Your application should remove them before passing them
to MySQL or your application should generate an error. Passing unchecked
values to MySQL is very dangerous!
o Check data sizes before passing them to MySQL.
o Consider having your application connect to the database using a
different user name than the one you use for administrative purposes. Do
not give your applications any more access privileges than they need. 
o Check out the addslashes() function. As of PHP 4.0.3, a
mysql_escape_string() function is available that is based on the function
of the same name in the MySQL C API. 
Do not transmit plain (unencrypted) data over the Internet. These data are
accessible to everyone who has the time and ability to intercept it and
use it for their own purposes. Instead, use an encrypted protocol such as
SSL or SSH. MySQL supports internal SSL connections as of Version 4.0.0.
SSH port-forwarding can be used to create an encrypted (and compressed)
tunnel for the communication.


 uso della register_globals = on
nelle ultime versioni di php register_globals è off di default.
register_globals = on può portare a problemi di sicurezza
links:
http://forums.devshed.com/t38817/s.html
http://216.239.59.104/search?q=cache:QjahCH2Jux4J:php.memphis.edu/download.php%3Fnode_id%3D46+register_globals+security&hl=en&ie=UTF-8
http://r2d2.evoknow.com/forums/index.php?showtopic=5
-- 
Chinaski FDB


 dalla mia esperienza in ambito di programmazione "sicura".
tutto veramente interessante, ma vogliamo parlare di cosa costa al 
cliente tutto questo lavoro?
In quali casi č auspicabile adottare tecniche di questo genere?
E della sicurezza delle strutture, non solo quelle della comunicazione?
Se entro nel DB, magari come utente root, che mi frega delle password 
ultra protette quando posso leggere tutti i dati come voglio? Cripto 
pure tutti i dati?
Ritengo che questo tipo di discussioni tecniche andrebbero affrontate 
contestualizzando un minimo l'ambito di utilizzo... avrebbe senso 
criptare tutti i dati di un forum pubblico?
Non č polemica, mi interesso anche io di sicurezza per lavoro, e la 
prima cosa che bisogna chiedersi č sempre il rapporto prezzo/vantaggi.
Ciao Gianfranzo
-- 
ICQ#: 21258924 Nick Gianfranzo
Home page 
http://www.gianfranzo.it
Gianfranzo č contro la guerra
"dopo tutto, gli angeli non sono altro che dei volatili" D. Pennac

 prima cosa che bisogna chiedersi è sempre il rapporto prezzo/vantaggi.
Infatti ho scritto:
------
Non si tratta di paranoia, ma semplicemente di imparare a proteggere in
modo adeguato i dati di cui si dispone: non avrebbe senso usare
Blowfish/RSA per proteggere il db delle ricette della nonna, come anche
sarebbe necessario non memorizzare le password in chiaro nel db (o
applicando banali algoritmi di shifting/permutazione etc.).
-------
;)


Inoltre l'idea mia era quella di affrontare la tematica di sicurezza in
php per capire come fare quello che so fare, in un linguaggio per il web.
Tutto qui.
Ciao


 Ciao
non lo metto in dubbio, ho sottolineato che non volevo fare polemica 
appositamente.
In questo NG scrivono persone più esperte e "novizi" chiarire che alcune 
tematiche vanno affrontate con uno studio a priori e non a botte di 
codice è doveroso.
A volte l'esperienza (o lo studio) determinano un modo di procedere, il 
tema proposto è *molto* interessante e utile, anche a solo livello di 
conversazione (IMHO), come in molti avete già detto è un tema ampio e 
complesso e, almeno per quelli che ne sentono parlare la prima volta, 
andrebbero definite anche delle linee guida per affrontare il problema, 
oltre che giustamente le tecniche per risolverlo.
Per le "ricette della nonna", tanto per fare un esempio potrebbe essere 
non interessante la "sicurezza" delle password quanto quella dei dati. 
Come determinare quale è il livello di sicurezza da garantire è forse un 
problema più spinoso di quale tecnica adottare, volevo solo far presente 
questo aspetto.
Ritengo (e non solo io) che la sicurezza delle comunicazioni sia un tema 
a volte secondario rispetto a quello della sicurezza dei sistemi...
In una trattazione,spero di ampio respiro,  bisogna accennare anche a 
questi aspetti, anche se in questo contesto (icwp) è chiaro che è più IT 
parlare delle tecniche da adottare sulla comunicazione che sui sistemi.
(il defacing dei siti, sempre più frequente anche in siti "commerciali e 
sicuri", ne è la riprova)
Ciao Gianfranzo
-- 
ICQ#: 21258924 Nick Gianfranzo
Home page 
http://www.gianfranzo.it
Gianfranzo è contro la guerra


Per chi deve proteggere qualcosa di piu' importante delle ricette della
nonna, segnalo
Practical Cryptography
Schneier - Ferguson.
Uno dei migliori libri sull'argomento che abbia mai letto, decisamente piu'
utile anche della "bibbia" Applied Cryptography, sempre di Schneier che e'
molto teorica
Spiega i motivi alla base della scelta degli algoritmi, spiega la differenza
(non e' banale ...) fra cifrare i propri dati e progettare un sistema di
sicurezza (il primo e' un sottoinsieme del secondo, ma molti pensano che
"uso della crittografia=sicurezza").
Il taglio e' molto pratico, solo il capitolo sui numeri primi contiene un po
di algebra.
Il libro non contiene descrizioni dettagliate degli algoritmi che propone,
perche' queste si trovano facilmente online.
Spiega invece come usare in sicurezza la crittografia, come costruire un
canale sicuro, come scambiare una chiave su un canale non sicuro, come
scrivere il codice in maniera "crittograficamente sicura" (qui l'autore
poteva forse sprecarsi un po di piu'), come mettere in piedi una PKI
A mio parere, un libro di lettura obbligatoria per chi si vuole occupare
attivamente di queste cose!
Segnalo il link
http://btobsearch.barnesandnoble.com/booksearch/isbnInquiry.asp?btob=Y&isbn=0471223573&itm=1
Ciao
Mauro