Een kwetsbaarheid melden
Mail naar hello@html2wp.dev met SECURITY in de onderwerpregel. Meld een beveiligingsprobleem alsjeblieft niet via een openbare issue op GitHub. Issues daar zijn openbaar vanaf het moment dat iemand ze aanmaakt, dus elke gebruiker van de skill zou aan het probleem blootstaan voordat er een update is om te installeren.
Hoe je meldt
Voeg alles toe wat nodig is om het probleem te reproduceren: de versie of commit, de stappen en wat je in plaats daarvan verwachtte. Een proof of concept (een werkende demonstratie van de exploit) helpt en is welkom, maar je hebt er geen nodig om iets te melden.
Het endpoint /v1/report uit de documentatie is hier niet het juiste kanaal voor: het is een brievenbus voor fouten in de generator, en een mens leest het samen met gewone bugmeldingen.
Wat je kunt verwachten
- Binnen 3 werkdagen een bevestiging dat we de melding hebben ontvangen.
- Binnen 10 werkdagen een beoordeling van het probleem en een globale planning.
- Een vermelding in de release notes als je dat wilt, en geen als je dat liever niet hebt.
Als het stil blijft
We zijn een klein team, geen bedrijf met een securityafdeling. Blijft een melding na die termijnen onbeantwoord, stuur haar dan opnieuw: we hebben haar gemist, we negeren haar niet.
Wat binnen de scope valt
- De skill en de scripts in
skills/html2wp/assets/scripts/, die op je eigen machine draaien. - De conversiedienst op
api.html2wp.dev. - Het WordPress-thema dat de dienst genereert, inclusief de PHP-runtime die het meelevert en de importeur van de inhoud.
Dingen die het melden waard zijn, ook als ze klein lijken: alles wat bestanden buiten de invoermap en de werkruimte leest of verstuurt, alles waardoor de ene conversie een andere kan zien, alles in een gegenereerd thema wat zonder authenticatie bereikbaar is, en alles waardoor een afgeronde conversie een thema oplevert dat ze had moeten weigeren.
Wat buiten de scope valt
- Bevindingen tegen een versie van WordPress, PHP of een plugin die je zelf koos, waarbij de oplossing een update is.
- De wegwerp-WordPress in Docker die
test-env.shgebruikt voor lokale controle. Die heeft met opzet een vast beheerderswachtwoord, luistert alleen op127.0.0.1en wordt na elke run verwijderd. Het is een testopstelling, geen gepubliceerde site. - Meldingen dat een licentiecontrole uit de client te verwijderen is. Ja, dat kan: de client is van jou en je kunt hem aanpassen. Niets wat met beveiliging te maken heeft, hangt af van die controle. De dienst beslist waar je recht op hebt, en de betaalde delen zijn precies de delen die hij zonder sleutel weigert te maken.
- Volumetrische denial-of-service-aanvallen (de dienst overspoelen met verzoeken) tegen
api.html2wp.dev, en bevindingen die neerkomen op het draaien van een scanner ertegen.
Testen tegen de dienst
Test tegen je eigen conversies en je eigen licentiesleutel. Probeer niet bij de jobs, artifacts of werkruimtes van een ander account te komen. Denk je dat je een manier hebt gevonden, dan is dat precies de melding die je ons moet sturen, en de methode beschrijven is genoeg. Je hoeft het niet te bewijzen met de gegevens van iemand anders.
Wat je machine verlaat
De pagina over gegevens en de eigen README van de plugin beschrijven dit, want een beveiligingsbeleid is de verkeerde plek om het voor het eerst te lezen. Kort gezegd: de gebouwde site gaat naar de dienst, en de conversie draait daarop. De uitkomsten van de controles worden apart gemeld en bevatten alleen namen en getallen. Fase 1 filtert bestanden die op inloggegevens lijken uit wat er wordt verstuurd en noemt elk bestand dat het weglaat. Vind je iets wat door dat filter heen komt, dan valt het binnen de scope.