Säkerhet är centralt för att hålla Snipp säkert för alla, och vi förlitar oss på forskare som hjälper oss att snabbt hitta och åtgärda sårbarheter. Om du har upptäckt ett säkerhetsproblem vill vi veta om det. Vi uppskattar varje ansvarsfullt offentliggörande, lycka till med jakten!
Vi kommer aldrig att vidta rättsliga åtgärder mot någon som rapporterar sårbarheter i god tro och följer riktlinjerna på den här sidan.
Vi strävar efter att bekräfta varje rapport inom 48 timmar och håller dig uppdaterad genom hela lösningsprocessen.
Beroende på allvarlighetsgraden och påverkan av ditt fynd kan du vara berättigad till ett exklusivt profilmärke och gratis månader av vår PLUS-prenumeration.
Forskare som gör meningsfulla bidrag till Snipps säkerhet kan tjäna profilmärken som visas offentligt på deras konto.
Tilldelas för din första giltiga sårbarhetsrapport. Uppmärksammar forskare som hjälper till att göra Snipp säkrare.
Tilldelas efter 3-5 exceptionella rapporter eller ett enskilt kritiskt fynd. Reserverat för aktiva forskare som avslöjar de mest betydelsefulla problemen.
All testning måste utföras på dina egna konton. Interagera aldrig med eller påverka andra användares data eller konton.
Endast Snipp-drivna tjänster omfattas. Rapporter som riktar sig mot tredjepartsplattformar, även de som är integrerade via vårt API, accepteras inte.
Undvik all aktivitet som kan försämra våra tjänster eller äventyra dataintegriteten, detta inkluderar brute force, DoS, spamning och tidsbaserade attacker.
Automatiserade skanningsverktyg är inte tillåtna. All testning ska göras manuellt.
Vi kan tillfälligt utesluta vissa sårbarhetsklasser från omfattningen medan vi åtgärdar dem internt. Eventuella ändringar återspeglas på den här sidan.
Håll alla fynd konfidentiella tills vi har utrett och löst problemet fullständigt.
Ansvarsfullt offentliggörande är det bästa sättet att hjälpa oss åtgärda problem snabbt samtidigt som risken minimeras. När du rapporterar direkt till oss kan vi börja arbeta på en lösning omedelbart utan att exponera sårbarheten för illvilliga aktörer.
Fynd som delas offentligt innan vi har haft en chans att åtgärda dem, oavsett om det är på sociala medier, forum eller någon annanstans, är inte berättigade till märkeserkännande. Vi vill ge erkännande till de personer som ger oss möjligheten att åtgärda saker först.
Om flera personer rapporterar samma problem utvärderar vi inskickningarna baserat på:
Tydligheten i den tekniska förklaringen
Hur väl rapporten förmedlar den verkliga påverkan
Tidsstämpel för inskickning
En rapport måste visa verklig påverkan. En CVSS-poäng i sig själv, utan ett fungerande proof of concept som visar vad en angripare faktiskt uppnår, behandlas som informativ och berättigar inte till någon belöning.
Vi uppskattar verkligen varje forskare som tar sig tid att hjälpa till att göra Snipp säkrare.
Vissa data är offentliga med avsikt. Information som redan visas på offentliga sidor är inte konfidentiell, och att läsa den, vare sig via webbplatsen, en API-slutpunkt eller medan du är utloggad, är inte en sårbarhet. Innan du rapporterar en dataexponering, kontrollera om samma data redan visas offentligt. Följande är offentligt enligt design:
Profilinformation som visas på en användares offentliga sida: användarnamn, visningsnamn, avatar, banner, biografi, länkade sociala medier, registreringsdatum samt antal följare och antal följda.
Profilmärken och statusen bakom dem, inklusive personal, partner, buggjägare, översättare, verifierad och supporter. Dessa visas offentligt som märken.
Inläggsinformation i ett offentligt eller olistat inlägg: titel, beskrivning, media, antal visningar och uppladdningsdatum.
Betraktarrelaterade flaggor som endast återspeglar din egen session, till exempel om en profil är din egen, om du följer en användare eller om det finns en blockering mellan dig och denne. Dessa beskriver din relation till data, inte någon annans privata information.
Tänk innan du skickar in på om problemet har ett realistiskt attackscenario och en meningsfull säkerhetspåverkan. Följande är generellt undantaget:
Avslöjande av data som redan är offentlig enligt design (se avsnittet ovan), inklusive profilfält, märken, inläggsmetadata och betraktarrelaterade flaggor
Rapporter som enbart baseras på validering på klientsidan. Säkerhetskontroller upprätthålls på servern, så en saknad kontroll på klientsidan är inte en sårbarhet när servern avvisar samma indata
Hantering av filtyp, MIME eller filändelse vid uppladdningar. Uppladdade filer valideras utifrån sitt faktiska innehåll på servern, och den lagrade typen hämtas aldrig från klienten
Avslöjande av en ursprungs-IP-adress, en infrastrukturleverantör eller en oproxad underdomän. Vissa tjänster, såsom uppladdningsslutpunkter, tillhandahålls avsiktligt utanför CDN:et och är härdade vid ursprunget
Inaktuella eller historiska DNS-poster som inte längre pekar på aktiv infrastruktur
Saknade eller felkonfigurerade säkerhetshuvuden, såsom CSP, HSTS eller X-Frame-Options, utan en påvisad fungerande exploatering
Utförliga felmeddelanden, stackspårningar eller avslöjande av programvaruversion utan en påvisad fungerande exploatering
Uppräkning av giltiga resurser efter identifierare, eller 4xx- och 5xx-svar på ogiltiga identifierare. Att returnera en hittades inte-status på en ogiltig begäran är förväntat beteende
Kontouppräkning
Attacker som kräver MITM eller fysisk åtkomst till en användares enhet
Clickjacking
Innehållsförfalskning och textinjektion
CSRF-sårbarheter
E-postens SPF-, DKIM- och DMARC-poster
Saknade HttpOnly/Secure-cookieflaggor
Öppna CORS-headers
Hastighetsbegränsning
Rapporter från skannrar och automatiserade verktyg
Självexploatering (som återanvändning av token och konsolskriptning)
Social manipulation eller nätfiskeattacker som riktar sig mot användare eller personal
Externa tjänster, partners och integrationer ligger utanför omfattningen av det här programmet. Endast sårbarheter i Snipp-ägda funktioner och API:er kvalificerar. Rapporter måste visa en tydlig säkerhetspåverkan på Snipp självt.
Alla scenarier där en angripare skulle kunna få tag på en annan användares API-nycklar, sessionstoken eller inloggningsuppgifter utan att förlita sig på social manipulation anses omfattas.
Reproducerbara webbplatskrascher orsakade av tillverkad indata eller normal användarinteraktion anses omfattas, förutsatt att de inte är beroende av resursutmattning, spam eller andra denial-of-service-tekniker.
Rapporter som är beroende av att utnyttja ett kapplöpningstillstånd behöver ytterligare bevis för att accepteras. Inkludera minst ett av följande:
Ett reproducerbart skript (Python eller JavaScript föredras, men andra språk går bra)
En grundlig genomgång som täcker HTTP-metoderna, slutpunkterna och den exakta ordningen på förfrågningar som behövs för att utlösa tillståndet
Att inkludera ett skript gör det mycket lättare för oss att verifiera problemet och påskyndar granskningsprocessen.
Skicka oss ett e-postmeddelande med en tydlig beskrivning av problemet, steg för att reproducera det och eventuellt stödjande bevis. Vi återkommer så snart vi kan.