bdittmer/gist:6461b7a5093acd7d6263 Secret

## gistfile1.txt
Request Hijacking with wildcard SSL certs: Hello,

I believe my colleague, Watson Martin, and I have discovered a rather serious bug related to wildcard SSL certificates and request routing. From what we can tell through experimentation, if an app's domain section is configured incorrectly and a wildcard SSL cert is being used it's possible to route http requests to rogue (i.e. not owned by the owner of the SSL cert) dynos.

There are two scenarios…one somewhat severe and the other very severe:

1. An app owner has installed a wildcard SSL cert. They have also setup a variety of subdomains pointing to their Heroku SSL host. However, they forgot to add one of the subdomains to their app domain list (via heroku domains:add …). If a third-party discovers this, they only need to add that specific subdomain to their rogue app's domain list and they will now have http requests routed to their app's dynos. In fact, the true owner of the domain cannot even add that subdomain to their app…the domain command reports it's in use by another app.

An example of this in action is https://api-test.wise-view.com. The *.wise-view.com cert is owned by the app 'wiseview', but the heroku app 'rforte-dt' added 'api-test.wise-view.com' to their domain list. https://api-test.wise-view.com and https://rforte-dt.herokuapp.com are hitting the same app.

2. The second scenario is even more frightening. If a user has a wildcard SSL cert installed in their app and a wildcard CNAME pointed to their Heroku SSL host, but they didn't setup the wildcard domain in their app's domains list, any subdomain that isn't being used by another app is hijackable. That is, a rogue app simply needs to add *any* subdomain to their app and it will start receiving http requests.

We are providing two examples of this. The *.quri.com ssl cert is owned by the app 'quri'.

The app 'rforte-dt' added 'www2.quri.com' to its list of domains. If you go to https://www2.quri.com the app 'rforte-dt' will receive the requests.
The app 'tranquil-garden-2235' added 'blah.quri.com' to its list of domains. If you go to https://blah.quri.com the app 'tranquil-garden-2235' receives the requests.

----

We think the ramifications of this issue are very clear: nefarious actors can easily pass off their own application as one that is owned by someone else...if the app that owns the SSL cert is misconfigured.

We believe the simple fix is if a wildcard SSL cert is installed in an app, only the owners of that app should be allowed to register subdomains (from that vert) with other apps. This handles the case of misconfigured apps and still allows developers the flexibility to use subdomains on other apps that they own.

We patiently await your response and will sit on this until we hear back. If anyone from the security team wants to meet in person or talk on the phone, we're right down the street at 2nd and Bryant in San Francisco.

Regards,
Brian Dittmer
Watson Martin
	Request Hijacking with wildcard SSL certs: Hello,

	I believe my colleague, Watson Martin, and I have discovered a rather serious bug related to wildcard SSL certificates and request routing. From what we can tell through experimentation, if an app's domain section is configured incorrectly and a wildcard SSL cert is being used it's possible to route http requests to rogue (i.e. not owned by the owner of the SSL cert) dynos.

	There are two scenarios…one somewhat severe and the other very severe:

	1. An app owner has installed a wildcard SSL cert. They have also setup a variety of subdomains pointing to their Heroku SSL host. However, they forgot to add one of the subdomains to their app domain list (via heroku domains:add …). If a third-party discovers this, they only need to add that specific subdomain to their rogue app's domain list and they will now have http requests routed to their app's dynos. In fact, the true owner of the domain cannot even add that subdomain to their app…the domain command reports it's in use by another app.

	An example of this in action is https://api-test.wise-view.com. The *.wise-view.com cert is owned by the app 'wiseview', but the heroku app 'rforte-dt' added 'api-test.wise-view.com' to their domain list. https://api-test.wise-view.com and https://rforte-dt.herokuapp.com are hitting the same app.

	2. The second scenario is even more frightening. If a user has a wildcard SSL cert installed in their app and a wildcard CNAME pointed to their Heroku SSL host, but they didn't setup the wildcard domain in their app's domains list, any subdomain that isn't being used by another app is hijackable. That is, a rogue app simply needs to add any subdomain to their app and it will start receiving http requests.

	We are providing two examples of this. The *.quri.com ssl cert is owned by the app 'quri'.

	The app 'rforte-dt' added 'www2.quri.com' to its list of domains. If you go to https://www2.quri.com the app 'rforte-dt' will receive the requests.
	The app 'tranquil-garden-2235' added 'blah.quri.com' to its list of domains. If you go to https://blah.quri.com the app 'tranquil-garden-2235' receives the requests.

	----

	We think the ramifications of this issue are very clear: nefarious actors can easily pass off their own application as one that is owned by someone else...if the app that owns the SSL cert is misconfigured.

	We believe the simple fix is if a wildcard SSL cert is installed in an app, only the owners of that app should be allowed to register subdomains (from that vert) with other apps. This handles the case of misconfigured apps and still allows developers the flexibility to use subdomains on other apps that they own.

	We patiently await your response and will sit on this until we hear back. If anyone from the security team wants to meet in person or talk on the phone, we're right down the street at 2nd and Bryant in San Francisco.

	Regards,
	Brian Dittmer
	Watson Martin