Caffeine is a social broadcasting platform for gaming, entertainment, and the creative arts. Our goal with this bug bounty program is give researchers a responsible way to disclose vulnerabilities, allow us to build a more secure service for all our users, and reward you for your hard work.
For this program, we are inviting researchers to test our websites, API services, auxiliary services and our Windows 10 broadcasting software.
You are welcome to test almost all of the components, and though it is not required, to start broadcasting yourself. To do so you will need at least 5Mbps upload and a supported game installed.
You are free to test the chat system, but do not do so in an active streamer's chat. You can start your own broadcast or simply navigate to caffeine.tv/yourusername and send messages there if you want to hunt for issues.
This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the prioritization/rating of findings.
For testing the website and APIs, only a Caffeine account is required. Please provide an email account that you actively monitor and prefix your username with "
bcr_". Do not sign up with an @caffeine.tv email address! If you finish your examination and will not use the account in the future, please go into the account settings and delete the account.
Out of scope
Any domain/property of Caffeine not listed in this targets section is out of scope.
There are plenty of targets though:
Step 1: Create a user
As a researcher, you will need to sign up for a new account on Caffeine to test most of the components.
Important: When signing up, please:
- Prefix your username with the letter
- Use an email address you actively monitor.
Please do not create more than 5 accounts.
After signing up, Caffeine will send an email with a verification link. Please click the link to verify your email address to enable your account to broadcast.
Step 2: Be a good citizen
- Do not spam or abuse someone's live broadcast.
- When you are done testing, please clean up after yourself by deleting your test account from the Account Settings page.
The website makes API calls to
*.rtcdn.caffeine.tv. Those are the dynamic services.
One point that is of particular interest is if you can determine the IP address of a broadcaster. We believe there is nothing exposing the broadcasters IP address anywhere, so if you find a workaround, expect to be compensated well.
Target: Request/Response API
This is the API service the website uses for create accounts, fetch users, friends lists, and so on. It is a Ruby on Rails API service, with an nginx proxy, hosted on AWS ECS behind an ALB. It uses JWTs for authentication.
Target: Real-time API
This is the API service the website uses for real-time communication and server push events. When watching a broadcast, the GIF chat system is powered by this API. It makes use of websockets for communication. It is a Golang program hosted on AWS ECS behind an ALB. It also uses JWTs for authentication.
Target: RTCDN API
To watch a broadcast, the website makes a request to this API service to determine where in our Real-Time Content Distribution Network to load video and audio from. It is also used by caffeine.exe (our broadcasting software) to determine where to send audio and video.
Target: Broadcasting Software
To broadcast on Caffeine, a user downloads, installs and runs our custom broadcasting software. It runs only on Windows 10 computers. A user can login to Caffeine using this program, start a supported game, and begin broadcasting the game to Caffeine. They can also include a webcam. You can download the broadcasting software from here: https://www.caffeine.tv/start-broadcasting
In order to capture the game,
CaffeineInjector_x86.exe will inject into the game’s process and hook into the render loop.
Target: Caffeine iOS Application
Our iOS Application serves the same purpose as the website, being used sign up/in, view broadcasts and interact with the broadcasters. It uses the same APIs as the website as well. The application is written in Swift.
Target: Mini-website for Preview
Caffeine makes use of social networking services such as Twitter. A link in Twitter on the iOS application opens their own browser. This mini-website is loaded in this case to support the embedded webview constraints.
Target: Images and Static content
The Caffeine software, user avatars, game images and other static content is hosted on these two domains. Both are hosted on AWS S3 with CloudFront for SSL handling and distribution.
Images can also make calls out to Imgix to perform transformations of images if necessary.
Target: Internal Website: Administrative
Caffeine has an internal websites we use for administrative tasks. It is a Ruby on Rails application on AWS EC2. It is included here because it is exposed to the Internet. We believe we have firewalls and protections in place for this service that ensure it is not accessible without permission.
Target: Other internal websites
These websites follow the same systems as our main website (static files that make API calls).
Target: Internal Website: Build and Test
Caffeine has an internal websites we use for build and test automation. It is a Jenkins server running on AWS EC2. It is included here because it is exposed to the Internet. We believe we have firewalls and protections in place for this service that ensure it is not accessible without permission.
Out of scope
Any subdomain not included above is explicitly out of scope. That includes:
...and any other subdomain of
caffeine.tvor any other Caffeine owned domain.
In the Caffeine broadcasting software, there is a form to “Report an Issue”. Please do not test this more than once as it does go directly to our support team.
Do not attempt any tests on a broadcaster's live broadcast other than your own (www.caffeine.tv/yourusername), and do not send messages to the API with the
stage_idof any other person's stage.
Also out of scope is the Caffeine iOS application on TestFlight.
Scanning is allowed, but keep in mind this is running on AWS who do actively block some scans.
Caffeine uses an OAuth 2.0 style authentication system with a Request Token and an Access Token. Currently, Access Tokens expire after 15 minutes. Submissions related to the access token not immediately expiring will be considered ineligible for reward (such as changing of password or logout). If a researcher is able to demonstrate that the access token is valid for more than 15 minutes, that is likely to be viewed as a priority. Refresh Tokens will expire immediately upon changing password.
Given the website is statically hosted on S3, the attack surface is small. Instead, focus more on the APIs, particularly focusing on account takeover techniques.
Of particular importance is if you can determine the IP address of a broadcaster. We believe there is nothing exposing the broadcaster's IP address, so if you find a workaround, expect to be compensated well.