Qual è il modo migliore per impedire alle persone di hackerare la tabella dei punteggi più alti basata su PHP di un gioco Flash
https://stackoverflow.com/questions/73947
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sto parlando di un gioco d'azione senza limite massimo di punteggio e senza modo di verificare il punteggio sul server riproducendo mosse, ecc.
Ciò di cui ho veramente bisogno è la crittografia più potente possibile in Flash/PHP e un modo per impedire alle persone di chiamare la pagina PHP se non tramite il mio file Flash.In passato ho provato alcuni semplici metodi per effettuare più chiamate per un singolo punteggio e completare una sequenza di checksum/fibonacci, ecc., e anche per offuscare l'SWF con Amayeta SWF Encrypt, ma alla fine sono stati tutti violati.
Grazie alle risposte di StackOverflow ora ho trovato alcune informazioni in più da Adobe: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_12.html E https://github.com/mikechambers/as3corelib - che penso di poter usare per la crittografia.Non sono sicuro che questo mi aiuterà a aggirare CheatEngine.
Ho bisogno di conoscere le soluzioni migliori sia per AS2 che per AS3, se sono diverse.
I problemi principali sembrano essere cose come le intestazioni TamperData e LiveHTTP, ma capisco che ci siano anche strumenti di hacking più avanzati, come CheatEngine (grazie Mark Webster)
Soluzione
Questo è un classico problema con i giochi e i concorsi su Internet.Il tuo codice Flash collabora con gli utenti per decidere un punteggio per un gioco.Ma gli utenti non sono affidabili e il codice Flash viene eseguito sul computer dell'utente.Sei SOL.Non puoi fare nulla per impedire a un utente malintenzionato di falsificare punteggi elevati:
Flash è ancora più semplice da decodificare di quanto si possa pensare, poiché i bytecode sono ben documentati e descrivono un linguaggio di alto livello (Actionscript) --- quando pubblichi un gioco Flash, stai pubblicando il tuo codice sorgente, sia che tu saperlo o no.
Gli aggressori controllano la memoria di runtime dell'interprete Flash, in modo che chiunque sappia usare un debugger programmabile possa alterare qualsiasi variabile (incluso il punteggio corrente) in qualsiasi momento, o alterare il programma stesso.
L'attacco più semplice possibile contro il tuo sistema è eseguire il traffico HTTP per il gioco tramite un proxy, catturare il salvataggio del punteggio più alto e riprodurlo con un punteggio più alto.
Puoi provare a bloccare questo attacco legando ogni salvataggio del punteggio più alto a una singola istanza del gioco, ad esempio inviando un token crittografato al client all'avvio del gioco, che potrebbe assomigliare a:
hex-encoding( AES(secret-key-stored-only-on-server, timestamp, user-id, random-number))
(Potresti anche utilizzare un cookie di sessione con lo stesso effetto).
Il codice del gioco restituisce questo token al server con il salvataggio del punteggio più alto.Ma un utente malintenzionato può comunque semplicemente riavviare il gioco, ottenere un token e quindi incollarlo immediatamente in un salvataggio con punteggio elevato riprodotto.
Quindi successivamente inserisci non solo un token o un cookie di sessione, ma anche una chiave di sessione con crittografia ad alto punteggio.Questa sarà una chiave AES a 128 bit, a sua volta crittografata con una chiave codificata nel gioco Flash:
hex-encoding( AES(key-hardcoded-in-flash-game, random-128-bit-key))
Ora, prima che il gioco pubblichi il punteggio più alto, decodifica la chiave di sessione di crittografia del punteggio più alto, cosa che può fare perché hai codificato la chiave di decrittografia della chiave di sessione di crittografia del punteggio più alto nel binario Flash.Crittografi il punteggio più alto con questa chiave decrittografata, insieme all'hash SHA1 del punteggio più alto:
hex-encoding( AES(random-128-bit-key-from-above, high-score, SHA1(high-score)))
Il codice PHP sul server controlla il token per assicurarsi che la richiesta provenga da un'istanza di gioco valida, quindi decrittografa il punteggio più alto crittografato, controllando per assicurarsi che il punteggio più alto corrisponda allo SHA1 del punteggio più alto (se salti questo passaggio , la decrittazione produrrà semplicemente punteggi casuali, probabilmente molto alti).
Quindi ora l'aggressore decompila il tuo codice Flash e trova rapidamente il codice AES, che sporge come un pollice dolorante, anche se anche se non lo facesse verrebbe rintracciato in 15 minuti con una ricerca nella memoria e un tracciante ("Lo so il mio punteggio per questo gioco è 666, quindi troviamo 666 in memoria, quindi catturiamo qualsiasi operazione che tocchi quel valore --- oh guarda, il codice di crittografia del punteggio più alto!").Con la chiave di sessione l'aggressore non deve nemmeno eseguire il codice Flash;prende un token di avvio del gioco e una chiave di sessione e può inviare un punteggio elevato arbitrario.
Ora sei al punto in cui la maggior parte degli sviluppatori si arrende: più o meno un paio di mesi di problemi con gli aggressori:
Scrambling delle chiavi AES con operazioni XOR
Sostituzione di matrici di byte chiave con funzioni che calcolano la chiave
Diffusione di crittografie con chiavi false e messaggi con punteggi elevati in tutto il codice binario.
Tutto questo è soprattutto una perdita di tempo.Inutile dire che neanche SSL ti aiuterà;SSL non può proteggerti quando uno dei due endpoint SSL è dannoso.
Ecco alcune cose che possono effettivamente ridurre le frodi con punteggi elevati:
Richiedi un accesso per giocare, fai in modo che l'accesso produca un cookie di sessione e non consenti più lanci di giochi in sospeso nella stessa sessione o più sessioni simultanee per lo stesso utente.
Rifiuta i punteggi più alti delle sessioni di gioco che durano meno delle partite reali più brevi mai giocate (per un approccio più sofisticato, prova a "mettere in quarantena" i punteggi più alti per le sessioni di gioco che durano meno di 2 deviazioni standard al di sotto della durata media del gioco).Assicurati di monitorare la durata del gioco sul lato server.
Rifiutare o mettere in quarantena i punteggi più alti ottenuti da accessi che hanno giocato solo una o due volte, in modo che gli aggressori debbano produrre una "traccia cartacea" di gioco dall'aspetto ragionevole per ogni accesso che creano.
Punteggi "Heartbeat" durante il gioco, in modo che il tuo server veda la crescita del punteggio nel corso della durata di un gioco.Rifiuta i punteggi più alti che non seguono curve di punteggio ragionevoli (ad esempio, saltando da 0 a 999999).
Stato del gioco "Istantanea" durante il gioco (ad esempio, quantità di munizioni, posizione nel livello, ecc.), che potrai successivamente riconciliare con i punteggi provvisori registrati.Per cominciare, non è nemmeno necessario disporre di un modo per rilevare anomalie in questi dati;devi solo raccoglierlo e poi puoi tornare indietro e analizzarlo se le cose sembrano sospette.
Disabilita l'account di qualsiasi utente che non supera uno dei tuoi controlli di sicurezza (ad esempio, inviando un punteggio elevato crittografato che non supera la convalida).
Ricorda però che qui stai solo scoraggiando le frodi con punteggi elevati.C'è Niente puoi fare per prevenire se.Se ci sono soldi in gioco nel tuo gioco, qualcuno sconfiggerà qualsiasi sistema tu abbia ideato.L'obiettivo non è quello fermare questo attacco;è rendere l'attacco più costoso che semplicemente diventare davvero bravo nel gioco e batterlo.
Altri suggerimenti
Potresti fare la domanda sbagliata.Sembri concentrato sui metodi che le persone utilizzano per scalare la classifica dei punteggi più alti, ma bloccare metodi specifici non va oltre.Non ho esperienza con TamperData, quindi non posso parlarne.
La domanda che dovresti farti è:"Come posso verificare che i punteggi inviati siano validi e autentici?" Il modo specifico per farlo è dipendente dal gioco.Per i giochi puzzle molto semplici, potresti inviare il punteggio insieme allo stato iniziale specifico e alla sequenza di mosse che hanno portato allo stato finale, quindi eseguire nuovamente il gioco sul lato server utilizzando le stesse mosse.Confermare che il punteggio dichiarato sia lo stesso del punteggio calcolato e accettare il punteggio solo se corrisponde.
Un modo semplice per farlo sarebbe fornire un hash crittografico del valore del tuo punteggio più alto insieme al punteggio stesso.Ad esempio, quando si pubblicano i risultati tramite HTTP GET:http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095
Quando si calcola questo checksum, dovrebbe essere utilizzato un segreto condiviso;questo segreto non dovrebbe mai essere trasmesso in rete, ma dovrebbe essere codificato sia nel backend PHP che nel frontend flash.Il checksum sopra è stato creato anteponendo la stringa "segreto"al punteggio"500", ed eseguendolo tramite md5sum.
Sebbene questo sistema impedisca a un utente di pubblicare punteggi arbitrari, non impedisce un "attacco di replay", in cui un utente ripubblica un punteggio precedentemente calcolato e una combinazione di hash.Nell'esempio precedente, un punteggio pari a 500 produrrebbe sempre la stessa stringa hash.Parte di questo rischio può essere mitigato incorporando più informazioni (come nome utente, timestamp o indirizzo IP) nella stringa da sottoporre ad hashing.Sebbene ciò non impedisca la riproduzione dei dati, assicurerà che un set di dati sia valido solo per un singolo utente alla volta.
Impedire Qualunque che si verifichino attacchi di ripetizione, sarà necessario creare un qualche tipo di sistema di sfida-risposta, come il seguente:
- Il gioco flash ("il client") esegue un HTTP GET di http://example.com/highscores.php senza parametri.Questa pagina restituisce due valori:un generato casualmente sale valore e un hash crittografico di quel valore salt combinato con il segreto condiviso.Questo valore salt dovrebbe essere archiviato in un database locale di query in sospeso e dovrebbe avere un timestamp associato in modo che possa "scadere" dopo forse un minuto.
- Il gioco flash combina il valore salt con il segreto condiviso e calcola un hash per verificare che questo corrisponda a quello fornito dal server.Questo passaggio è necessario per impedire la manomissione dei valori salt da parte degli utenti, poiché verifica che il valore salt sia stato effettivamente generato dal server.
- Il gioco flash combina il valore salt con il segreto condiviso, il valore del punteggio più alto e qualsiasi altra informazione rilevante (nickname, ip, timestamp) e calcola un hash.Quindi invia queste informazioni al backend PHP tramite HTTP GET o POST, insieme al valore salt, al punteggio più alto e ad altre informazioni.
- Il server combina le informazioni ricevute allo stesso modo del client e calcola un hash per verificare che corrisponda a quello fornito dal client.Verifica quindi anche che il valore salt sia ancora valido come indicato nell'elenco delle query in sospeso.Se entrambe queste condizioni sono vere, scrive il punteggio più alto nella tabella dei punteggi più alti e restituisce al client un messaggio di "successo" firmato.Rimuove inoltre il valore salt dall'elenco delle query in sospeso.
Tieni presente che la sicurezza di una qualsiasi delle tecniche di cui sopra è compromessa se il segreto condiviso è accessibile all'utente
In alternativa, alcuni di questi avanti e indietro potrebbero essere evitati forzando il client a comunicare con il server tramite HTTPS e assicurando che il client sia preconfigurato per fidarsi solo dei certificati firmati da un'autorità di certificazione specifica a cui solo tu hai accesso. .
Mi piace quello che ha detto tpqf, ma invece di disabilitare un account quando viene scoperto un cheat, implementa un honeypot in modo che ogni volta che accedono, vedono i loro punteggi compromessi e non sospettano mai di essere stati contrassegnati come troll.Cerca "phpBB MOD Troll" e vedrai un approccio ingegnoso.
Nella risposta accettata tqbf afferma che puoi semplicemente eseguire una ricerca in memoria per la variabile del punteggio ("Il mio punteggio è 666 quindi cerco il numero 666 in memoria").
C'è un modo per aggirare questo problema.Ho una lezione qui: http://divillysausages.com/blog/safenumber_and_safeint
Fondamentalmente, hai un oggetto per memorizzare il tuo punteggio.Nel setter moltiplica il valore che gli passi con un numero casuale (+ e -), e nel getter dividi il valore salvato per il moltiplicatore casuale per ottenere indietro l'originale.È semplice, ma aiuta a fermare la ricerca nella memoria.
Inoltre, guarda il video di alcuni dei ragazzi dietro il motore PushButton che parlano di alcuni dei diversi modi in cui puoi combattere l'hacking: http://zaa.tv/2010/12/the-art-of-hacking-flash-games/.Erano l'ispirazione dietro la lezione.
Ho trovato una specie di soluzione alternativa...Ho avuto un dato in cui i punteggi aumentavano (ottieni sempre +1 punteggio).Innanzitutto, ho iniziato a contare da un numero casuale (diciamo 14) e quando visualizzo i punteggi, ho mostrato solo i punteggi var meno 14.In questo modo se i cracker cercano ad esempio 20, non lo troveranno (ce ne saranno 34 in memoria).In secondo luogo, poiché so quale dovrebbe essere il punto successivo...Ho utilizzato la libreria crittografica Adobe per creare l'hash del punto successivo dovrebbe essere.Quando devo incrementare i punteggi, controllo se l'hash dei punteggi incrementati è uguale a quello che dovrebbe essere.Se il cracker ha cambiato i punti della memoria, gli hash non sono uguali.Eseguo alcune verifiche lato server e quando ottengo punti diversi dal gioco e dal PHP, so che erano coinvolti imbrogli.Ecco lo snippet del mio codice (sto utilizzando la classe MD5 della libreria Adobe Crypto e il sale di crittografia casuale.callPhp() è la mia convalida lato server)
private function addPoint(event:Event = null):void{
trace("expectedHash: " + expectedHash + " || new hash: " + MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt) );
if(expectedHash == MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt)){
SCORES +=POINT;
callPhp();
expectedHash = MD5.hash( Number(SCORES + POINT).toString() + expectedHashSalt);
} else {
//trace("cheat engine usage");
}
}
Usando questa tecnica + l'offuscamento SWF, sono riuscito a fermare i cracker.Inoltre, quando invio i punteggi al lato server, utilizzo la mia piccola funzione di crittografia/decrittografia.Qualcosa del genere (codice lato server non incluso, ma puoi vedere l'algoritmo e scriverlo in PHP):
package {
import bassta.utils.Hash;
public class ScoresEncoder {
private static var ranChars:Array;
private static var charsTable:Hash;
public function ScoresEncoder() {
}
public static function init():void{
ranChars = String("qwertyuiopasdfghjklzxcvbnm").split("")
charsTable = new Hash({
"0": "x",
"1": "f",
"2": "q",
"3": "z",
"4": "a",
"5": "o",
"6": "n",
"7": "p",
"8": "w",
"9": "y"
});
}
public static function encodeScore(_s:Number):String{
var _fin:String = "";
var scores:String = addLeadingZeros(_s);
for(var i:uint = 0; i< scores.length; i++){
//trace( scores.charAt(i) + " - > " + charsTable[ scores.charAt(i) ] );
_fin += charsTable[ scores.charAt(i) ];
}
return _fin;
}
public static function decodeScore(_s:String):String{
var _fin:String = "";
var decoded:String = _s;
for(var i:uint = 0; i< decoded.length; i++){
//trace( decoded.charAt(i) + " - > " + charsTable.getKey( decoded.charAt(i) ) );
_fin += charsTable.getKey( decoded.charAt(i) );
}
return _fin;
}
public static function encodeScoreRand(_s:Number):String{
var _fin:String = "";
_fin += generateRandomChars(10) + encodeScore(_s) + generateRandomChars(3)
return _fin;
}
public static function decodeScoreRand(_s:String):Number{
var decodedString:String = _s;
var decoded:Number;
decodedString = decodedString.substring(10,13);
decodedString = decodeScore(decodedString);
decoded = Number(decodedString);
return decoded;
}
public static function generateRandomChars(_length:Number):String{
var newRandChars:String = "";
for(var i:uint = 0; i< _length; i++){
newRandChars+= ranChars[ Math.ceil( Math.random()*ranChars.length-1 )];
}
return newRandChars;
}
private static function addLeadingZeros(_s:Number):String{
var _fin:String;
if(_s < 10 ){
_fin = "00" + _s.toString();
}
if(_s >= 10 && _s < 99 ) {
_fin = "0" + _s.toString();
}
if(_s >= 100 ) {
_fin = _s.toString();
}
return _fin;
}
}//end
}
Quindi invio la variabile insieme ad altre false-var e si perde per strada...C'è molto lavoro da fare anche solo per un piccolo gioco flash, ma quando sono coinvolti i premi alcune persone diventano semplicemente avide.Se hai bisogno di aiuto, scrivimi un PM.
Saluti, Ico
La crittografia utilizzando una chiave reversibile nota (privata) sarebbe il metodo più semplice.Non sono esperto di AS, quindi non sono sicuro di quali tipi di provider di crittografia esistano.
Ma potresti includere variabili come la durata del gioco (crittografata, ancora una volta) e il conteggio dei clic.
Tutte cose così Potere essere sottoposto a reverse engineering, quindi considera l'idea di inserire un mucchio di dati spazzatura per allontanare le persone dall'odore.
Modificare:Potrebbe valere la pena inserire anche alcune sessioni PHP.Avvia la sessione quando fanno clic su Avvia gioco e (come dice il commento a questo post) registra l'ora.Quando inviano il punteggio puoi verificare che abbiano effettivamente una partita aperta e che non stiano inviando un punteggio troppo presto o troppo grande.
Potrebbe valere la pena elaborare uno scalare per vedere qual è il punteggio massimo per secondo/minuto di gioco.
Nessuna di queste cose è inevitabile, ma sarà utile avere una logica non in Flash dove le persone possono vederla.
Nella mia esperienza, è meglio affrontare questo problema come un problema di ingegneria sociale piuttosto che come un problema di programmazione.Invece di concentrarti sul rendere impossibile imbrogliare, concentrati sul renderlo noioso rimuovendo gli incentivi a imbrogliare.Ad esempio, se l'incentivo principale sono i punteggi più alti visibili pubblicamente, semplicemente ritardando la visualizzazione dei punteggi più alti è possibile ridurre significativamente gli imbrogli eliminando il ciclo di feedback positivo per gli imbroglioni.
Non puoi fidarti dei dati restituiti dal client.La convalida deve essere eseguita sul lato server.Non sono uno sviluppatore di giochi, ma realizzo software aziendale.In entrambi i casi può essere coinvolto denaro e le persone romperanno le tecniche di offuscamento lato client.
Forse inviare periodicamente i dati al server ed eseguire qualche convalida.Non concentrarti sul codice client, anche se è lì che risiede la tua applicazione.
Ogni volta che il tuo sistema di punteggi migliori si basa sul fatto che l'applicazione Flash invia dati dei punteggi migliori non criptati/non firmati attraverso la rete, questi possono essere intercettati e manipolati/riprodotti.La risposta segue da ciò:crittografare (decentemente!) o firmare crittograficamente i dati dei punteggi più alti.Questo, almeno, rende più difficile per le persone violare il tuo sistema di punteggi più alti perché dovranno estrarre la chiave segreta dal tuo file SWF.Molte persone probabilmente si arrenderanno proprio lì.D'altra parte, basta che una sola persona estragga la chiave e la affigga da qualche parte.
Le soluzioni reali implicano una maggiore comunicazione tra l'applicazione Flash e il database dei punteggi più alti in modo che quest'ultimo possa verificare che un determinato punteggio sia in qualche modo realistico.Questo probabilmente è complicato a seconda del tipo di gioco che hai.
Non c'è modo di renderlo completamente inattaccabile, poiché è facile decompilare i file SWF e un esperto hacker sviluppatore potrebbe quindi rintracciare il tuo codice e capire come aggirare qualsiasi sistema crittografato che potresti utilizzare.
Se vuoi semplicemente impedire ai bambini di imbrogliare tramite l'uso di strumenti semplici come TamperData, puoi generare una chiave di crittografia da passare all'SWF all'avvio.Quindi usa qualcosa di simile http://code.google.com/p/as3crypto/ per crittografare il punteggio più alto prima di restituirlo al codice PHP.Quindi decrittografarlo sul lato server prima di archiviarlo nel database.
Stai parlando di quello che viene chiamato il problema della "fiducia del cliente".Perché il client (in questo caso, un SWF in esecuzione in un browser) sta facendo qualcosa per cui è stato progettato.Salva un punteggio elevato.
Il problema è che vuoi assicurarti che le richieste di "salvataggio del punteggio" provengano dal tuo filmato flash e non da qualche richiesta HTTP arbitraria.Una possibile soluzione a questo problema è codificare un token generato dal server nell'SWF al momento della richiesta (utilizzando flasmo) che deve accompagnare la richiesta di salvataggio del punteggio più alto.Una volta che il server salva il punteggio, il token scade e non può più essere utilizzato per le richieste.
Lo svantaggio è che un utente sarà in grado di inviare solo un punteggio elevato per caricamento del filmato flash: è necessario costringerlo ad aggiornare/ricaricare l'SWF prima di poter riprodurre nuovamente per un nuovo punteggio.
Di solito includo i "dati fantasma" della sessione di gioco con la voce del punteggio più alto.Quindi, se sto realizzando un gioco di corse, includo i dati di replay.Spesso hai già i dati di replay per la funzionalità di replay o la funzionalità di corsa fantasma (giocando contro la tua ultima gara o giocando contro il fantasma del tizio n. 14 in classifica).
Controllarli è un lavoro molto manuale, ma se l'obiettivo è verificare se i primi 10 partecipanti a un concorso sono legittimi, questa può essere un'utile aggiunta all'arsenale di misure di sicurezza già segnalate da altri.
Se l'obiettivo è mantenere la lista dei punteggi più alti online fino alla fine dei tempi senza che nessuno debba guardarla, questo non ti porterà molto.
Il modo in cui lo fa un nuovo popolare mod arcade è che invia i dati da Flash a php, di nuovo a Flash (o lo ricarica), quindi di nuovo a php.Ciò ti consente di fare tutto ciò che desideri, confrontare i dati e anche ignorare gli hack post-dati/decrittografia e simili.Un modo per farlo è assegnare 2 valori casuali da php a flash (che non puoi catturare o vedere anche se si esegue un cattura dati flash in tempo reale), utilizzando una formula matematica per aggiungere il punteggio con i valori casuali, quindi controllandolo utilizzando la stessa formula per invertirla per vedere se il punteggio corrisponde a quello quando finalmente passa al php alla fine.Questi valori casuali non sono mai visibili, così come cronometrano anche la transazione in corso e se dura più di un paio di secondi, la contrassegnano anche come imbroglio perché presuppone che tu abbia interrotto l'invio per cercare di capire i valori casuali o eseguire i numeri attraverso un qualche tipo di cifratura per restituire possibili valori casuali da confrontare con il valore del punteggio.
Sembra una soluzione abbastanza buona se me lo chiedi, qualcuno vede qualche problema con l'utilizzo di questo metodo?O possibili modi per aggirarlo?
Penso che il modo più semplice sarebbe quello di effettuare chiamate a una funzione come RegisterScore(score) ogni volta che il gioco registra un punteggio da aggiungere e poi codificarlo, impacchettarlo e inviarlo a uno script php come stringa.Lo script php saprebbe come decodificarlo correttamente.Ciò interromperebbe qualsiasi chiamata diretta allo script php poiché qualsiasi tentativo di forzare un punteggio comporterebbe un errore di decompressione.
È possibile solo mantenendo il file tutta la logica del gioco sul lato server che memorizza anche il punteggio internamente all'insaputa dell'utente.Per ragioni economiche e scientifiche, l'umanità non può applicare questa teoria a tutti i tipi di gioco esclusi quelli a turni.Per es.mantenere la fisica sul lato server è computazionalmente costoso ed è difficile ottenere reattività come velocità di mano.Anche possibile, mentre si gioca a scacchi chiunque può abbinare il gameplay degli scacchi dell'IA all'avversario.Quindi, meglio giochi multigiocatore dovrebbe contenere anche creatività su richiesta.
Non è davvero possibile ottenere ciò che desideri.Gli interni dell'app Flash sono sempre parzialmente accessibili, soprattutto quando sai come usare cose come Motore di ricerca per le scorciatoie, il che significa che non importa quanto siano sicure le comunicazioni del tuo sito web e del tuo browser<->server, sarà comunque relativamente semplice da superare.
Potrebbe essere una buona idea comunicare con il backend tramite AMFPHP.Dovrebbe scoraggiare almeno i più pigri dal provare a spingere i risultati tramite la console del browser.
