Sikkerhet er kjernen i å holde Snipp trygt for alle, og vi stoler på forskere for å hjelpe oss med å finne og fikse sårbarheter raskt. Hvis du har oppdaget et sikkerhetsproblem, vil vi vite om det. Vi setter pris på hver ansvarlig avsløring, lykke til med jakten!
Vi vil aldri forfølge rettslige skritt mot noen som rapporterer sårbarheter i god tro og følger retningslinjene på denne siden.
Vi tar sikte på å bekrefte hver rapport innen 48 timer og vil holde deg oppdatert gjennom hele løsningsprosessen.
Avhengig av alvorlighetsgraden og virkningen av funnet ditt, kan du være kvalifisert for et eksklusivt profilmerke og gratis måneder med PLUS-abonnementet vårt.
Forskere som gir meningsfulle bidrag til Snipps sikkerhet, kan tjene profilmerker som vises offentlig på kontoen deres.
Tildeles for din første gyldige sårbarhetsrapport. Anerkjenner forskere som hjelper med å gjøre Snipp tryggere.
Tildeles etter 3-5 eksepsjonelle rapporter eller et enkelt kritisk funn. Forbeholdt aktive forskere som avdekker de mest virkningsfulle problemene.
All testing må utføres på dine egne kontoer. Aldri interager med eller påvirk andre brukeres data eller kontoer.
Bare Snipp-drevne tjenester er i omfang. Rapporter som retter seg mot tredjepartsplattformer, selv de som er integrert via API-et vårt, vil ikke bli akseptert.
Unngå aktivitet som kan forringe tjenestene våre eller kompromittere dataintegriteten. Dette inkluderer brute forcing, DoS, spamming og tidsbaserte angrep.
Automatiserte skanneverktøy er ikke tillatt. All testing skal utføres manuelt.
Vi kan midlertidig ekskludere visse sårbarhetsklasser fra omfanget mens vi håndterer dem internt. Eventuelle endringer vil gjenspeiles på denne siden.
Vennligst hold alle funn konfidensielle til vi har undersøkt og løst problemet fullstendig.
Ansvarlig avsløring er den beste måten å hjelpe oss med å fikse problemer raskt på, samtidig som risikoen minimeres. Når du rapporterer direkte til oss, kan vi begynne å jobbe med en løsning umiddelbart uten å eksponere sårbarheten for ondsinnede aktører.
Funn som deles offentlig før vi har hatt mulighet til å håndtere dem, enten på sosiale medier, fora eller andre steder, vil ikke være kvalifisert for merkeanerkjennelse. Vi vil kreditere de som gir oss muligheten til å fikse ting først.
Hvis flere personer rapporterer samme problem, vil vi evaluere innsendinger basert på:
Klarhet i den tekniske forklaringen
Hvor godt rapporten formidler den reelle virkningen
Tidsstempel for innsending
En rapport må vise reell påvirkning. En CVSS-poengsum alene, uten et fungerende proof of concept som viser hva en angriper faktisk oppnår, behandles som informativ og kvalifiserer ikke til belønning.
Vi setter virkelig pris på hver forsker som tar seg tid til å hjelpe med å gjøre Snipp tryggere.
Noen data er offentlige med vilje. Informasjon som allerede vises på offentlige sider, er ikke konfidensiell, og å lese den, enten via nettstedet, et API-endepunkt eller mens du er logget ut, er ikke en sårbarhet. Før du rapporterer en dataeksponering, sjekk om de samme dataene allerede vises offentlig. Følgende er offentlig av design:
Profilinformasjon som vises på en brukers offentlige side: brukernavn, visningsnavn, avatar, banner, biografi, tilknyttede sosiale medier, registreringsdato samt antall følgere og antall fulgte.
Profilmerker og statusen bak dem, inkludert ansatt, partner, feiljeger, oversetter, verifisert og støttespiller. Disse vises offentlig som merker.
Innleggsinformasjon i et offentlig eller uoppført innlegg: tittel, beskrivelse, medier, antall visninger og opplastingsdato.
Seerrelaterte flagg som bare gjenspeiler din egen økt, for eksempel om en profil er din egen, om du følger en bruker, eller om det finnes en blokkering mellom deg og vedkommende. Disse beskriver ditt forhold til dataene, ikke noen andres private informasjon.
Før du sender inn, tenk over om problemet har et realistisk angrepsscenario og en meningsfull sikkerhetsvirkning. Følgende er generelt ekskludert:
Avsløring av data som allerede er offentlig av design (se avsnittet ovenfor), inkludert profilfelt, merker, innleggsmetadata og seerrelaterte flagg
Rapporter som utelukkende er basert på validering på klientsiden. Sikkerhetskontroller håndheves på serveren, så en manglende kontroll på klientsiden er ikke en sårbarhet når serveren avviser den samme inndataen
Håndtering av filtype, MIME eller filendelse ved opplastinger. Opplastede filer valideres ut fra sitt faktiske innhold på serveren, og den lagrede typen hentes aldri fra klienten
Avsløring av en opprinnelses-IP-adresse, en infrastrukturleverandør eller et uproksert underdomene. Enkelte tjenester, som opplastingsendepunkter, leveres med vilje utenfor CDN-et og er herdet ved opprinnelsen
Utdaterte eller historiske DNS-oppføringer som ikke lenger peker til aktiv infrastruktur
Manglende eller feilkonfigurerte sikkerhetshoder, som CSP, HSTS eller X-Frame-Options, uten en påvist fungerende utnyttelse
Detaljerte feilmeldinger, stakksporinger eller avsløring av programvareversjon uten en påvist fungerende utnyttelse
Oppramsing av gyldige ressurser etter identifikator, eller 4xx- og 5xx-svar på ugyldige identifikatorer. Å returnere en ikke funnet-status på en ugyldig forespørsel er forventet atferd
Kontooppregning
Angrep som krever MITM eller fysisk tilgang til en brukers enhet
Clickjacking
Innholdsforfalskning og tekstinjeksjon
CSRF-sårbarheter
SPF-, DKIM- og DMARC-poster for e-post
Manglende HttpOnly/Secure-flagg for informasjonskapsler
Åpne CORS-headere
Hastighetsbegrensning
Rapporter fra skannere og automatiserte verktøy
Selvutnyttelse (som token-gjenbruk og konsollskripting)
Sosial manipulering eller phishing-angrep rettet mot brukere eller ansatte
Eksterne tjenester, partnere og integrasjoner er utenfor omfanget av dette programmet. Bare sårbarheter i Snipp-eide funksjoner og API-er kvalifiserer. Rapporter må vise en tydelig sikkerhetsvirkning på Snipp selv.
Ethvert scenario der en angriper kan skaffe seg en annen brukers API-nøkler, sesjonstokener eller legitimasjon uten å støtte seg på sosial manipulering, anses som i omfang.
Reproduserbare nettstedskrasj forårsaket av utformet input eller normal brukerinteraksjon anses som i omfang, forutsatt at de ikke er avhengige av ressursutmattelse, spam eller andre teknikker for tjenestenekt.
Rapporter som er avhengige av å utnytte en kappløpstilstand, trenger ytterligere bevis for å bli akseptert. Vennligst inkluder minst ett av følgende:
Et reproduserbart skript (Python eller JavaScript foretrekkes, men andre språk er greit)
En grundig redegjørelse som dekker HTTP-metodene, endepunktene og den nøyaktige rekkefølgen av forespørsler som trengs for å utløse tilstanden
Å inkludere et skript gjør det mye enklere for oss å verifisere problemet og fremskynder gjennomgangsprosessen.
Send oss en e-post med en tydelig beskrivelse av problemet, trinn for å reprodusere det, og eventuelle støttende bevis. Vi kommer tilbake til deg så snart vi kan.