GeckoFlag è un software che funziona sul Suo server. Affinché possa affidargli i dati dei Suoi progetti con tranquillità, lo sviluppatore esegue personalmente controlli di sicurezza a ogni release e pubblica su questa pagina i relativi contenuti e risultati.
Questa pagina documenta i controlli eseguiti dallo sviluppatore stessoNon si tratta di una certificazione o di un audit di un ente terzo. Poiché pubblichiamo anche che cosa viene controllato, La invitiamo a utilizzare queste informazioni come elemento di valutazione per l'adozione.
- Misure progettuali
- Controlli a ogni release
- Risultati dell'ultima versione
- Ambiti non controllati
- Segnalazione di vulnerabilità
- Verifica dei file distribuiti
- Impostazioni consigliate
Misure di sicurezza a livello di progettazione
GeckoFlag integra di serie le seguenti misure. Sono tutte attive senza alcuna configurazione.
Protezione delle password
Le password non vengono memorizzate in chiaro, ma come hash bcrypt. Anche i token per la reimpostazione della password vengono memorizzati come hash, e il numero di richieste di reimpostazione è limitato.
Limitazione dei tentativi di accesso
I tentativi di accesso non riusciti vengono conteggiati sia per account sia per indirizzo IP di origine; oltre una certa soglia, l'accesso viene temporaneamente limitato. Ciò contrasta gli attacchi di forza bruta e quelli rivolti a numerosi account.
Protezione CSRF
Ogni invio di modulo viene verificato tramite token, per impedire operazioni fraudolente avviate da siti esterni.
Protezione XSS
Il testo formattato di ticket, commenti, Wiki, note e altri contenuti viene salvato e visualizzato mantenendo solo i tag consentiti da HTML Purifier. Per i link sono consentiti solo http e https. Anche i testi generati dall'IA passano tutti attraverso lo stesso trattamento prima di essere salvati.
Protezione dalla SQL injection
Le operazioni sul database utilizzano l'ORM di CakePHP 5 e prepared statement.
Verifica dell'intestazione Host
I link inseriti nelle e-mail di reimpostazione della password, di invito e di notifica vengono generati a partire dal dominio registrato, non dall'intestazione Host della richiesta. Non è possibile sostituire i link nelle e-mail con indirizzi esterni tramite un'intestazione Host falsificata.
Archiviazione dei file
Le immagini dei ticket e i file dei progetti sono conservati al di fuori della cartella pubblica e vengono serviti solo dopo aver verificato che chi li visualizza sia membro del progetto. I file con estensioni eseguibili, come PHP, non vengono accettati.
Cifratura della chiave API
La chiave API di Claude per le funzioni di IA viene salvata nel database in forma cifrata.
Token API dell’integrazione con Claude
L’integrazione con Claude è disattivata per impostazione predefinita e si può usare solo se un amministratore la attiva e la consente per ciascun utente. Di ogni token API viene salvato solo un hash ed è possibile impostare una scadenza. Cambiando la password i token diventano non validi. L’API verifica gli stessi permessi delle schermate e i token di sola lettura non possono modificare nulla.
Restrizione per indirizzo IP
Gli amministratori possono limitare gli indirizzi IP da cui è consentito l'accesso.
Chiusura del programma di installazione
Una volta completata la configurazione, la schermata del programma di installazione non è più accessibile.
Protezione delle cartelle private
Con Apache, l'accesso diretto alle cartelle di configurazione, log, codice sorgente e simili viene negato di serie (con Nginx, consulti le impostazioni consigliate).
Backup automatico prima dell'aggiornamento
Prima di ogni aggiornamento del software viene creato automaticamente un backup.
Verifica della firma dei file di aggiornamento
I file di aggiornamento ufficiali recano la firma digitale dello sviluppatore (Ed25519). Prima dell'aggiornamento, la firma e il contenuto di tutti i file vengono verificati; i file manomessi e i file di aggiornamento non ufficiali non vengono applicati.
Verifica del caricamento delle immagini
Per le immagini come avatar, miniature e loghi, il formato viene determinato dal contenuto del file e il file viene salvato con un nome casuale. Dalle cartelle delle immagini non vengono serviti file diversi dalle immagini (con Apache). Il formato SVG non è accettato.
Intestazioni di sicurezza
Vengono inviate le intestazioni Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy, per prevenire il clickjacking e la fuga di informazioni verso siti esterni. Se il sito è in esercizio con HTTPS, viene inviata anche Strict-Transport-Security, in modo che il browser si connetta sempre tramite HTTPS.
Gestione delle sessioni
La sessione viene ricreata a ogni accesso. Le modifiche ai permessi, l'eliminazione di un account e la modifica della password si applicano immediatamente anche alle sessioni già aperte. Per modificare l'indirizzo e-mail e la password è necessario inserire la password attuale.
Controlli di sicurezza a ogni release
Prima di pubblicare una nuova versione, eseguiamo i controlli seguenti. I controlli vengono svolti in un ambiente di test con la stessa configurazione della produzione, mai su servizi in esercizio o sui server dei clienti. I controlli eseguiti sull'ultima versione sono riportati in «Risultati dei controlli dell'ultima versione».
| Categoria | Contenuto del controllo | Strumenti e riferimenti | Frequenza |
|---|---|---|---|
| Librerie dipendenti | Verifica dell'assenza di vulnerabilità note nelle librerie utilizzate e creazione dell'elenco delle librerie utilizzate (SBOM) | composer audit, OSV-Scanner, CycloneDX | A ogni release |
| Analisi statica | Individuazione nel codice sorgente dei percorsi attraverso cui i valori in ingresso raggiungono operazioni pericolose (XSS, SQL injection, ecc.) | Psalm (analisi taint), PHPStan (livello 5), Semgrep | A ogni release |
| Presenza di dati segreti | Verifica che password o chiavi API non siano presenti nel codice sorgente o nei file distribuiti | gitleaks | A ogni release |
| Scansione dinamica | Invio di richieste di attacco reali con accesso come amministratore e come utente normale, verificandone la risposta | Nuclei | A ogni release |
| Controllo dei permessi | Verifica che non sia possibile visualizzare o modificare ticket, file e note di progetti di cui non si è membri modificando l'ID nell'URL | Test automatici (PHPUnit), verifica manuale | A ogni release |
| Caricamento di file | Verifica che file eseguibili, file camuffati da immagini, ZIP che manipolano i percorsi e simili vengano rifiutati | Revisione del codice, verifica manuale | A ogni release |
| XSS | Inserimento di stringhe di attacco nella descrizione dei ticket, nei commenti, nel Wiki e nei testi generati dall'IA, verificando che nessuno script venga eseguito | Revisione del codice, verifica manuale | A ogni release |
| Verifica per configurazione del server | Verifica, per Apache e Nginx e per ciascuna disposizione della cartella pubblica, che non sia possibile accedere direttamente ai file di configurazione o ai log | Verifica manuale | A ogni release |
| Estensione dell’integrazione con Claude | Vulnerabilità note delle librerie usate dall’estensione, gestione del token API e limiti sulle destinazioni delle richieste | npm audit, gitleaks, revisione del codice | A ogni versione dell’estensione |
| Autovalutazione tramite checklist | Verifica voce per voce di autenticazione, sessioni, validazione dell'input, gestione degli errori e altro | Con riferimento a OWASP ASVS 5.0 livello 1, IPA (Giappone): «How to Secure Your Website» | A ogni versione principale |
| Sito ufficiale | Configurazione HTTPS e intestazioni di sicurezza di geckoflag.com | SSL Labs, Mozilla Observatory | Una volta al mese |
Se vengono rilevati problemi di gravità «alta» o «media», la release non viene pubblicata finché non sono stati corretti e ricontrollati. Per i problemi di gravità «bassa» ne esaminiamo il contenuto e li correggiamo oppure documentiamo il motivo per cui non hanno impatto.
Politica di aggiornamento delle librerie dipendenti
Le vulnerabilità note delle librerie utilizzate da GeckoFlag (come CakePHP) vengono verificate a ogni release. Se viene individuata una vulnerabilità che interessa GeckoFlag, pubblichiamo una versione correttiva indicativamente entro i seguenti tempi.
- Gravità «critica» e «alta»: entro 14 giorni dalla divulgazione
- Gravità «media»: entro 30 giorni dalla divulgazione
- Gravità «bassa»: con la release successiva (al più tardi entro 90 giorni)
Anche le vulnerabilità che non hanno impatto sul modo in cui GeckoFlag utilizza la libreria vengono risolte aggiornando a una versione corretta nella release successiva. Le librerie di sviluppo non sono incluse nei file distribuiti.
Risultati dei controlli dell'ultima versione: v1.11.0
Questi controlli hanno riguardato le modifiche dalla v1.10.0 (l’integrazione con Claude, i colori del testo e dello sfondo e i separatori nel testo formattato, ecc.) e hanno anche corretto problemi già presenti nelle versioni precedenti. Se usate la v1.10.0 o una versione precedente, consigliamo di aggiornare alla v1.11.0.
| Controllo | Strumenti (versione) | Rilevati (alta / media / bassa) | Intervento |
|---|---|---|---|
| Librerie dipendenti | GitHub Advisory Database, FriendsOfPHP security-advisories (dati al 2026-10-28; 89 pacchetti) | 0 / 0 / 0 | Nessuna vulnerabilità nota nelle librerie incluse nei file distribuiti. Le vulnerabilità note delle librerie di sviluppo sono state risolte aggiornandole nella v1.11.0 (le librerie di sviluppo non sono incluse nei file distribuiti) |
| Analisi statica e revisione del codice | Psalm 5.26.1 (analisi taint), PHPStan 2.1.17 (livello 5), Semgrep 1.182.1, revisione manuale del codice (modifiche dalla v1.10.0: API e token dell’integrazione con Claude, testo formattato, accesso persistente, aggiornamenti del software; oltre all’output dei link in tutte le schermate) | 1 / 1 / 3 | I problemi di gravità «alta» e «media» e 2 di quelli di gravità «bassa» sono stati corretti nella v1.11.0. Il problema «basso» rimanente si verifica solo tramite azioni dell’utente stesso e il suo impatto è risultato limitato. Il problema «alto» era già presente nelle versioni precedenti |
| Presenza di dati segreti | gitleaks 8.24.2 | 0 / 0 / 0 | Sono stati controllati sia il codice sorgente sia i file distribuiti. Entrambi i 2 rilevamenti erano falsi positivi (stringhe di esempio in librerie esterne, ecc.) |
| Verifica delle correzioni | Verifica del funzionamento nell'ambiente di test (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | Per ciascun rilievo, verificato che il problema precedente alla correzione non si riproduca |
| Scansione dinamica | Nuclei v3.11.1 (template v10.5.1), senza autenticazione e come amministratore e membro | 0 / 0 / 0 | Nessun problema |
| Controllo dei permessi | PHPUnit 12.5 (454 test automatici; oltre ai controlli precedenti, verificato che l’API dell’integrazione con Claude rifiuta le richieste senza token, con token di sola lettura, da utenti non autorizzati e con la funzione disattivata, e non raggiunge mai progetti di cui l’utente non fa parte) | 0 / 0 / 0 | Nessun problema |
| Verifica per configurazione del server | Manuale (Apache 2.4 e Nginx 1.24, 2 disposizioni della cartella pubblica; 39 URL tra file di configurazione, log, sessioni, file salvati, ecc.) | 0 / 0 / 1 | Corretto nella v1.11.0: l’accesso diretto alla cartella dei file delle versioni precedenti (files) ora viene rifiutato completamente anche su Apache. Nessun altro problema |
| Checklist | OWASP ASVS 5.0 livello 1 (70 voci) | Soddisfatte 50 delle 56 voci applicabili | Non rivista in questa occasione (resta valido il risultato della v1.10.0) |
| Estensione dell’integrazione con Claude | npm audit, gitleaks 8.24.2, mcpb validate, revisione manuale del codice (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | Nessuna vulnerabilità nota che riguardi le librerie incluse nel file distribuito. Verificati la gestione del token API e i limiti sulle destinazioni delle richieste (solo HTTPS, nessun reindirizzamento seguito) |
I risultati di tutte le versioni, comprese le precedenti, sono raccolti in «Risultati precedenti».
Ambiti non controllati
I controlli sopra descritti presentano i seguenti limiti. Se sta valutando l'adozione di GeckoFlag, La invitiamo a tenerne conto.
- Non sono stati effettuati controlli da parte di terzi.Al momento non sono state eseguite revisioni del codice sorgente né penetration test da parte di esperti esterni.
- L'ambiente server del cliente non rientra nei controlli.La sicurezza varia notevolmente in base alla configurazione e allo stato di aggiornamento del sistema operativo, del server web, di PHP e del database.
- Non sono stati verificati tutti gli ambienti di hosting.Le configurazioni controllate sono limitate a quelle indicate in «Risultati dei controlli dell'ultima versione».
- I servizi esterni sono esclusi.La sicurezza dell'API di Anthropic utilizzata dalle funzioni di IA, dell'app desktop di Claude utilizzata dall'integrazione con Claude, dei server di invio delle e-mail e simili dipende dai rispettivi fornitori.
- Problemi non rilevati dagli strumenti automatici.I tipi di problemi che gli strumenti non rilevano (come errori nella logica applicativa) vengono coperti con controlli manuali, ma non è possibile garantire una copertura completa.
Come segnalare una vulnerabilità
Se individua un problema che ritiene essere una vulnerabilità di GeckoFlag, non lo renda pubblico: ci contatti direttamente tramite il canale indicato di seguito. Ogni segnalazione viene esaminata personalmente dallo sviluppatore.
Canale di segnalazione: ci contatti tramite il modulo di contatto, selezionando il tipo di richiesta «Segnalazione di vulnerabilità»
Informazioni da includere nella segnalazione
- La versione interessata e la schermata o funzione in cui si verifica il problema
- I passaggi per riprodurre il problema (per quanto possibile)
- L'impatto previsto
- L'ambiente server utilizzato (PHP, server web, ecc.)
Richiesta
- Esegua le verifiche in un ambiente da Lei gestito e non compia operazioni offensive su installazioni di GeckoFlag gestite da altri né su geckoflag.com.
Se lo desidera, il nome dell'autore della segnalazione verrà pubblicato come ringraziamento nelle informazioni di sicurezza della versione correttiva.
SHA-256 dei file distribuiti
Può verificare che il file scaricato sia identico a quello ufficiale confrontandolo con i valori seguenti.
| File | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
Come verificare: su Windows esegua Get-FileHash nomefile -Algorithm SHA256 in PowerShell; su macOS e Linux esegua shasum -a 256 nomefile.
Impostazioni consigliate per un utilizzo sicuro
La sicurezza di GeckoFlag dipende anche dalla configurazione del server su cui è installato. Consigliamo le seguenti impostazioni.
- Completi l'installazione subito dopo il caricamento: finché l'installazione non è completata, chiunque conosca l'URL può aprire la schermata di configurazione. Dopo aver caricato i file, completi subito l'installazione.
- Utilizzi HTTPS: le credenziali di accesso e i contenuti dei progetti vengono trasmessi in forma cifrata. Molti servizi di hosting offrono certificati SSL gratuiti. Tenga presente che, dopo aver aperto il sito una volta tramite HTTPS, il browser si connetterà a quell'indirizzo tramite HTTPS per il successivo anno (v1.10.0 e successive). Presti attenzione se prevede di smettere di utilizzare HTTPS.
- Imposti webroot come cartella pubblica (document root): in questo modo i file di configurazione e i log si trovano in una posizione non raggiungibile dal web.
- Se utilizza Nginx, aggiunga la configurazione necessaria: con Nginx il file .htaccess non ha effetto. Configuri separatamente il server in modo da negare l'accesso alle cartelle private e da non eseguire PHP nella cartella di caricamento delle immagini (webroot/img). Per un esempio di configurazione, consulti il manuale (Installazione).
- Aggiorni all'ultima versione: le correzioni di sicurezza vengono fornite nell'ultima versione. Scarichi i file di aggiornamento dal sito ufficiale e ne verifichi lo SHA-256. Dalla v1.10.0 in poi, prima dell'aggiornamento viene verificata automaticamente anche la firma.
- Mantenga PHP e il database su versioni supportate: le versioni di PHP non più supportate non ricevono correzioni.
- Protegga gli account amministratore: utilizzi password lunghe e difficili da indovinare e conceda i permessi di amministratore solo a chi ne ha bisogno.
- Per l'uso interno all'azienda, utilizzi la restrizione IP: da «Impostazioni» può limitare gli indirizzi IP da cui è consentito l'accesso.
- Esegua backup periodici: conservi il database e i file caricati in un luogo separato dal server.