81–90 of 113 posts
Couldn't they just look at the user agent and know that the hit to their API is coming from an Android device rather than a server?
http://developer.android.com/reference/java/net/HttpURLConne... might not have a default User-Agent header that identifies android
I wonder how they would identify a string that appears to be an API secret, and queries their database for it. For every plausible string in every app? I guess they decompile it and find string literals of the correct length?
AWS knows the clients that are connecting to it. All they have to detect is that a large amount of traffic is coming from a wide distribution of mobile devices. This is indicative they embedded the creds into the APK. If they got the creds from a server during runtime, it would be safer to proxy to AWS through the server itself, and never distribute the sensitive data. This would result in only a few proxies connecti…
They did a good thing, title feels slightly misguiding. Could they have figured it out based on API access locations being random?
What's misguiding? No intention to misguide. I think it's completely accurate. They downloaded my app, inspected it, found AWS credentials and emailed me as a result.
I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seemingly sane person develops an application intended for distribution to the public which contains AWS credentials. At what point in your development process do you say "I want this application, which will be distributed to unknown persons, to contain the means to…
If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.
Earlier quoted context omitted.
What's misguiding? No intention to misguide. I think it's completely accurate. They downloaded my app, inspected it, found AWS credentials and emailed me as a result.
I think the misguiding part (or at least, what the tone suggests) is that the order of events is 1) Amazon downloading and scanning all apps and then 2) looking for AWS credentials in the code.
This seems to be the natural outcome of Amazon's excellent customer service policy, where they have on numerous occasions[0] refunded costs for hacked instances. When they commit to that policy, they have a huge incentive to limit customer security breaches. I love examples like that where a company's policies result in incentives that are so well-aligned with those of their users. Does anyone have other good example…
Credit card companies are a good example of the this too. Since they're responsible for fraudulent charges, there's a huge incentive for them to detect them.
I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seemingly sane person develops an application intended for distribution to the public which contains AWS credentials. At what point in your development process do you say "I want this application, which will be distributed to unknown persons, to contain the means to…
I think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not? If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.
It's not an "alternative", it's the correct solution.
In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps.
With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.
Earlier quoted context omitted.
I think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not? If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.
The obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform. It's not an "alternative", it's the correct solution. In fact, you still have to do a lighter-weight version of it with AWS -- you…
For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app.
These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.
Earlier quoted context omitted.
The obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform. It's not an "alternative", it's the correct solution. In fact, you still have to do a lighter-weight version of it with AWS -- you…
I'm not necessarily disagreeing with you, but it's not always practical and perhaps not even possible. For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app. These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.