Newsgroup: it.comp.www.php
Titolo: Php e sicurezza

Ciao a tutti e...BUONE FESTE!!!
    ...tanto ormai ci siamo, no? ;)
Volevo creare un'area amministrativa per un sito a cui sto lavorando, e
sarebbe bello poterla proteggere in qualche modo.
So che esistono vari metodi in Php per incrementare la sicurezza dei siti,
ma non mi sono mai documentato a riguardo.
Voi solitamente che metodi usate e/o ritenete validi?
Per il momento l'unica misura di controllo stà nel controllo di una
variabile di sessione (se il "livello" è settato come amministratore può
accedere, altrimenti viene sbattuto nella homepage), ma non mi sembra un
sistema molto professionale... : P
Aspetto le vostre risposte!
BUON NATALE!!!

 sistema molto professionale... : P
se il meccanismo a livelli lo chiamassi lista di capabilities o 
controlli di accessi ti sembrerebbe più "professionale"?
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

 wrote in message
news:br4mio$28nj1n$1...@ID-201944.news.uni-berlin.de...


 
non volevo prendere per il culo, però il meccanismo coi livelli di 
accesso è lo stesso con altri nomi più altisonanti, semmai la 
"professionalità" stà nella gestione dell'assegnamento e rilascio delle 
abilitazioni...


 wrote in message
news:br4tul$27s614$1...@ID-201944.news.uni-berlin.de...


 Comunque grazie ancora! :)
tutto o quasi è permesso, siamo qui per parlare e confrontarci, magari 
per imparare cose nuove oltre che risolvere problemi, non credi?
benissimo il tuo discorso, ma non prendi in giro nessuno:
diciamo che definisci 3 livelli di utente:
Amministratore; Operatore; Visitatore;
Diciamo che assegni 0,1,2 come livelli di accesso.
Ogni utente viene definito dalla sua anagrafica, da login e password e 
dal livello di accesso.
Per ogni livello di accesso TU definisci il set di operazioni consentite 
al tipo di utente che accede (e questo lo puoi fare in mille modi: con 
una tabella complicatissima o più semplicemente a livello di programma 
con i classici costrutti condizionali :)).
Questo significa creare una lista di capabilities: una 'funzione' e un 
'diritto' di usarla, per tutte le 'funzioni' disponibili sul tuo 
sito/applicativo...
A questo punto è corretto è 'sicuro' restringere l'accesso alle 
funzioni/pagine in base alle associazioni che hai creato tra utente e 
funzionalità operative (con il 'livello' come discrimine, per cui se non 
hai il livello giusto vieni sparato fuori in una pagina di errore, per 
esempio). Inoltre  puoi fare in modo che gli utenti di un 'livello' 
siano inconsapevoli delle operazioni che possono fare gli altri (basta 
per esempio generare dei menù differenziati per livello).
In questo caso separazione + protezione locale delle funzionalità/pagine 
disponibili forniscono il sistema di sicurezza.
Certo che se invece di utilizzare un DB, magari codici criptati e simili 
metti tutto in chiaro va tutto a farsi friggere, ma immagino che non sia 
il tuo caso.
Per esempio:
Diciamo che tu consenti di creare nuovi utenti nella amministrazione del 
tuo sito, dovrai prevedere un sistema che consenta di associare il 
livello all'utente creato (ovviamente è quasi banale fare questo).
Se l'operazione di creazione utente (e volendo modifica, elimina etc) è 
riservato al solo livello 0 (amministratore) gli altri utenti non 
potranno accedere, probabilmente non saranno neppure a conoscenza 
dell'esistenza della possibilità, alla sezione che permette di gestire 
gli utenti.
Ricordati, se consenti l'eliminazione degli utenti, di fare in modo che 
almeno un amministratore sia sempre attivo altrimenti il cliente la 
prima cosa che farà sarà eliminare l'unico amministratore esistente e 
chiederti come mai non rientra più nell'amministrazione del sito :)
Ovviamente non puoi pensare di passare con il metodo GET il livello di 
accesso, perché altrimenti siamo punto e a capo :)
Rimane il problema della sicurezza fisica del server, ma questo, se non 
sei tu l'amministratore delle risorse web in campo, non ti dovrebbe 
riguardare....
Ma a questo punto ho il dubbio di non aver capito quale è il tuo 
problema o dubbio di sicurezza...


 wrote in message
news:br52rr$28up74$1...@ID-201944.news.uni-berlin.de...


 Al limite ci si potrebbe documentare e mettere anche qualcosa nelle FAQ!
mannaggia RAPPERZ, cerca di quotare un pochetto meglio però, altrimenti 
non andiamo molto d'accordo... :)(si risponde sotto al messaggio e si 
tolgono le parti non utili alla discussione, nel nostro caso tutto il 
mio messaggio, non te la prendere, ma aiuta tutti seguire un pochetto di 
netiquette)
ok la cosa che dici è una ulteriore protezione degli accessi.
I server web possono (devono! per specifica) fornire un sistema di 
autentica per l'accesso al file sistem (tutto o parte) della webroot (è 
una sintesi non accurata, ma rende l'idea). Non sono un esperto di *nix 
o apache, nella maggioranza dei casi mi capita di lavorare in ambienti win.
Comunque la questione è questa: puoi specificare nel webserver (quindi 
dovresti poter accedere all'amministrazione della macchina) che una 
porzione del file system è accessibile solo a seguito di autentica da 
parte del server web che stai utilizzando. In pratica alla richiesta di 
un documento nella porzione protetta ti viene richiesta login e password 
  con un pop up (in genere). Come si faccia sotto apache non saprei 
dirtelo, ma se ci legge Setec o Jurgen (per esempio) vedrai che ti 
possono indicare la via per farlo, sotto IIS è piuttosto semplice 
(grazie all'interfaccia grafica :)).
Comunque se ci fai sapere che webserver usi/amministri vedrai che la 
soluzione arriva in un batter d'occhi :)
Bada che dovrai pensare un sistema che ti consenta di passare una 
autentica "automatica" da programma, altrimenti il tuo cliente dovrà 
inserire due volte login e password, una per il tuo meccanismo di 
accesso, la seconda per quello del server web, ti assicuro che 
preferiscono essere meno sicuri che dover fare 2 autenticazioni....


 possono indicare la via per farlo
Sotto apache la procedura standard è la creazione di un file .htaccess 
nella directory che vuoi proteggere, che va a puntare ad un file con 
utenti e password criptate, che conviene mettere fuori dalla 
DocuemntRoot e da ogni altra directory visibile via web server.
La sintassi è un po' lunghetta da spiegare qui, ma trovi la 
documentazione (ben fatta) qui:
http://httpd.apache.org/docs/howto/auth.html
http://httpd.apache.org/docs-2.0/howto/auth.html
il primo link è per apache 1.3.x, il secondo per apache 2.0.x
-- 
Ciao
Morsac

 preferiscono essere meno sicuri che dover fare 2 autenticazioni....
In effetti non ci avevo pensato...magari verrņ a disturbare il NG anche per
questo... : P

 documentazione (ben fatta) qui:
Grazie mille!!!

 controlli di accessi ti sembrerebbe più "professionale"?
esiste anche un altro problema che non viene affrontato l'accesso ai dati di
MySQL
normalmente i provider danno un db e un user
il problema e che danno solo un user (ADMIN) del db stesso, quindi
l'applicazione gira sempre
con i diritti di amministrazione del DB (alter, delete, upadate, insert,
create table, delete table..)
quindi in caso di sforo o errore in sql (SQL INJECTION) e' possibile
cuccarsi il db
o creare query apposite (a nessuno frega nulla se scarichi il programma
fatto spesso si tratta di phpnuke
o sistemi opensource) ma quello che PRUDE e che potrebbero fottersi il db
con i dati degli utenti e usarlo ad altri scopi (SPAMMING) o alterare la
struttura del db o suotarlo
quindi ci vorrebbere 2 utenti uno "admin" e uno usage (select insert update
delete)
e uno di struttura
altra cosa l'autenticazione (su apache)
se metto un upload in una dir protetta da pw e c'e' attivo il safe mode non
posso fare l'upload
nella dir pubblica
se per comodita voglio creare un upload di immagini o tutto (php compresi)
capirete che lasciare l'upload
nella dir pubblica scoccia parecchio
l'unica soluzione e' quella di fare un autenticazione a livello di script
(non che mi ispiri) con il controllo di sessione
come dice ~*~*~ RAPPERZ ~*~*~ , per il momento rimane l'unica soluzione
