Doists retningslinjer for belønninger for feil som oppdages
Les retningslinjene våre grundig ettersom disse tydeliggjør hvilken type sikkerhetsproblemer vi vil kunne belønne. Kun rapporter som sendes inn via kontaktskjemaet vårt (tilgjengelig via knappen nederst på denne siden) vil bli vurdert for en eventuell dusørbelønning.
Hos Doist er programmet vårt som belønner feil som blir funnet en kritisk del av innsatsen vår for å bedre sikkerheten. Hvis du har oppdaget en sikkerhetsproblem som du mener vi bør vite om, vil vi gjerne høre fra deg. Innsatsen din kan gi deg en pengebelønning.
Kvalifisering
Du må være den første som rapporterer problemet for å kvalifisere for en belønning.
Du må være tilgjengelig for å gi oss ekstra informasjon, som teamet vårt kanskje trenger, for å gjenskape og adressere problemet.
Gi en detaljert rapport med tydelig reproduserbare trinn, konsekvensen på produktene våre og/eller brukerne, og eventuelle testkontoer du har brukt samt testdata.
Sørg for at du rapporterer uavhengige sårbarheter i separate billetter.
Sørg for at rapporten din har en tydelig tittel som beskriver sårbarheten.
Innsendingen din må inneholde skriftlige instruksjoner for å gjenskape sårbarheten. Enhver rapport uten klare trinn for å reprodusere sårbarheten, eller som bare inkluderer en video som viser sårbarheten, er kanskje ikke kvalifisert for en belønning.
Belønninger
Du kan kvalifisere for å motta en pengebelønning hvis:
Du er den første personen som sender inn en svakhet for et produkt
Sårbarheten anses å være et gyldig problem av teamet vårt
Du har fulgt alle reglene for programmet
Alle belønninger bestemmes av teamet vårt, som vil evaluere hver rapport og tildele et alvorlighetsgrad som bestemmer beløpet for den økonomiske belønningen som skal gis. Alvorlighetsgraden avgjøres internt ut fra typen sårbarhet og potensiell innvirkning. Nedenfor finner du en oversikt over eksempler på hvert alvorlighetsgrad:
Problemer som ikke er relatert til sikkerhet, som HTTP-responskoder son ikke er 200, programfeil eller serverfeil, osv.
Problemer uten en klar innvirkning på sikkerheten, for eksempel utlogget CSRF, manglende HTTP-sikkerhetsheaders, SSL-problemer, problemer med retningslinjer for passord, eller clickjacking på sider uten sensitive handlinger.
Problemer som påvirker utdaterte programmer eller komponenter, som ikke lenger er i bruk eller vedlikeholdes
Problemer som berører tredjeparter, for eksempel tredjepartsapper eller -tjenester vi bruker (f.eks. Firebase, ZenDesk)
Problemer som involverer spam eller sosiale ingeniørteknikker, som SPF og DKIM, og mangel på DNSSEC.
Problemer som involverer tilgjengeliggjøring av serverinformasjon, hovedsakelig «X-Powered-by» og «Server»-respons-header. Unntak kan finnes når tilgjengeliggjort informasjon inneholder en serverversjon med en tilknyttet CVE-tilgjengeliggjøring.
Problemer som involverer SSRF (server-side request forgery) på tjenester som utfører aktive forespørsler etter design, med mindre det er bevist at sensitiv informasjon kan lekkes.
Feil som krever svært usannsynlig brukersamhandling (f.eks. det å ta over en konto via SSO-pålogging)
Rapporter som krever privilegert tilgang til målets enheter eller som ellers er utenfor vår kontroll. Disse inkluderer, men er ikke begrenset til: tilgang til nettleserens informasjonskapsler og/eller andre polletter som burkes til å etterligne brukeren, få tilgang til brukerens e-postadresse, osv.
Problemer med clickjacking som oppstår på forhåndsgodkjente sider, eller mangelen på «X-Frame-Options», eller andre problemer med clickjacking.
Cross-OriginResourceSharing (CORS)-problemer der serveren IKKE svarer med «Access-Control-Allow-Credentials: true»-header.
Manglende hastighetsgrenser, med mindre det kan føre til en sårbarhet som kan utnyttes.
Bruker-e-postoppregning på sidene for registrering, pålogging og glemt passord.
Filer tilgjengelig i URI-er med en bane som starter med «/.well-known» (også kjent som well-known URI-er).
2FA-forbigåelse ved tilbakestilling av passord
Spesifikt for klientapper
Brukerdata lagret ukryptert
Mangel på forvirring
Runtime-hacking som involverer manipulering av kode eller dets miljø
Alvorlighetsgrad: Lav
Åpne omadresseringer
Feilkonfigurasjon eller feil klargjøring av server
Informasjonslekkasjer eller avsløring uten sensitive brukerdata
Cross-OriginResourceSharing (CORS)-problemer der serveren svarer med «Access-Control-Allow-Credentials: true»-header til en forespørsel med tredjeparts «Origin»-header (med andre ord ikke «*.todoist.com», «*.twist.com»).
Reflektert XSS
Blandet innhold-problemer, hvis målnettadressen ikke svarer med en «Strict-Transport-Security» (aka HSTS)-verdi. Risikoen eksisterer fortsatt, men er begrenset til en enkelt interaksjon per domene/underdomene (avhengig av HSTS-verdien). I 2021 har nettlesere gått over til HTTPS som standard, noe som ytterligere reduserer dette problemet.
Andre problemer med lav alvorlighetsgrad
Alvorlighetsgrad: Middels
CSRF / XSRF
SSRF til en intern tjeneste
Lagret XSS
Andre problemer med middels alvorlighetsgrad
Alvorlighetsgrad: Høy
Informasjonslekkasjer eller avsløring med sensitive brukerdata
Andre problemer med høy alvorlighetsgrad
Alvorlighetsgrad: Kritisk
SQL-injeksjon
Ekstern kodekjøring
Eskalering av privilegier
Ødelagt godkjenning
SSRF til en intern tjeneste, som resulterer i en kritisk sikkerhetsrisiko