Salt Mobile SA - Bug Bounty Program
Salt stands for innovation and the best price for premium products in the Swiss telecommunications market (fix and mobile networks).
Reward
Program
Hacktivity
About
Salt Mobile SA
At Salt, we believe in teamwork. Together we achieve more.
That's why we value your feedback, as it enables us to continuously improve our service. If you have found a weakness in our service, please contact us so that we can rectify the problem and you can be assured of fair compensation for your discovery.
Thank you in advance for your loyal cooperation and contribution to making Salt better day by day.
May the show go on.
Program Rules
Testing Policy and Responsible Disclosure
Please adhere to the following rules while performing research on this program:
- Denial of service (DoS) attacks on Salt Mobile SA applications, servers, networks or infrastructure are strictly forbidden.
- Avoid tests that could cause degradation or interruption of our services.
- Do not use automated scanners or tools that generate large amount of network traffic.
- Do not leak, manipulate, or destroy any user data or files in any of our applications/servers.
- Do not copy any files from our applications/servers and disclose them.
- Do not solicit our customers service when the application covered in the scope allows online chat, appointment or call back.
- Do not use accounts of other customers during your research. Only use accounts that you own.
- No vulnerability disclosure, full, partial or otherwise, is allowed.
Reward Eligibility
We are happy to thank everyone who submits valid reports which help us improve the security of Salt Mobile SA, however only those that meet the following eligibility requirements may receive a monetary reward:
- You must be the first reporter of a vulnerability.
- The vulnerability must be a qualifying vulnerability (see below).
- The report must contain the following elements:
- Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and Salt Mobile SA, and remediation advice on fixing the vulnerability
- Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact
- Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc
- You must not break any of the testing policy rules listed above
- You must not be a former or current employee of Salt Mobile SA or one of its contractors.
Reward amounts are based on:
- Reward grid of the report's scope
- CVSS scoring and actual business impact of the vulnerability upon performing risk analysis
About Cross-Site-Scripting (XSS)
Unless you can demonstrate a specific situation where an XSS becomes a "HIGH" or "CRITICAL" finding, it is likely an XSS vulnerability will score as "MEDIUM".
In this case, and if you want your report to be rewarded as a "HIGH" or "CRITICAL" finding, please provide a realistic, proven and step by step detailed scenario of exploitability, including elements that could be modified through this exploit, or actions that could be undertaken on behalf of targeted user.
For example : XHR request to modify account information and could lead to an account take over.
There is also a certain chance, that similar XSS exploits on different endpoints or parameters are caused by the same underlying input validation weakness. If that is the case, we reserve the right to honor only a single report and to reject the other ones as "Duplicate" or "Informative".
N-Day Exploit
The use of N-Day exploit is only considered valid after the patch has been available for at least two months.
Reward
Asset value | CVSS | CVSS | CVSS | CVSS |
---|---|---|---|---|
€50 | €300 | €800 | €2,000 |
Scopes
Scope | Type | Asset value | Expand rewards grid |
---|---|---|---|
https://my.salt.ch | web-application | ||
Low Medium High Critical | |||
https://eshop.salt.ch | web-application | ||
Low Medium High Critical | |||
https://login.salt.ch | web-application | ||
Low Medium High Critical |
Out of scopes
- All domains or subdomains not listed in the above list of 'Scopes'
Vulnerability types
Qualifying vulnerabilities
- SQL Injection (SQLi)
- Cross-Site Scripting (XSS)
- Remote Code Execution (RCE)
- Insecure Direct Object Reference (IDOR)
- Horizontal and vertical privilege escalation
- Authentication bypass & broken authentication
- Business Logic Errors vulnerability with real security impact
- Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
- Cross-Origin Resource Sharing (CORS) with real security impact
- Cross-site Request Forgery (CSRF) with real security impact
- Open Redirect
Non-qualifying vulnerabilities
- Tabnabbing
- Missing cookie flags
- Content/Text injections
- Mixed content warnings
- Clickjacking/UI redressing
- Denial of Service (DoS) attacks
- Known CVEs without working PoC
- Open ports without real security impact
- Social engineering of staff or contractors
- Presence of autocomplete attribute on web forms
- Vulnerabilities affecting outdated browsers or platforms
- Self-XSS or XSS that cannot be used to impact other users
- Outdated libraries without a demonstrated security impact
- Any hypothetical flaw or best practices without exploitable PoC
- Expired certificate, best practices and other related issues for TLS/SSL certificates
- Unexploitable vulnerabilities (ex: XSS or Open Redirect in HTTP Host Header)
- Reports with attack scenarios requiring MITM or physical access to victim's device
- Missing security-related HTTP headers which do not lead directly to a vulnerability
- Unauthenticated / Logout / Login and other low-severity Cross-Site Request Forgery (CSRF)
- Invalid or missing SPF (Sender Policy Framework), DKIM, DMARC records
- Session expiration policies (no automatic logout, invalidation after a certain time or after a password change)
- Disclosure of information without direct security impact (e.g. stack traces, path disclosure, directory listings, software versions, IP disclosure, 3rd party secrets)
- CSV injection
- HTTP Strict Transport Security Header (HSTS)
- Subdomain takeover without a full working PoC
- Blind SSRF without direct impact (e.g. DNS pingback)
- Lack of rate-limiting, brute-forcing or captcha issues
- User enumeration (email, alias, GUID, phone number)
- Password requirements policies (length / complexity / reuse)
- Ability to spam users (email / SMS / direct messages flooding)
- Disclosed / misconfigured Google API key (including Google Maps)
- Recently disclosed 0-day vulnerabilities
- Password reset token leak on trusted third-party website via Referer header (eg Google Analytics, Facebook…)
Hunters collaboration
When submitting new report, you can add up to 5 collaborators, and define the reward split ratio.
For more information, see help center.
Note: For reports that have already been rewarded, it is not possible to redistribute the rewards.