Cette page est une traduction fournie à titre indicatif : en cas de divergence, seule la version anglaise fait foi. Nous encourageons le signalement responsable des vulnérabilités découvertes sur nos sites web et nos applications. Nous vous demandons de ne divulguer publiquement aucune information concernant une vulnérabilité tant que nous ne l’avons pas corrigée. Les récompenses sont accordées à notre discrétion, en fonction de la criticité de chaque vulnérabilité.
Pour signaler une vulnérabilité, contactez-nous à security@missiveapp.com en joignant une description détaillée qui nous aidera à comprendre et à corriger la vulnérabilité le plus rapidement possible.
Notre fichier security.txt est disponible ici.
Exigences relatives aux vulnérabilités
Pour être considéré comme valide, un signalement doit démontrer un impact réel et exploitable sur les services de Missive inclus dans le périmètre.
Les signalements doivent démontrer un impact allant au-delà de ce que permettent les propres privilèges de leur auteur. Si l’action nécessite une session authentifiée, expliquez comment un attaquant l’obtiendrait : « l’attaquant a accès à la session de la victime » ne constitue pas une vulnérabilité de l’application.
Preuve de concept obligatoire
Chaque signalement doit inclure l’un des éléments suivants :
- Une démonstration fonctionnelle sur votre propre compte de test
- Des instructions de reproduction claires, étape par étape, que notre équipe peut suivre de manière autonome
- Une vidéo ou des captures d’écran montrant l’exploitation en action
Identification du compte de test obligatoire
Indiquez la ou les adresses e-mail du ou des comptes utilisés pendant les tests. Cela nous permet de vérifier que le comportement signalé a réellement été testé sur notre application. Les signalements sans ces informations vous seront renvoyés pour clarification.
Impact démontré obligatoire
La vulnérabilité doit entraîner au moins l’un des effets suivants :
- Accès non autorisé aux données d’un autre utilisateur ou d’une autre organisation, ou modification ou suppression de ces données
- Prise de contrôle du compte d’un autre utilisateur ou usurpation de son identité
- Possibilité d’amener une victime à effectuer involontairement des actions qui modifient l’état (par ex. CSRF, manipulation du flux OAuth)
- Contournement des limites
- Exploitation côté serveur, comme l’exécution de code à distance, une SSRF donnant accès à des ressources internes, ou le contournement de l’authentification ou des autorisations
Disqualification automatique
Les signalements suivants seront clôturés sans examen :
- Résultats bruts de scanners automatisés, sans vérification manuelle ni impact démontré
- Vulnérabilités théoriques ou hypothétiques sans preuve de concept fonctionnelle
- Signalements affirmant qu’une protection est absente sans l’avoir vérifié : si vous signalez que l’application ne fait pas X, vous devez démontrer que X est réellement absent. Nous clôturerons les signalements dont le comportement décrit ne correspond pas à la réalité.
- Constats purement informatifs, comme la divulgation de versions, l’absence d’en-têtes de sécurité ou des suggestions de configuration, qui ne mènent pas à une exploitation concrète
- Comportements inhérents au protocole ou à la norme sous-jacents (par ex. des jetons OAuth qui restent valides après la réinitialisation du mot de passe chez le fournisseur, des jetons d’API côté client dans les applications mobiles)
- Logique métier ou choix de conception du produit, comme la durée de l’essai, le parcours d’inscription ou les règles d’invitation, qui ne donnent pas un accès non autorisé aux données d’un autre utilisateur
- Actions auto-infligées sur le propre compte de l’auteur du signalement : si l’exploitation nécessite que l’attaquant dispose déjà d’un accès authentifié complet, le signalement doit expliquer quel accès supplémentaire est obtenu au-delà de ce que la session permet déjà
- Signalements en double présentés comme de nouvelles découvertes (par ex. signaler séparément l’abus de l’essai gratuit via des alias « + » et l’abus de l’essai via plusieurs comptes)
- Attaques d’ingénierie sociale ou d’hameçonnage visant les employés de Missive
- Attaques par déni de service (DoS/DDoS)
- Signalements qui n’incluent pas les étapes de reproduction
Hors périmètre
Les catégories de vulnérabilités suivantes sont exclues du programme. Aucune récompense ne sera accordée pour les signalements qui s’y rapportent.
- Politiques e-mail DMARC, SPF et DKIM des domaines Missive
- Métadonnées EXIF non supprimées dans les images téléversées
- Absence d’implémentation de DNSSEC
- Liens de réinitialisation du mot de passe non invalidés après une nouvelle demande
- Problèmes affectant feedback.missiveapp.com ; ils doivent être signalés à Canny.io
- Problèmes affectant status.missiveapp.com ; ils doivent être signalés à PagerDuty
- Problèmes affectant missiveapp.com (domaine racine) ; ils doivent être signalés à Webflow