Raportarea unei vulnerabilități
Scrie la hello@html2wp.dev cu SECURITY în subiect. Te rugăm să nu raportezi o problemă de securitate printr-un issue public pe GitHub. Acolo, un issue e public din clipa în care cineva îl deschide. Astfel, fiecare utilizator al skill-ului ar fi expus înainte să existe o actualizare de instalat.
Cum raportezi
Trimite tot ce e nevoie ca problema să poată fi reprodusă: versiunea sau commit-ul, pașii și ce te așteptai să se întâmple. Un proof of concept (o demonstrație funcțională a exploit-ului) ajută și e binevenit. Pentru un raport însă nu ai nevoie de el.
Endpoint-ul /v1/report din documentație nu e canalul potrivit pentru asta. E o căsuță pentru defectele generatorului, iar un om o citește alături de rapoartele obișnuite de bug-uri.
La ce să te aștepți
- Confirmarea că am primit raportul în cel mult 3 zile lucrătoare.
- O evaluare a problemei și un calendar aproximativ în cel mult 10 zile lucrătoare.
- O mențiune în notele de versiune, dacă o vrei, și niciuna dacă preferi așa.
Dacă nu primești răspuns
Suntem o echipă mică, nu o companie cu un departament de securitate. Dacă un raport rămâne fără răspuns după aceste termene, trimite-l din nou. Ne-a scăpat, nu îl ignorăm.
Ce intră în aria de acoperire
- Skill-ul și scripturile din
skills/html2wp/assets/scripts/, care rulează pe calculatorul tău. - Serviciul de conversie de la
api.html2wp.dev. - Tema WordPress pe care o generează serviciul, inclusiv runtime-ul PHP livrat cu ea și importatorul de conținut.
Merită raportate și lucrurile care par mărunte. De exemplu, orice citește sau trimite fișiere din afara directorului de intrare și a spațiului de lucru. La fel, orice permite unei conversii să vadă o altă conversie și orice element dintr-o temă generată accesibil fără autentificare. Raportează și orice face ca o conversie terminată să predea o temă pe care ar fi trebuit să o refuze.
Ce nu intră în aria de acoperire
- Probleme găsite într-o versiune de WordPress, PHP sau plugin aleasă de tine, unde soluția e actualizarea ei.
- WordPress-ul temporar din Docker pe care
test-env.shîl folosește pentru verificarea locală. Are intenționat o parolă de administrator fixă, ascultă doar pe127.0.0.1și e șters după fiecare rulare. E un instrument de test, nu un site publicat. - Rapoarte că verificarea licenței poate fi scoasă din client. Da, poate: clientul e al tău și îl poți modifica. Nimic legat de securitate nu depinde de acea verificare. Serviciul decide la ce ai dreptul, iar părțile plătite sunt exact cele pe care refuză să le producă fără cheie.
- Atacuri volumetrice de tip denial-of-service (inundarea serviciului cu cereri) asupra
api.html2wp.devși constatări care se reduc la rularea unui scanner asupra lui.
Testarea serviciului
Testează pe propriile conversii și cu propria cheie de licență. Nu încerca să ajungi la job-urile, artefactele sau spațiile de lucru ale altui cont. Dacă crezi că ai găsit o cale, exact acesta e raportul pe care să ni-l trimiți, iar descrierea metodei e suficientă. Nu trebuie să o demonstrezi pe datele altcuiva.
Ce pleacă de pe calculatorul tău
Pagina despre date și README-ul pluginului descriu asta, pentru că o politică de securitate e locul greșit în care să afli asta prima dată. Pe scurt: site-ul compilat urcă la serviciu, iar conversia rulează pe el. Verdictele gate-urilor se raportează separat și conțin doar nume și cifre. Etapa 1 scoate din pachet fișierele care arată a date de autentificare și listează fiecare fișier eliminat. Dacă găsești ceva care trece de acest filtru, intră în aria de acoperire.