gdr vulnerabili

21/02/2010 20:05:10

Non pensavo di generare una discussione così ampia :)
Concordo con chi dice "è un gioco, non il sito di una banca".. sinceramente non mi interessa se un gdr con una o più decina di utenti si perde l'intero database alle spalle.
A mio parere però una sql injection nella pagina di login potrebbe essere evitata in pochi minuti mentre si scrive il codice. Qualcosa all'interno del sito può sfuggire per carità (per esempio il libero utilizzo di codici html e javascript?!?!?) ma la pagina più attaccabile all'entrata e la registrazione :D.. un minimo di attenzione

quota

21/02/2010 20:28:21 e modificato da ghennadi72 il 21/02/2010 20:32:13

Giusto. Il problema a monte é:
L'amministratore del sito (e quindi della land) deve essere un programmatore o avere a disposizione qualcuno fidato con analoghe competenze.
Insomma deve essere qualcuno in grado di capire facilmente (lui o per interposta persona) se il pacchetto OS che sta installando richiederà 1, 10 o 1000 correzioni solo per garantirsi un livello di sicurezza accettabile dati gli scopi della comunità.

In funzione di questo potrebbe anche decidere che rispetto all'utilizzo di un software buggato gli converrebbe scriverne uno di proprio pugno.

In ogni caso dati gli scopi di una land considero anch'io abbastanza irrealistico pensare di appoggiarsi a servizi e/o consulenze esterne per garantirsi un'analisi della sicurezza della propria land e un costante aggiornamento, soprattutto se il personale "consulente" lòo si viene a ricercare qui, tramite annunci.

Voglio dire, credo che non passi anno senza che questo o quello staff litighi, senza che questo o quello staff di quella land si separi drammaticamente, con gestori che "si portano via" codici, pezzi di database e dispettucci del genere... eppure c'è regolarmente chi ci casca e per risparmiare, magari, un mese di autoapprendimento o un mese di ricerca di un programmatore affidabile e del tutto fuori dal giro del PbC, prende scorciatoie inopportune e si mette in condizione di perdere mesi e mesi in recriminazioni su chi abbia diritto a "tenersi il codice" o il database utenti, o l'ambientazione.

In questo campo a mio parere quello che funziona meglio é il "fai da te". Ma un "fai da te con criterio".

---

quota

21/02/2010 20:40:49

Perfettamente d'accordo con te... in particolare la frase quotata

quota

21/02/2010 20:52:08 e modificato da vino_veritas il 21/02/2010 20:52:59

Esattamente... e per riallacciarmi al mio discorso, il senso di esso è proprio qui: nell'ambito del gdr-online, creare un cms pbc sicuro a mio parere sarebbe semplicemente un invito ai gestori a sbattersene le pelotas (esistono quelli che pubblicano land senza nemmeno modificare la struttura di base del gdr-cd, come possiamo non pensare che succeda anche per la sicurezza?). Visto che si tratta alla fin fine di giochi online, il livello adeguato di sicurezza può essere raggiunto in poco tempo dall'aspirante gestore; in tale maniera egli potrà capire realmente a quali rischi è sottoposto e le tecniche ottimali (e soprattutto PERSONALI) per la difesa. Se poi tale gestore non sa nemmeno cos'è una SQL Injection, perdonatemi, ma forse non è proprio adatto a gestire una land, e a dirla tutta non è nemmeno giusto che gli si forniscano i mezzi per combattere qualcosa che nemmeno conosce.

quota

21/02/2010 22:02:19

Su questo concordo fino a un certo punto. Supponiamo che anzichè il portale gdr-online questo fosse il portale da cui si scarica InvisionBoard, o Joomla, o MK-portal. Tu metteresti in download libero per gli utenti un cms buggato e vulnerabile all'SQL injection solo perchè, così per principio, chi installa un CMS dovrebbe sapere cos'é l'sql injection e come porvi rimedio da solo?

Idealmente, secondo me, l'OS scaricabile da questo portale dovrebbe essere utilizzabile dall'utente finale (alias il futuro gestore) senza dover avere necessariamente buone conoscenze di programmazione.

Il che significa seguire le regole di progettazione di un OS che ad esempio Oorazoroo ha seguito quando pubblicò accent. Un admin di Joomla che voglia personalizzare la grafica non é costretto a diventare un programmatore solo per orietarsi tra codice, template e stili css, e men che meno per correggere funzionalità basilari come il filtraggio degli input da parte degli utenti. Lo stesso dovrebbe accadere con un CMS per la gestione di una land virtuale.

Distinguiamo infatti tra la personalizzazione grafica (che non dovrebbe richiedere proprio alcuna competenza di programmazione) e la personalizzazione dell'interfaccia di gioco per inserire funzionalità non previste dal programmatore originario del pacchetto. Nel secondo caso é ovvio che o sai programmare, o sai programmare. Ma nel primo caso (ossia quello che va per la maggiore, in cui il gestore si limita a mettere in piedi un'ambientazione e ad adottare TUTTE le convenzioni più diffuse quanto a meccanica di gioco) non vedo proprio per quale motivo un gestore deve saper programmare.

Poi sappiamo tutti che qui non possiamo permetterci un livello di supporto a chi scarica un OS simile a quello garantito a chi scarica, che so, IPB, Joomla o Wordpress.

Ma rimuovere dal download libero i pacchetti notoriamente buggati a mio parere dovrebbe essere fatto a prescindere. Soprattutto dove la patch per correggere un particolare bug esiste già quindi andrebbe solo fatto lo sforzo di sovrascrivere le pagine/applicazioni buggate con quelle corrette.

Non ci vedo nulla di educativo o di "nobile" nel mettere a disposizione di un newbie-gestore un pacchetto buggato solo per fargli sbattere il muso sui bug e sfotterlo perchè non sa programmare quando ovviamente arriva qui disperato a chiedere aiuto perchè qualcuno gli ha brasato il database...

---

quota

Adattamento del Fantasy

Tesi dal titolo "L’adattamento del genere fantasy" di Francesca Dalla Bona

Le Quattro Terre

Ben due gdr, molto diversi tra loro ma entrambi inspirati alle opere del caro Terry Brooks

Lucca 2016

Breve riassunto sugli ospiti incontrati al Lucca Comics and Games 2016!

Apocalisse ArcheAge

Un apocalisse simulata: un mmorpg rivela come potremmo reagire alla fine del mondo!