Programme de chasse aux bugs de sécurité

La sécurité est essentielle pour garder Snipp sûr pour tous, et nous comptons sur les chercheurs pour nous aider à trouver et corriger rapidement les vulnérabilités. Si vous avez découvert un problème de sécurité, nous voulons le savoir. Nous apprécions chaque divulgation responsable, bonne chasse !

Notre engagement

  • Nous n'engagerons jamais de poursuites judiciaires contre quiconque signale des vulnérabilités de bonne foi et respecte les règles de cette page.

  • Nous nous efforçons d'accuser réception de chaque signalement dans un délai de 48 heures et nous vous tiendrons informé tout au long du processus de résolution.

  • Selon la gravité et l'impact de votre découverte, vous pourriez être éligible à un badge de profil exclusif et à des mois gratuits de notre abonnement PLUS.

Badges de chercheur

Les chercheurs qui apportent des contributions significatives à la sécurité de Snipp peuvent gagner des badges de profil affichés publiquement sur leur compte.

Chasseur de bugs

Attribué pour votre premier signalement de vulnérabilité valide. Récompense les chercheurs qui contribuent à rendre Snipp plus sûr.

Chasseur de bugs d'élite

Attribué après 3 à 5 signalements exceptionnels ou une seule découverte critique. Réservé aux chercheurs actifs qui mettent au jour les problèmes les plus marquants.

Règles

  • Tous les tests doivent être effectués sur vos propres comptes. N'interagissez jamais avec les données ou les comptes d'autres utilisateurs et ne les affectez jamais.

  • Seuls les services exploités par Snipp sont dans le périmètre. Les signalements visant des plateformes tierces, même intégrées via notre API, ne seront pas acceptés.

  • Évitez toute activité susceptible de dégrader nos services ou de compromettre l'intégrité des données, ce qui inclut le brute force, le DoS, le spam et les attaques basées sur la temporisation.

  • Les outils d'analyse automatisée ne sont pas autorisés. Tous les tests doivent être effectués manuellement.

  • Nous pouvons temporairement exclure du périmètre certaines catégories de vulnérabilités le temps de les traiter en interne. Tout changement sera reflété sur cette page.

  • Veuillez garder toutes vos découvertes confidentielles jusqu'à ce que nous ayons pleinement enquêté et résolu le problème.

Comment nous traitons les signalements

La divulgation responsable est le meilleur moyen de nous aider à corriger rapidement les problèmes tout en minimisant les risques. Lorsque vous nous faites un signalement directement, nous pouvons commencer à travailler sur un correctif immédiatement, sans exposer la vulnérabilité aux acteurs malveillants.

Les découvertes partagées publiquement avant que nous ayons eu l'occasion de les traiter, que ce soit sur les réseaux sociaux, des forums ou ailleurs, ne seront pas éligibles à la reconnaissance par badge. Nous voulons créditer les personnes qui nous donnent l'occasion de corriger les choses en premier.

Si plusieurs personnes signalent le même problème, nous évaluerons les envois en fonction de :

  • La clarté de l'explication technique

  • La façon dont le signalement traduit l'impact concret

  • L'horodatage de l'envoi

Un rapport doit démontrer un impact concret. Un score CVSS à lui seul, sans une preuve de concept fonctionnelle montrant ce qu'un attaquant obtient réellement, est considéré comme informatif et n'est pas éligible à une récompense.

Nous apprécions sincèrement chaque chercheur qui prend le temps de nous aider à rendre Snipp plus sûr.

Public par conception

Certaines données sont publiques de manière intentionnelle. Les informations qui apparaissent déjà sur des pages publiques ne sont pas confidentielles, et le fait de les consulter, que ce soit via le site, un point de terminaison d'API ou en étant déconnecté, ne constitue pas une vulnérabilité. Avant de signaler une exposition de données, vérifiez si les mêmes données sont déjà affichées publiquement. Les éléments suivants sont publics par conception :

  • Les informations de profil affichées sur la page publique d'un utilisateur : nom d'utilisateur, nom affiché, avatar, bannière, biographie, réseaux sociaux liés, date d'inscription, ainsi que le nombre d'abonnés et d'abonnements.

  • Les badges de profil et le statut qu'ils représentent, notamment membre du personnel, partenaire, chasseur de bugs, traducteur, vérifié et soutien. Ils sont affichés publiquement sous forme de badges.

  • Les informations d'une publication publique ou non répertoriée : titre, description, médias, nombre de vues et date de mise en ligne.

  • Les indicateurs propres au spectateur qui ne reflètent que votre propre session, par exemple si un profil est le vôtre, si vous suivez un utilisateur ou s'il existe un blocage entre vous et lui. Ils décrivent votre relation avec les données, et non les informations privées d'autrui.

Ce qui n'est pas dans le périmètre

Avant de soumettre, demandez-vous si le problème présente un scénario d'attaque réaliste et un impact significatif sur la sécurité. Les éléments suivants sont généralement exclus :

  • La divulgation de données déjà publiques par conception (voir la section ci-dessus), y compris les champs de profil, les badges, les métadonnées des publications et les indicateurs propres au spectateur

  • Les rapports fondés uniquement sur une validation côté client. Les contrôles de sécurité sont appliqués sur le serveur, de sorte qu'un contrôle côté client manquant ne constitue pas une vulnérabilité lorsque le serveur rejette la même entrée

  • La gestion du type de fichier, du type MIME ou de l'extension lors des envois. Les fichiers envoyés sont validés selon leur contenu réel sur le serveur, et le type stocké n'est jamais repris du client

  • La divulgation d'une adresse IP d'origine, d'un fournisseur d'infrastructure ou d'un sous-domaine non protégé par un proxy. Certains services, comme les points de terminaison d'envoi, sont volontairement servis en dehors du CDN et sont renforcés au niveau de l'origine

  • Les enregistrements DNS obsolètes ou anciens qui ne pointent plus vers une infrastructure active

  • Les en-têtes de sécurité manquants ou mal configurés, tels que CSP, HSTS ou X-Frame-Options, sans exploit fonctionnel démontré

  • Les messages d'erreur détaillés, les traces de pile ou la divulgation de versions logicielles sans exploit fonctionnel démontré

  • L'énumération de ressources valides par identifiant, ou les réponses 4xx et 5xx à des identifiants invalides. Renvoyer un statut « non trouvé » à une requête invalide est un comportement attendu

  • Énumération de comptes

  • Attaques nécessitant un MITM ou un accès physique à l'appareil d'un utilisateur

  • Clickjacking

  • Usurpation de contenu et injection de texte

  • Vulnérabilités CSRF

  • Enregistrements e-mail SPF, DKIM et DMARC

  • Absence des attributs de cookie HttpOnly/Secure

  • En-têtes CORS ouverts

  • Limitation de débit

  • Signalements provenant de scanners et d'outils automatisés

  • Auto-exploitation (comme la réutilisation de jetons et le scripting dans la console)

  • Attaques d'ingénierie sociale ou de phishing visant les utilisateurs ou le personnel

Remarques supplémentaires

Services tiers

Les services externes, partenaires et intégrations sont hors du périmètre de ce programme. Seules les vulnérabilités présentes dans les fonctionnalités et API détenues par Snipp sont admissibles. Les signalements doivent démontrer un impact clair sur la sécurité de Snipp lui-même.

Vol d'identifiants et de jetons

Tout scénario dans lequel un attaquant pourrait obtenir les clés API, les jetons de session ou les identifiants d'un autre utilisateur sans recourir à l'ingénierie sociale est considéré comme dans le périmètre.

Plantages du site web

Les plantages reproductibles du site web causés par une entrée spécialement conçue ou une interaction utilisateur normale sont considérés comme dans le périmètre, à condition qu'ils ne dépendent pas de l'épuisement des ressources, du spam ou d'autres techniques de déni de service.

Conditions de concurrence

Les signalements qui dépendent de l'exploitation d'une condition de concurrence nécessitent des preuves supplémentaires pour être acceptés. Veuillez inclure au moins l'un des éléments suivants :

  • Un script reproductible (Python ou JavaScript de préférence, mais d'autres langages conviennent)

  • Une explication détaillée couvrant les méthodes HTTP, les points de terminaison et l'ordre exact des requêtes nécessaires pour déclencher la condition

Inclure un script nous permet de vérifier le problème beaucoup plus facilement et accélère le processus d'examen.

Vous avez trouvé quelque chose ?

Envoyez-nous un e-mail avec une description claire du problème, les étapes pour le reproduire et toute preuve à l'appui. Nous vous répondrons dès que possible.

Plus d'articles