Segnalare una vulnerabilità
Scrivi a hello@html2wp.dev con SECURITY nell'oggetto. Per favore, non segnalare un problema di sicurezza con una issue pubblica su GitHub. Le issue lì sono pubbliche dal momento in cui qualcuno le apre, quindi ogni utente della skill sarebbe esposto al problema prima che esista un aggiornamento da installare.
Come segnalare
Includi tutto ciò che serve per riprodurre il problema: la versione o il commit, i passaggi e cosa ti aspettavi invece. Una proof of concept (una dimostrazione funzionante dell'exploit) aiuta ed è benvenuta, ma non serve per segnalare qualcosa.
L'endpoint /v1/report descritto nella documentazione non è il canale giusto per questo: è una casella per i difetti del generatore, e una persona la legge insieme alle normali segnalazioni di bug.
Cosa aspettarti
- La conferma di ricezione della segnalazione entro 3 giorni lavorativi.
- Una valutazione del problema e una tempistica di massima entro 10 giorni lavorativi.
- Una menzione nelle note di rilascio, se la vuoi, e nessuna se preferisci di no.
Se non ricevi risposta
Siamo una piccola realtà, non un'azienda con un team di sicurezza. Se una segnalazione resta senza risposta oltre quei termini, inviala di nuovo: ci è sfuggita, non la stiamo ignorando.
Cosa rientra nell'ambito
- La skill e gli script in
skills/html2wp/assets/scripts/, che girano sul tuo computer. - Il servizio di conversione su
api.html2wp.dev. - Il tema WordPress generato dal servizio, compreso il runtime PHP che contiene e l'importatore dei contenuti.
Alcune cose vanno segnalate anche quando sembrano piccole: qualsiasi cosa legga o trasmetta file fuori dalla cartella di input e dal workspace, o permetta a una conversione di vederne un'altra. Lo stesso vale per qualsiasi parte di un tema generato raggiungibile senza autenticazione. E per qualsiasi cosa faccia consegnare a una conversione conclusa un tema che avrebbe dovuto rifiutare.
Cosa è fuori ambito
- Problemi trovati su una versione di WordPress, PHP o di un plugin che hai scelto di usare, quando la soluzione è aggiornarla.
- Il WordPress usa e getta in Docker che
test-env.shutilizza per la verifica locale. Ha di proposito una password di amministratore fissa, ascolta solo su127.0.0.1e viene eliminato dopo ogni esecuzione. È un'installazione di prova, non un sito pubblicato. - Segnalazioni secondo cui il controllo della licenza si può rimuovere dal client. Sì, si può: il client è tuo e puoi modificarlo. Nulla di rilevante per la sicurezza dipende da quel controllo. È il servizio a decidere a cosa hai diritto, e le parti a pagamento sono proprio quelle che si rifiuta di produrre senza una chiave.
- Attacchi denial-of-service volumetrici (inondare il servizio di richieste) contro
api.html2wp.dev, e risultati che si riducono a lanciargli contro uno scanner.
Test sul servizio
Fai i test sulle tue conversioni e con la tua chiave di licenza. Non tentare di raggiungere job, artifact o workspace di un altro account. Se pensi di aver trovato un modo per farlo, è proprio la segnalazione da inviarci, e basta descrivere il metodo. Non devi dimostrarlo sui dati di qualcun altro.
Cosa lascia il tuo computer
La pagina sui dati e il README del plugin lo descrivono, perché una policy di sicurezza è il posto sbagliato per scoprirlo la prima volta. In breve: il sito compilato viene caricato sul servizio, e la conversione lavora su quello. I verdetti dei gate (i controlli) vengono inviati a parte e contengono solo nomi e numeri. La fase 1 esclude dal payload i file che sembrano credenziali ed elenca ciascuno di quelli scartati. Se trovi qualcosa che supera quel filtro, rientra nell'ambito.