Amazon Alexa Client Data Security Hole/Risk

Out of the hundreds of thousands of developers and 100,000+ skills, it’s interesting I’m the one that found the blatant security violation.

The data displayed by our skills contains client MP3s, images and videos. These assets belong to the client and we take great precautions to protect them against unauthorized access. The URLs we provide the skill, and thus Amazon, are never provided to the outside world because would-be hackers would then have access to client data for their own use.

 

We recently found that the Amazon Alexa web app makes available some of these direct asset URLs to Alexa users! This is a major Amazon security hole and betrays the trust our clients have in us, Voice2Biz Inc, to safeguard their data.

 

We figured this out because Amazon failed certification of our latest skill, Baby Countdown. They said our response image could not be displayed. Huh?

 

We retested Baby Countdown thinking we missed something and the image displayed correctly on all screen devices as well as the Alexa simulator, iOS app, and Alexa web browser app. Everything.

 

We reached back out to Amazon to get more information (the certification failure email from them had zero useful information). They said the image was not being displayed in the Alexa app “Activities”, or logs.  I went into the activities for my account and they were correct: the images were not being displayed. Hmmm…

 

I opened the browser Javascript console and looked at the logs and found that the Alexa web app was trying to access our direct client image URL from the logs!!!! Egads, a major security breach by Amazon. They should ONLY access a thumbnail on their own servers taken from the original asset to prevent exactly this type of breach.

Amazon made our client’s data available to the outside world.

 

With these URLs, anyone can download the original client assets directly from our backend that we use to serve assets to our skill. And, then fish for more.

 

The reason this Amazon security hole was even found was that we disable CORS (Cross-Origin Resource Sharing) on our servers. This prevents normal (non-malicious) misbehaving web apps from accessing files outside their own domain where the web app is running.

 

Because we disable CORS, the Amazon Alexa web app got a CORS security violation when the browser did its preflight for the asset. The security violation was in bright red, along with our internal client data URL – right in the browser logs for anyone to see!!! Egads!

 

I documented this and sent the browser log screenshot (see at bottom of page) and told them to go consult with their Security Engineering folks.

 

The interesting thing that remains is we still do NOT want to enable CORS. Even though Amazon no longer tries to access our client’s data directly from the log code, they still do so someplace else in order to build the log. This might still incur a CORS security violation depending on how they do it, thus still rendering our images blank in the activities log. Because of this, they still fail our skill certification.

 

What this means to us is either we create a security hole (enable CORS) in our servers for Amazon to be able to access the image OUTSIDE of the skill context, or we can no longer get our clients’ skills certified. By definition, we had to choose to enable CORS in a selective manner on our skill servers so Amazon can build their activities logs.