View Full Version : Sicurezza sui siti
Stiwy.NET
27-11-2006, 09:36
Ciao,
mi è stato chiesto di fare un sito in asp.net 2.0 e di modificarne un'altro in php. Non ho grossi ostacoli per quanto riguarda la sintassi o il metodo con cui sviluppare, ma mi è stato chiesto di farli molto "sicuri". So che è un argomento molto complesso e qualcosa so già, ma vorrei da voi dei consigli su come evitare di fare errori. Ad esempio so che nelle stringhe sql è meglio usare i parametri per evitare le sqlinjection. Mi è stato chiesto di cryptrare le password in md5 o sha e controllare che le password inserite rispettino alcuni parametri di affidabilità (minimo 5 caratteri, almeno 1 lettera e 1 numero e 1 carattere speciale).
Cos'altro potrei fare? Quali sono le ultime tecniche per stare un pò tranquilli?
Aggiungerei di criptare le password già a livello client con sha1 (javascript) (http://www.pajhome.org.uk/crypt/md5/sha1.js)
edit: la sintassi é semplice:
<script language="JavaScript">
stringa = hex_sha1("stringa da criptare");
</script>
giannola
27-11-2006, 10:26
Ciao,
mi è stato chiesto di fare un sito in asp.net 2.0 e di modificarne un'altro in php. Non ho grossi ostacoli per quanto riguarda la sintassi o il metodo con cui sviluppare, ma mi è stato chiesto di farli molto "sicuri". So che è un argomento molto complesso e qualcosa so già, ma vorrei da voi dei consigli su come evitare di fare errori. Ad esempio so che nelle stringhe sql è meglio usare i parametri per evitare le sqlinjection. Mi è stato chiesto di cryptrare le password in md5 o sha e controllare che le password inserite rispettino alcuni parametri di affidabilità (minimo 5 caratteri, almeno 1 lettera e 1 numero e 1 carattere speciale).
Cos'altro potrei fare? Quali sono le ultime tecniche per stare un pò tranquilli?
nessuna.
non esiste e non esisterà mai un sito sicuro: è un problema non decidibile.
Questa è una delle cose che si imparano ad ingegneria.
L'unica cosa che puoi fare è usare le tecniche a tua disposizione e tenerti informato riguardo le falle nella sicurezza che vengono via via scoperte. ;)
Stiwy.NET
27-11-2006, 10:45
nessuna.
non esiste e non esisterà mai un sito sicuro: è un problema non decidibile.
Questa è una delle cose che si imparano ad ingegneria.
L'unica cosa che puoi fare è usare le tecniche a tua disposizione e tenerti informato riguardo le falle nella sicurezza che vengono via via scoperte. ;)
Se è questo che insegnano sono contento di essermi fermato alle superiori... dai per favore... lo sanno tutti che non è possibile fare un sito completamente sicuro, ma si possono adottare delle tecniche e degli accorgimenti per evitare falle più o meno grandi. Ad esempio l'utente php non ha diritto di scrittura nelle cartelle del sito, può solo eseguire il suo codice e basta. In quelle cartelle non è possibile avviare eseguibili etc...
La mia domanda è...
"oltre a dire session("livelloutente") = "admin" posso fare altri controlli?"
Aggiungerei di criptare le password già a livello client con sha1 (javascript) (http://www.pajhome.org.uk/crypt/md5/sha1.js)
edit: la sintassi é semplice:
<script language="JavaScript">
stringa = hex_sha1("stringa da criptare");
</script>
Guarda, mi lascia alquanto dubbioso una soluzione del genere...
Facendo lo sha1 della password hai lo stesso livello di sicurezza rispetto ad inviare la password in chiaro...
Semmai sarebbe un minimo più sicuro fare cleint side l'hash della password insieme ad un codice generato casualmente. Lo stesso hash lo metti nella sessione e così puoi fare il confronto fra l'hash server side e client side. E questo cofnronto ha validità solo per quella istanza della form.
mad_hhatter
27-11-2006, 18:40
Facendo lo sha1 della password hai lo stesso livello di sicurezza rispetto ad inviare la password in chiaro...
Perchè con sha1 è troppo facile trovare collisioni, perchè è reversibile, o cos'altro?
Semmai sarebbe un minimo più sicuro fare cleint side l'hash della password insieme ad un codice generato casualmente. Lo stesso hash lo metti nella sessione e così puoi fare il confronto fra l'hash server side e client side. E questo cofnronto ha validità solo per quella istanza della form.
e come ci si mette d'accordo sul codice ausiliario tra server e client?
scusa le domande, ma non ne so quasi niente di ste cose e vorrei iniziare a capirci qualcosina
mad_hhatter
27-11-2006, 18:41
e come ci si mette d'accordo sul codice ausiliario tra server e client?
scusa le domande, ma non ne so quasi niente di ste cose e vorrei iniziare a capirci qualcosina
per caso è il server che invia il codice al client? e se si, come, in chiaro?
per caso è il server che invia il codice al client? e se si, come, in chiaro?
Sì...in chiaro... Non è un metodo sicuro, ma se non altro "ascoltando" soltanto la l'invio della form non si è in grado di carpire alcuna informazione segreta...
Guarda, mi lascia alquanto dubbioso una soluzione del genere...
Facendo lo sha1 della password hai lo stesso livello di sicurezza rispetto ad inviare la password in chiaro...
Semmai sarebbe un minimo più sicuro fare cleint side l'hash della password insieme ad un codice generato casualmente. Lo stesso hash lo metti nella sessione e così puoi fare il confronto fra l'hash server side e client side. E questo cofnronto ha validità solo per quella istanza della form.
Scusa, io ragionavo ad ajax inviando il form tramite quello :)
intendevo farlo lato client...
Ad esempio con una roba tipo
<script language="JavaScript">
function controlla(){
password = hex_sha1(document.getElementById('password').value);
// Invia tramite ajax la password
}
</script>
<input type="password" id="password" name="password">
<input type="button" onClick="controlla();">
Perchè con sha1 è troppo facile trovare collisioni, perchè è reversibile, o cos'altro?
Perchè se la mia password è "pippo" lo sha1 sarà af7f864e23123debca7...e di fatto ha la stessa segretezza della password...
Se io carpisco ascoltando l'invio della form quel af7f864e23123debca7 è come se avessi la password...infatti successivamente mi basterà inviare af7f864e23123debca7 e mi sarò autenticato come te ;)
Con il codice condiviso fra client e server è più complicata la cosa perchè anche se l'avversario ha il codice (che è stato inviato in chiaro) comunque non ha la password perchè ce l'ha solo il client ;)
intendevo farlo lato client...
Ad esempio con una roba tipo
Come dicevo sopra non aggiunge alcuna sicurezza far passare il fingerprint al post della password in chiaro...perchè comunque riuscendo a prelevare il fingerprint posso autenticarmi lo stesso sul server inviando il fingerprint stesso...
Non ci avevo pensato, verissimo...e come fanno ad esempio su meebo.com?
Boh...chi lo sa, bisogna mettersi ad analizzare il sito...inoltre lì c'è anche un altro elemento importante... Bisogna vedere come è fatto il protocollo dell'IM... Se l'IM vuole la password in chairo non posso usare i fingerprints...
Se è questo che insegnano sono contento di essermi fermato alle superiori...
:D
La mia domanda è...
"oltre a dire session("livelloutente") = "admin" posso fare altri controlli?"
per quanto riguarda la trasmissione della password, senza scomodare l'SSL, non c'è molto da aggiungere a quello che ha detto cionci.
cambiando discorso invece,
come controlli i privilegi?
pagina per pagina?
hai una pagina che li controlla e poi reindirizza di conseguenza?
i link alle varie pagine li visualizzi sempre e comunque o li visualizzi solo quando un utente è abilitato?
magari questo può darti qualche spunto...
o magari no :fagiano:
'iao
l'SSL cos'é esattamente?
edit: scusate, google migliore amico dell'uomo (SSL (http://it.wikipedia.org/wiki/Secure_Sockets_Layer))
l'SSL cos'é esattamente?
edit: scusate, google migliore amico dell'uomo (SSL (http://it.wikipedia.org/wiki/Secure_Sockets_Layer))
SSL (http://it.wikipedia.org/wiki/SSL)
HTTPS (http://it.wikipedia.org/wiki/HTTPS)
XD sono più veloce di un fulmine a rispondere :D
SSL (http://it.wikipedia.org/wiki/SSL)
HTTPS (http://it.wikipedia.org/wiki/HTTPS)
Questo rallenta di molto la connessione però, vero?
L'ideale sarebbe non rendere l'autenticazione persistente (hai presente questo sito ?) tramite i cookie, ma se proprio lod evi fare...salva nei cookie un hash...potrebbe essere l'hash di qualcosa che te ti calcoli lato server... Ad esempio:
cookie = sha1("codice segreto".password.username.lastlogin)
In questo modo il cookie lo puoi cambiare ogni volta che crei una nuova sessione, in pratica ogni volta che al momento di validare l'utente lo trovi già in possesso del cookie... Ovviamente aggiorni anche il campo lastlogin...
Questa cosa ti permette di far cambiare ad ogni login il cookie di autenticazione... Non è il massimo, ma meglio di niente...
Senza contare che se un utente si trovasse non autenticato significa che qualcuno è entrato prima di lui con le sue credenziali (gli hanno fregato il cookie o semplicemente si è loggato da un altro PC o da un altro browser), quindi in teoria gli potresti proporre di cambiare la password invalidando automaticamente tutti gli altri cookie...
giannola
27-11-2006, 19:59
Se è questo che insegnano sono contento di essermi fermato alle superiori... dai per favore... lo sanno tutti che non è possibile fare un sito completamente sicuro, ma si possono adottare delle tecniche e degli accorgimenti per evitare falle più o meno grandi. Ad esempio l'utente php non ha diritto di scrittura nelle cartelle del sito, può solo eseguire il suo codice e basta. In quelle cartelle non è possibile avviare eseguibili etc...
La mia domanda è...
"oltre a dire session("livelloutente") = "admin" posso fare altri controlli?"
forse hai male interpretato, ho detto che puoi fare un sito quanto più possibile scevro da falle (conosciute) e sicuro (rispetto ad hacker dilettanti), ma è inutile che ti scomodi troppo a cercare la "soluzione definitiva" perchè di qua a domani la tua soluzione potrebbe nascondere una falla.
In ogni caso puoi provare a criptare i dati creando un tuo personalissimo algoritmo e autenticare l'utente veribicando il + possibile la correttezza dei dati inseriti.
Per il resto a meno che tu non possa fare una scansione retinica ed un analisi del dna non c'è molto altro che tu possa fare, nemmeno memorizzare il codice mac della scheda di rete. :D
P.S. in ogni caso quando all'uni si affermano cose che per te sono empiricamente note si suffragano anche dalle dimostrazioni, ti consiglio di dare un occhiatina al concetto di insiemi ricorsivamente enumerabili e di insiemi ricorsivi, giusto per capire perchè non esisteranno mai programmi in grado di verificare la correttezza di se stessi e di altri programmi. ;)
Stiwy.NET
28-11-2006, 07:44
:D
per quanto riguarda la trasmissione della password, senza scomodare l'SSL, non c'è molto da aggiungere a quello che ha detto cionci.
cambiando discorso invece,
come controlli i privilegi?
pagina per pagina?
hai una pagina che li controlla e poi reindirizza di conseguenza?
i link alle varie pagine li visualizzi sempre e comunque o li visualizzi solo quando un utente è abilitato?
magari questo può darti qualche spunto...
o magari no :fagiano:
'iao
I privilegi normalmente li controllo confrontando il livello di autorizzazione dell'utente con il livello richiesto dalla pagina (variabile ad inizio pagina che lo specifica). L'autorizzazione dell'utente è memorizzata su db e la memorizzo in una session durante la login.
Avevo anche pensato di usare un sistema un pò più complesso: inserisco in una tabella tutte le pagine del sito e ogni volta che vengono richiamate confronto il livello dell'utente con l'autorizzazione memorizzata su db. In definitiva non è molto diverso dall'altro sistema, però mi dà l'impressione di essere un pò più flessibile.
I link sono sempre in chiaro ed il controllo (come appena detto) lo faccio ogni volta che la pagina viene richiamata.
giannola probabilmente ho frainteso. Comunque a me basterebbe venire a conoscenza di metodi alternativi così da ampliare le mie conoscenze per fare un lavoro migliore. Magari facendo un mix di quello che mi state dicendo potrei tirare fuori qualcosa di buono.
Nel mio ultimo sito quando facevo il login (e il check di "ricordami" era flaggato) memorizzavo in un cookie la user e un codice. Questo codice lo memorizzavo nel db. Quindi quando l'utente apriva una qualunque pagina del sito controllavo l'esistenza di quel cookie, se c'era tentavo di fare il login automatico. Ogni volta il codice cambiava, quindi, o qualcuno copiava il cookie (ed entrare una volta sola) oppure non era possibile risalire alla password e, quindi, entrare.
Altri sistemi un pò più fantasiosi?
@ cionci:
Ritornando al discorso della criptazione lato client...
Cripto la password con sha1: 1234 diventa 242kljnk345ku3b45b4535,
l' hacker vede 242kljnk345ku3b45b4535, come fa ad inviare la stringa 242kljnk345ku3b45b4535 se lato server si fa il controllo della lunghezza e/o dalla pagina da cui proviene? (che con sha1 se non erro é sempre di 40 caratteri)
Questa cosa è molto interessante. Dal mio lato non ho molto da condividere, l'unica cosa che ho fatto, avendo messo online una pagina in .asp per dei clienti con accesso tramite User e Password, è stata quella di usare il mio serverweb interno aziendale con accesso ad esso tramite autenticazione user e password di windows nt. Cosi sulla pagina home del sito web viene rimandato all'ip fisso e porta aperta sul firewall aziendale con accesso al server web, e la prima cosa che chiede e lo user e pwd con autenticazione di windows nt, poi in base all'utente connesso visualizzo i dati che gli servono. Non sò sinceramente quanto sia sicura, leggendo in giro già questa autenticazione dovrebbe risultare protetta, ma non sono entrato in dettaglio, anche perchè le informazioni che mostro non è che siano chissà che, comunque un minimo di sicurezza la devo avere.
Ah, ho usato il barbatrucco del frame, in modo che sulla barra indirizzi non si veda nessuna pagina di navigazione , rimanendo fissa sulla home page del sito web. E se scarico o visualizzo il codice html vedo solo il codice del frame. Niente di chè , solo una cosa puramente ... estetica :D
Stiwy.NET
28-11-2006, 10:40
Questa cosa è molto interessante. Dal mio lato non ho molto da condividere, l'unica cosa che ho fatto, avendo messo online una pagina in .asp per dei clienti con accesso tramite User e Password, è stata quella di usare il mio serverweb interno aziendale con accesso ad esso tramite autenticazione user e password di windows nt. Cosi sulla pagina home del sito web viene rimandato all'ip fisso e porta aperta sul firewall aziendale con accesso al server web, e la prima cosa che chiede e lo user e pwd con autenticazione di windows nt, poi in base all'utente connesso visualizzo i dati che gli servono. Non sò sinceramente quanto sia sicura, leggendo in giro già questa autenticazione dovrebbe risultare protetta, ma non sono entrato in dettaglio, anche perchè le informazioni che mostro non è che siano chissà che, comunque un minimo di sicurezza la devo avere.
Il problema di questo sistema è che devi creare tanti utenti di windows nt quanti sono gli utenti a cui vuoi far fare il login...giusto? mi sembra improponibile.
@ cionci:
Ritornando al discorso della criptazione lato client...
Cripto la password con sha1: 1234 diventa 242kljnk345ku3b45b4535,
l' hacker vede 242kljnk345ku3b45b4535, come fa ad inviare la stringa 242kljnk345ku3b45b4535 se lato server si fa il controllo della lunghezza e/o dalla pagina da cui proviene? (che con sha1 se non erro é sempre di 40 caratteri)
Ad esempio tramite spoofing e spedendola nel momento in cui il client è nella pagina giusta... Se controlli il referer basta semplicemente duplicare anche il referer...
Edit: pensa di spedire la password in chiaro invece del fingerprint...cambia qualcosa rispetto a quello che hai aggiunto dopo ?
Crashbandy80
28-11-2006, 10:48
Edit : letto male.. devo ancora svegliarmi stamattina :D
Se controlli il referer basta semplicemente duplicare anche il referer...
in che senso?
Il problema di questo sistema è che devi creare tanti utenti di windows nt quanti sono gli utenti a cui vuoi far fare il login...giusto? mi sembra improponibile.
Bhè si , per forza. Cosa cambia scusa ? Nell'altro caso dovrai inserire nel database tante user e pwd quanti sono gli utenti che vogliono loggarsi... :confused:
Stiwy.NET
29-11-2006, 07:19
Bhè si , per forza. Cosa cambia scusa ? Nell'altro caso dovrai inserire nel database tante user e pwd quanti sono gli utenti che vogliono loggarsi... :confused:
Cosa cambia? azz è un lavoro immane considerando che noi siamo + o - 100 utenti (45 attivi). Senza contare che non sono amministratore e che, quindi, dovrei chiedere autorizzazioni ai tecnici. no, non è una soluzione attuabile. E' troppo rigida. Andrebbe bene per poter lavorare in terminal server, ma non per fare un sito.
Cosa cambia? azz è un lavoro immane considerando che noi siamo + o - 100 utenti (45 attivi). Senza contare che non sono amministratore e che, quindi, dovrei chiedere autorizzazioni ai tecnici. no, non è una soluzione attuabile. E' troppo rigida. Andrebbe bene per poter lavorare in terminal server, ma non per fare un sito.
Che non hai l'autorizzazzione al web server ok è un problema, ma quello che volevo capire con il "cosa cambia" è : ok siete 100 utenti, da qualche parte dovrai inserirli , no ? a meno che sia una registrazione online (tipo quella dei forum)... ma non credo altrimenti che "sicurezza" dovrebbe avere se tutti si possono registrare fornendo una mail valida per esempio ?
Io non volevo dire che la mia soluzione sia la migliore, anzi, è quella che ho praticato per diversi motivi, in primis perchè nello spazio web che ho a disposizione non ho ancora un database di appoggio al sito, poi non posso usare i file .htaccess per regolare accessi tipo a cartelle perchè il provider preferisce configurarlo lui... e terza cosa... perchè ho meno di 5 clienti on line che devono accedere per adesso :D
Io, come altri, sono curioso di sapere le problematiche e diciamo le soluzioni migliori per quanto riguarda questa discussione :)
PS: ah per la cronaca, all'arrivo di un nuovo cliente il lavoro "immane" è: inserire una user e pwd e mandarlo al cliente, assegnandoli il gruppo di lavoro che può solo accedere al server web.
Stiwy.NET
29-11-2006, 16:57
Che non hai l'autorizzazzione al web server ok è un problema, ma quello che volevo capire con il "cosa cambia" è : ok siete 100 utenti, da qualche parte dovrai inserirli , no ? a meno che sia una registrazione online (tipo quella dei forum)... ma non credo altrimenti che "sicurezza" dovrebbe avere se tutti si possono registrare fornendo una mail valida per esempio ?
Io non volevo dire che la mia soluzione sia la migliore, anzi, è quella che ho praticato per diversi motivi, in primis perchè nello spazio web che ho a disposizione non ho ancora un database di appoggio al sito, poi non posso usare i file .htaccess per regolare accessi tipo a cartelle perchè il provider preferisce configurarlo lui... e terza cosa... perchè ho meno di 5 clienti on line che devono accedere per adesso :D
Io, come altri, sono curioso di sapere le problematiche e diciamo le soluzioni migliori per quanto riguarda questa discussione :)
PS: ah per la cronaca, all'arrivo di un nuovo cliente il lavoro "immane" è: inserire una user e pwd e mandarlo al cliente, assegnandoli il gruppo di lavoro che può solo accedere al server web.Vero vero... mmmhhh allora dobbiamo chiedere agli altri utenti... "Quali altri sistemi e trucchi si possono adottare?" :p
@ cionci:
Ritornando al discorso della criptazione lato client...
Cripto la password con sha1: 1234 diventa 242kljnk345ku3b45b4535,
l' hacker vede 242kljnk345ku3b45b4535, come fa ad inviare la stringa 242kljnk345ku3b45b4535 se lato server si fa il controllo della lunghezza e/o dalla pagina da cui proviene? (che con sha1 se non erro é sempre di 40 caratteri)
Cosa intendi per lunghezza e pagina di provenienza?
Cosa intendi per lunghezza e pagina di provenienza?
La quantità di caratteri... strlen
Pagina di provenienza intendo
$_SERVER['HTTP_REFERER'];
che il browser restituisce il nome della pagina precedente ma ho sentito ceh si può manomettere benissimo
Pagina di provenienza intendo
$_SERVER['HTTP_REFERER'];
che il browser restituisce il nome della pagina precedente ma ho sentito ceh si può manomettere benissimo
Come dicevo prima questa informazione può essere facilmente duplicata nell'header della richiesta http ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.