Infrastruktur, webbtjänster, SMS-Activate-appar

Regler för deltagande i Bug Bounty-programmet

Registrering och verifiering

• Registrering: för att delta i programmet måste du först registrera dig på webbplatsen sms-activate.ai Ange ditt Telegram-konto under registreringsprocessen för enkel kommunikation;
• Verifiering: Du måste genomgå verifieringsprocessen för att få utbetalningar. Detaljerade instruktioner skickas till dig via Telegram när din rapport har godkänts.

Inlämning av rapporter

• Studera reglerna: Innan du skickar in din rapport, vänligen bekanta dig med reglerna för deltagande och de typer av sårbarheter som kan beaktas;
• Rapporteringsformulär: använd formuläret på sidan sms-activate.ai/bugbountyForm för att skicka in din rapport. Din rapport bör innehålla en tydlig beskrivning av sårbarheten, steg för att återskapa den, bevis (skärmdumpar, videor) och rekommendationer för att åtgärda den;
• Ytterligare filer: bifoga ytterligare filer för att bekräfta sårbarheten om det behövs;

Process för granskning av rapporter

Typer av sårbarheter

Verifiering och integritet

Utbetalningar

Etiska riktlinjer

Bilaga A

• IDOR (rapporter om denna typ av sårbarhet accepteras endast vid hög kriticitetsnivå; nivån fastställs av vår specialist när sårbarheten bekräftas);
• Alla typer av XSS-sårbarheter, förutom lagrad XSS (rapporter om lagrad XSS-sårbarhet accepteras beroende på webbresursens betydelse);
• Clickjacking;
• Osäker omdirigerings-URI;
• Aktiverad kataloglistning (lösenord, säkerhetskopior) och Exponering av känslig data (beroende på vilken data som avslöjas; rapporter om denna sårbarhet accepteras om kritisk data hittas);
• Aktiverat debug-läge, som inte avslöjar kritisk data;
• CSRF-sårbarheter, hittade inom en funktion som inte är kritisk;
• Avslöjande av administrationspanelen (om bugghuntaren hittar admin-panelen men inte kan ta över konton eller erhålla annan kritisk information);
• Användarenumerering utan att avslöja kritisk data;
• Felaktig säkerhetskonfiguration, om det inte finns bevis för att hotet har realiserats;
• Vägran att tillhandahålla tjänster;
• Spam；
• Social ingenjörskonst, riktad mot anställda, underleverantörer eller kunder;
• Fysiska försök att få tillgång till egendom eller datacenter
• Systemägare;
• Rapport skapad med automatiserade verktyg och skanningar;
• Fel i tredjepartsprogramvara;
• Avsaknad av säkerhetsheadrar som inte direkt leder till en sårbarhet;
• Brott mot SSL/TLS-förtroende;
• Sårbarheter som endast påverkar användare av föråldrade eller icke-licensierade webbläsare och plattformar;
• Riktlinjer för lösenord och kontoåterställning, såsom utgångsdatum för återställningslänkar eller lösenordsstyrka;
• Föråldrad DNS-post, som pekar på ett system som inte tillhör systemägaren.