Newsgroup: it.comp.www.php
Titolo: sito ultimato e consigli sulla sicurezza

Salve a tutti,
non credo di essere totalmente niubbo in php (almeno spero) ed ho 
realizzato un cms tutto mio. Mi trovo alla fase finale del lavoro, cioè 
quella della sicurezza!
Prima di leggermi la miriade di materiale raccolto negli ultimi tempi, 
volevo sapere se nel mio caso può essere utile usare la codifica in 
base64 e md5 di cui ho sentito tanto parlare.
A quanto ho capito la crittografia vera e propria è l'md5, mentre il 
base64 converte intere istruzioni o codice binario in testo. Giusto?
I punti a cui ho pensato di applicare l'md5 sono:
1- la password del pannello del cms che uso per inserire le notizie, 
anche se la mia diffidenza mi porta a non lasciare mai i files di 
gestione sul server del sito, caricandoli solo per inserire news e 
cancellandoli in seguito. Faccio bene? :-)
2- i valori del POST fatto dal motore di ricerca e che vengono in un 
secondo momento passati anche con il GET tra le varie pagine restando 
nell'url visibili e manipolabili da un malintenzionato.
Per il base64 mi chiedo che utilità possa trarne nel mio caso?
Tutte le news vengono memorizzate in chiaro nel database e tra una 
pagina e l'altra al massimo vengono passate 2-3 variabili numeriche in 
GET. Se la mia domanda è di una leggerezza impressionante, vi chiedo 
scusa e vi invito a rispondermi ugualmente. :-(
Avete altri suggerimenti per dove potrei applicare l'md5?
Tutte le variabili passate in get sono esclusivamente numeriche ad 
eccezione dei due casi sopra indicati pertanto non vedo il senso del 
codificarli. Non è inoltre il mio un sito di ecommerce, ma un semplice 
portale di informazione per modellisti e non avendo a che fare con 
aspetti economici o di chissà quale diabolico interesse non vorrei 
diventare paranoico oltre il dovuto.
Sperando di aiutare chi altri (come me) vuole dritte sulla sicurezza, 
dopo aver settato bene e filtrato i valori passati in get e post, 
cifrato i valori più delicati con md5, che altro consigliate di 
ritoccare contro gli 'scassinatori' di turno?
Ciao e grazie infinite.
Marco

 Per il base64 mi chiedo che utilità possa trarne nel mio caso?
il base64 è utilissimo se devi salvare in formato testuale qualcosa di
binario, come nel caso dovessi forgiare un'email con un'allegato di
posta (quindi un file di qualunque genere).
Puoi al limite creare una funzione crittografica che permetta la
decrittazione delle informazioni (sia che siano testi o file) che
manipoli un buffer dati in base64... ma non ne capisco la necessita.
Penso cmq che troverai molto in rete se fai delle ricerche a riguardo.
-- 
2T STUDIO - Sviluppo Web
  [web]   
http://www.2t-studio.com/ng
	- Sviluppo Siti e Applicativi Web Oriented Validati W3C
	- Consulenze SEO (Posizionamento motori di ricerca)

ritoccare contro gli 'scassinatori' di turno?
Mi pare che a questo punto tu sia messo bene - il problema grosso sta nel
filtraggio, e se riesci a limitarti a variabili intere lo semplifichi non
poco.
Leonardo
-- 
Geordie - he's a man, there's little doot about't,
He's done all he can, wha' can do withoot't?
Doon there cam a blade, linkin' like me lordie,
He wad drive a trade, a' the loom of Geordie.

Ciao ragazzi, ringrazio entrambi per le risposte.
x 2T STUDIO: Ti ringrazio per avermi chiarito le idee, intendo usare 
l'md5 per il pannello del cms perchè non voglio lasciare in chiaro la 
password nel file sorgente (v.l'esempio di Leonardo Serni di confrontare 
i valori).
x Leonardo Serni: leggo spesso i tuoi interventi, al riguardo se non 
sono indelicato vorrei contattarti in privato per una consulenza (a 
pagamento ovviamente) sul sorgente del mio sito. L'email che vedo 
sernil@.. etc è esatta?
Come detto quasi tutte le pagine si scambiano valori decimali con GET 
(usare post per ogni voce del classico 'main' menu di sinistra è un po' 
palloso o sbaglio?) il primo controllo che viene fatto infatti e con 
ctype_digit, dopo -come hai suggerito anche tu Leonardo- ogni caratttere 
del valore passato in GET viene confrontato con una serie di caratteri 
inseriti in un array (tra cui apici,#,<,> e compagnia bella). Se supera 
tutti i controlli accetta il parametro. Credo sia inattaccabile per chi 
vuole manomettere i contenuti delle variabili.. o no?
L'unico neo era appunto il motore di ricerca.
Ad es. dopo che ho immesso 'ciao amici' ho settato lo script del motore 
in modo da trasformarmelo in automatico in '+ciao* amici*' e passarlo 
alla query del database. Siccome non mi bastava una semplice elencazione 
dei risultati in una pagina ho aggiunto al tutto uno script di 
elencazione dei risultati in più pagine.
Il classico:
<< inizio <indietro   avanti> fine>>
Ora, se clicco su 'avanti' lo script 'dimentica' i parametri di ricerca, 
per ricordarglieli e mandarli alla pagina successiva uso GET:
<a href='index.php?val=+ciao* amici*'>avanti</a>
è qui che un malintenzionato potrebbe rompere, da qui le mie 
preoccupazioni a tenerli in chiaro.
Anche perchè come potrei usare POST in questo caso?
Spero di essere stato chiaro.
Grazie a entrambi e a chiunque vorrà aggiungersi al thread.
Marco

 
Se ho capito bene hai un textbox per il testo da ricercare e poi vuoi 
aggiungere i tasti per lo scorrimento delle pagine (stile google, per 
intendersi)
Passare a post non ti conviene, poichè avrai problemi con il tasto back 
del browser; per quanto riguarda la sicurezza, se la mia ipotesi 
iniziale è corretta, non hai problemi. Se il tizio ha fatto una ricerca 
per "gatto", nella querystring ci sarà gatto, se la cambia in cane, 
avrai cane come se avesse fatto la ricerca iniziale come cane.
Io eviterei caratteri particolari come il tuo esempio (+ciao* amici*), a 
quale scopo? Magari postresti utilizzare urlencode per "bonificare" il 
testo prima di passarlo via get
Ovviamente se la mia premessa iniziale è sbagliata, ignora il post
	Francesco

alla query del database.
Qui si entra gia' in un mondo meno bello :-) -- questo e' testo, e testo
che va in pasto al motore SQL. Andrebbe validato in modo piu' pesante, o
alterato in modo che eventuali sequenze comando vengano eliminate o rese
innocue, a scelta.
Ti conviene salvare la query in sessione, dopo averla validata, e, negli
URL di navigazione, mettere solo gli offset (interi).
Per la validazione potresti o usare le funzioni di serie (se esistono) o
brutalmente dire: io accetto solo testo, spazi e numeri; quindi vai giu'
di preg_replace /[^A-Za-z0-9 ]+/ => '', dopo eventualmente esplodi tutto
in parole singole e costruisci una LIKE o una REGEXP o quello che ti da'
il tuo motore DB.
A quel punto, i tuoi link diventano qualcosa come
	<a href="search.php?off=10">indietro</a>
	<a href="search.php?off=30">avanti</a>
Dato che per sapere quante pagine hai ti serve comunque l'avere fatto la
query all'inizio, se anche uno ti passasse off=9999999 fai presto a fare
il confronto con $_SESSION['tot_results'] e vedere che e' di fuori; dopo
di che a te la scelta... lo tratti male o silenziosamente lo sostituisci
con max(0,(floor($tot_results/$res_per_page)-1))*$res_per_page :-)


 
Perchè salvarle in sessione non lasciarle via GET?
Alla fine la stringa da cercare l'ha inserita precedentemente l'utente e 
un uso della sessione non ti dà nessuna sicurezza in più (l'unico 
vantaggio è rendere la vita difficile ad un simpaticone che con uno 
script idiota di grabba le ricercche, cosa leggermente più difficile se 
usi la sessione [1])
[1] "Il più difficile" è una riga in più di script!
	Francesco

 Leonardo
tutto chiaro.
Grazie ancora.
Marco

un uso della sessione non ti dà nessuna sicurezza in più
Sicurezza, no, e' vero. Vantaggi si': non devo rivalidarmela tutte le
volte.
Il mio approccio filosofico e' che, per mettere qualcosa in sessione,
questo deve essere stato validato; solo di quello mi fido. Cosi', nel
codice, se vedo un _REQUEST o un _SESSION, so se mi posso fidare o se
devo trattare il dato con le molle.


 testo prima di passarlo via get
non ho mai usato urlencode, avevo pensato di bonificare a posteriori il 
testo, ovvero dopo averlo ricevuto da GET.
La bonifica l'avrei fatta con riferimenti incrociati come detto a 
Leonardo, in tal modo se da '+ciao* amici*' il tizio mi fa '+ciao* 
<script>etc.' o qualunque altra diavoleria si inventa per darmi rogne il 
filtro mi eliminerebbe i due '>' '<' e male che vada cercherebbe 'ciao 
script'.
Che ne pensi, al di là di come procedersti al posto mio, lo ritieni 
comunque funzionale?

ma poi la query non è leggibile dal cookie di sessione?
No. Ma anche fosse, a te interessa che non sia _scrivibile_ .
Se anche l'utente riesce a recuperare la query che ha inserito LUI, mica
e' pelle del tuo naso :-)


 Leonardo
	Francesco

 No. Ma anche fosse, a te interessa che non sia _scrivibile_ .
non ho mai usato le sessioni oltre un certo livello e non mi sono mai 
chiesto se i cookies di sessione fossero modificabili dal visitatore.
Certo considerero' quanto mi dici anche se a questo punto la domanda 
sorge spontanea:
..e se un utente ha la ricezione dei cookies di sessione disabilitati 
dal browser? Il motore di ricerca va a farsi benedire?
Grazie.
Marco

 testo, ovvero dopo averlo ricevuto da GET.
Bonificare (tra virgolette) rendendoli digeribili alla querystring.
Le bonifiche per aspetti di sicurezza vanno sempre fatti come hai 
riportato negli altri post.
	Francesco

Nel tuo caso lo tratti come 1.
Ah, capito tutto. Ma questo e' un altro 'scope' ancora: sono campi a testo
libero. Li' e' utile una doppia validazione (javascript lato client, tanto
per bloccare il 99% dei distratti; e lato server, per bloccare l'1% di chi
ha JS disabilitato e/o e' marpione).
Un utente non dovrebbe avere mai la possibilita' di modificarsi un ID o un
parametro di ricerca manualmente, e *quelli* sono i campi da forzare.
Una data, per esempio, *non deve* essere validata a colpi di (int) perche'
qualsiasi errore verrebbe passato per "quasi valido" - come dici tu, il 1o
di gennaio diventerebbe il primo gennaio.
Eravamo fuori sintonia :-)


dal browser? Il motore di ricerca va a farsi benedire?
Il PHP ha anche il magic_rewrite degli URL, per cui se necessario l'ID di
sessione viene passato negli URL. Va attivato nel config, pero'.



molto utile al posto di urlencode che non passa cose particolari tipo
` - !@.,,|\# $%^&*()_":'  accettate in alcuni casi da windows
md5 e' inutile se non accompagnato da qualcosa.....
il tuo sistema e' 100% visibile dal provider e i tuoi dati pure
allora ti serve https
altra cosa
non credo che passi solo degli INT in get o post
ma e' utile usare un qualcosa che in caso di ambiguita' acetti
il valore se esiste
switch($_GET['dato']){
    case 0:
    echo "questo e' merda";
break;
   case 1:
    echo "questo e' buono";
break:
default:
    echo "nn so cosa mi dai quindi...";
break;
}
che sia un int 0 o una string "0" hai sempre lo stesso risultato, utile per
l'include
piu che altro controlla gli include e che __NON__ devono mai iniziare per
una variabile
include($variabile."/miofile.php");
tra i due c'e un abisso
include("./".$variabile."/miofile.php");