SecuPress s’engage à travailler avec des experts en sécurité afin de rester à jour avec les dernières techniques de sécurité. Si vous avez découvert un problème de sécurité que vous croyez que nous devrions connaître, nous serions ravis de travailler avec vous.

Cadre

  • Les bugs de sécurité des extensions SecuPress Pro et Free (versions 1.3+) seulement sont comptées.
  • Les bugs de sécurité sur le site secupress.me sont aussi comptés.

Qualification des vulnérabilités

Remarquez que le cadre de ce programme se limite aux vulnérabilités decouvertes avec des navigateurs, mobiles et application web ; merci de ne pas lancer d’attaque d’ingénierie sociale.

Tout problème de feature design ou implémentation qui affecte la confidentialité ou l’intégrité des données des utilisateurs fait partie de ce cadre. Quelques exemples habituels :

  • Cross-Site Scripting (XSS),
  • Cross-Site Request Forgery (CSRF or XSRF),
  • SQL Injections (SQLi),
  • File Inclusions (LFI or RFI),
  • Authentication or Authorization flaws,
  • Remote Code Execution (RCE),
  • Open Redirections,
  • Privilege Escalation,
  • Web Cache Poisoning.

Ne sont pas concernés, la disponibilité de nos services aux utilisateurs, merci de ne pas tenter d’attaque DDOS, c’est hors de ce cadre et non constructif. Nous décourageons aussi l’utilisation d’outils de découvertes automatisées de vulnérabilités générant un volume significatif de trafic, ces tests vous disqualifient des possibles récompenses.

Les vulnérabilités hors cadre

  • XSS « fait le toi même » : Si un attaquant doit convaincre une personne de coller manuellement du code javascript dans firebug, il n’y a rien qu’une application web ne puisse prévenir.
  • XSRF sans utilité pour un attaquant : Si une requête particulière ne change pas l’état de quoi que ce soit, ou si ce changement est succinct, cela ne qualifie pas une récompense.
  • XSRF qui requiert la connaissance d’un secret : Si vous connaissez le secret, vous connaissez le jeton de sécurité alors ce n’est plus une faille. Ce comportement est un faux-positif reporté par les scripts automatisé, ne les utilisez pas.
  • Les bugs qui requièrent des actions utilisateurs un peu folles : Par exemple, une faille XSS qui requiert de la part de l’utilisateur de coller une payload manuellement dans une page, puis de cliquer 2 fois sur des messages d’erreur, ce n’est pas réalisable en vrai.
  • Les vulnérabilités qui requièrent une présence physique de la victime pour débloquer un accès : Bien sûr que non.
  • Denial of Service Vulnerabilities (DoS) : Non merci.
  • Attaques brute force (sur les mots de passe ou jetons): Non merci.
  • Spam ou technique d’ingénierie sociale : Nous nous concentrons sur les failles techniques et non humaines pour ce programme.
  • Entête manquantes qui ne mènent pas directement à une faille de sécurité : Evidemment non.
  • Faille dans WordPress ou un plugin WordPress : Si vous trouvez un bug dans le cœur de WordPress, merci de mailer security@wordpress.org, s’il s’agit d’un plugin présent dans le dépôt des extension, envoyez un mail à plugins@wordpress.org.
  • Les bugs dans nos récentes acquisitions : Pour nous permettre une revue interne, les nouveaux produits et companies rachetées sont sujets à une période de 3 mois de blackout. Les bugs reportés durant cette période n’offrent pas de récompenses.
  • La présence d’un numéro de version ou une information/footprint : Une version ou information en footprint n’est pas en elle même une faille, elle n’explose pas le plugin ou le site à une attaque, donc il est pas possible de qualifier ceci comme une vulnérabilité.
  • La non mise à jour d’un élément sur le site ou d’une librairie tiers dans le plugin : Même si cela représente un danger, cela ne concerne pas nos développements. Merci pour le signalement, mais cela n’ouvre pas de droit à une récompense.

Nous croyons en la reconnaisse du travail des autres. Récompenses monétaires de côté, si votre travail nous aide à améliorer la sécurité de notre service, nous serons heureux de vous remercier de votre contribution au bas de cette page.

Montant des récompenses

Toutes récompenses non réclamée après 2 mois sera annulée.

Le montant final de la récompense est choisi à la discrétion de notre échelle. En particulier, nous pouvons décider de payer plus cher une récompense pour une vulnérabilité trouvée de façon intelligente : décider de payer moins si cela requiert des interactions inhabituelles ; décider qu’un multiple report n’en font qu’un seul et donc ne méritent qu’une seule récompense.

Les récompenses sont rémunérées entre USD$50 et USD$200. Nous utilisons le modèle DREAD score pour choisir la bonne récompense.

DREAD Score › Récompense

  • Très basse (≤ 1) › $50
  • Basse (≤ 2) › $75
  • Sérieuse (≤ 3) › $100
  • Haute (≤ 4) › $150
  • Très haute (≤ 5) › $200

Investigation et rapport des bugs

Nous ne répondons qu’aux rapports techniques de vulnérabilités. Les bugs non relatifs à la sécurité ou autres problèmes devraient être adressés à notre support.

Quand vous investiguez une vulnérabilité, merci de ne cibler que votre compte ou sites web. N’essayez jamais d’accéder aux données d’une autre personne et ne vous engagez pas dans des activités qui endommageraient des données ou le serveur. Aussi il est interdit par la loi d’accéder à des données sans permission, et nous ne le permettons pas même pour des tests.

Merci d’être brefs : Un court lien vers un proof-of-concept ou une courte video expliquant les conséquences d’un bug.

Procédure de divulgation

Le contenu de votre rapport de bug sera transmis à l’équipe de sécurité immédiatement, et restera non public pour permettre à notre équipe d’avoir le temps suffisant pour trouver un remède. Le divulgation publique du rapport pourra être demandée par le chercheur lui même.

  • Accord mutuel : Nous encourageons les 2 partis à rester ouverts pour la décision d’une chronologie de la divulgation. Si nous trouvons un accord, le contenu sera public à la date décidée.
  • Divulgation de protection : Si nous trouvons une preuve d’exploitation active, ou qui pourrait endommager des comptes utilisateurs, nous pourrions publier les détails immédiatement au public afin que chacun puisse prendre les mesures pour se protéger.
  • Extension : Dépendant de la complexité et d’autres facteurs, certaines vulnérabilités peuvent demander plus de temps que les 30 jours par défaut pour être résolue. Dans ces cas inhabituels, le rapport pourrait encore rester non public afin de s’assurer que l’équipe aie le temps adéquat pour corriger la faille.
  • Dernier recours : Si après 6 mois après nous avoir informé, nous n’avons toujours pas publié de correctif, ou n’avons pas respecté la chronologie décidée, le contenu du rapport pourra être divulgué si vous le souhaitez par vos moyens. Nous pensons que la transparence au public le meilleur des cas.

Les rapports doivent inclure

  • Un proof of concept
  • Le détails des étapes permettant de reproduire la vulnérabilité
  • L’explication du comment l’attaque pourrait être exécutée dans le vrai pour compromettre un système
  • Une identité réelle et une adresse email sur un service non temporaire
  • Un délai correct pour les réponses et la divulgation responsable

Ne pas nous donner du temps de vous répondre, rendre une information publique, ne pas faire d’efforts de communications, prendre le risque que nos utilisateurs soient en danger, dégrader nos services, cacher votre identité, tout ceci vous disqualifie instantanément des récompenses.

Aussi vous devez adhérer à ces lignes de conduite et à notre politique de divulgation responsable ci-dessous

  • Respecter la vie privée. Faites un gros effort pour ne pas accéder aux données des utilisateurs.
  • Soyez patient. Faites un gros effort pour clarifier votre rapport et pendant le support de notre équipe.
  • Ne dégradez pas. Agissez avec le bon sens pendant le processes de découverte des vulnérabilités. N’exploitez jamais à fond sans permission, que nous ne donnons pas..
  • Tous les chercheurs doivent attendre au moins 2 jours avant de divulguer un correctif quelque soit la criticité.
  • Tous les chercheurs doivent attendre au moins 4 jours avant de divulguer un correctif de criticité haute ou plus.
  • Vous devez être la première personne à nous rapporter le problème. Si un doublon est reporté pendant que la vulnérabilité est encore présente sans correctif, une récompense pourra être accordée si les informations sont plus importantes et claires ou si elle ajoute de la criticité.
  • Ne communiquer avec notre équipe qu’avec notre mail security@secupress.me, nous serons plus impressionnés par vos exploits en privé que via les réseaux sociaux.
  • Être dans un pays dans lequel nous pouvons légalement vous rémunérer via Paypal et nous fournir une facture.

Paiement des récompenses

Les paiements des récompenses sont sujets aux exigences suivantes :

  • Les mineurs sont les bienvenues dans le programme. Cependant, la Children’s Online Privacy Protection Act nous interdit de collecter des données personnelles sur les enfants de moins de 13 ans, donc vous devrez réclamer votre dû via votre parent ou représentant légal.
  • Tous les paiements sont fait en U.S. dollars (USD) et respecteront les lois locales, les règlements et les règles d’éthique. Vous êtes responsable des taxes que la récompense peut apporter, à déterminer avec les lois de votre pays.
  • Il est de votre seule responsabilité de respecter les politiques que votre employeur pourrait avoir et qui affecteraient votre admissibilité à participer à ce programme de primes.

Nous vous remercions par avance pour vos recherches.