12 ms·

iViewed your API keys

174 points by spellsaidwrong 4y ago

louissan 4y ago
- speedgoose 4y ago
  Not really?
  - zach_garwood 4y ago
    Kinda really. This entire class of security lapse can be avoided by not building a js app on the client.
    - gcommer 4y ago
      Plenty of server-rendered apps have been caught putting private data in responses. In this very same comment section people have mentioned the story of a state website that included teacher SSN's in hidden fields[1], and OJFord shared a story of a server that included a full env var dump in error messages[2]. This sort of thing happens all the time to all sorts of services. Rather than just blaming JS, it's far more productive to think of technical controls that could catch this. For example Taint Checking[3] or scanning server responses for API keys. [1]: https://news.ycombinator.com/item?id=31026374 https://news.ycombinator.com/item?id=31026374 [2]: https://news.ycombinator.com/item?id=31026415 https://news.ycombinator.com/item?id=31026415 [3]: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
    - deleted 4y ago
      [deleted]
    - speedgoose 4y ago
      Yes I guess if you don’t build apps you have fewer security issues.
  - louissan 4y ago
    The reason I react (no pun intended haha) this way is because I have seen with my own eyes blue chip (US -- is that the right expression for "company name known quite literally the world over"?) companies doing exactly these sort of things. I have seen the plastering of webpacked-gulpified-obfuscated-minified-hoistpropified-younamedifiedit mind-blowing amounts of Javascript to create the latest "cool" app. I have seen web pages best described as "this webpage is so heavy not even light can escape it". The (not full) cast, not in order of appearance: . 5MB+ of Javascript (not kidding) -- _after_ the above . gazillions of HTTP requests . internal data bled through to the outside world (not always problematic from a security point of view, but one may as well: 1) save on the bytes 2) not give malicious ideas to you-know-who) . code coverage is inversely proportional: with grand score hovering around 3-5%..... End result: . from inside: a bloated over-engineered chaos (see entry: "Big Ball of Mud") . from outside: catastrophic load times of around 35 seconds w/o a primed cache. Talk about the latest shiny new "single page application"..... Granted, it's not always like that! :)
- ovyerus 4y ago
  No it's just bad code/devops
  - zach_garwood 4y ago
Grimburger 4y ago
I'd be careful about posting stuff like this as a young person in Australia. The modern situation is incredibly hostile towards this sort of disclosure. Especially regarding a government entity. It's not that you've done anything in the slightest bit wrong. It's that others with power can easily make it become wrong with little to no backlash in the current Australian climate. I understand the desire for recognition, but certainly think twice and at the very least wait until after election season is over in June so tech-illiterate political opportunists don't pounce to martyr you for their own gain. Would suggest looking into the fall of someone widely recognised like Dr Vanessa Teague, a professor who pointed out government failures in e-voting and claimed health anonymization measures to make up your own mind. One government department finally had enough and she was out, I'm sure it's a lot cheaper than actually fixing the problems raised. Behind the laid back "beers and beaches" mirage, Australia is an authoritarian country with huge public support for iron fists, this is clear to many.
- mimentum 4y ago
  Na you'd be alright -we're not authoritarian here
- AdamJacobMuller 4y ago
  That's really sad. I've never been there but definitely romanticized the beers and beaches and kangaroos motif. Oh well.
  - Handytinge 4y ago
    It's also really untrue, don't believe the doom and gloomers!
- derekbaker783 4y ago
  The same applies in the US, unfortunately.
  - reuben364 4y ago
    See: this ad from Gov Parson in response to a disclosure about a state website leaking social security numbers of teachers https://m.youtube.com/watch?v=9IBPeRa7U8E https://m.youtube.com/watch?v=9IBPeRa7U8E
account-5 4y ago
I'm not a web developer but this stuff, from the outside looking in, is reason enough for me to avoid. Obviously I'm no expert but this sort of stuff happens enough that I wouldn't even know where to start to learn this stuff properly.
- zach_garwood 4y ago
  The disappointing thing is that preventing this sort of thing doesn't take an expert. If you wouldn't post a secret to Reddit or Twitter, don't send that secret to a browser client. That's like webdev 101 stuff.
raxxorraxor 4y ago
To be fair, I think a lot of developers begin with that. There is a logistical problem in providing secrets to a process without getting the secret exposed. Environment variables are an often chosen approach. Of course when the software is tested and ready to be deployed, the step to use a secure container containing credentials is often neglected like it was probably done here. This isn't necessarily sloppy programming, it is just skipping an essential step. How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way?
- 3np 4y ago
  Environment variables on the server side, sure, but having those end up in the client...? If you find that this is a relatable mistake, I hope you have someone with more experience reviewing your code and processes before they touch anything remotely sensitive in production... (Unless you're just trolling)
- alias_neo 4y ago
  The step they seem to be missing is _the entire development process_. If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend. If your "client" needs access to sensitive API keys, you need to rethink your architecture. As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.
  - ratww 4y ago
    Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT. This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening. This is a problem in the CI coupled with a bad build process.
gitgud 4y ago
You can easily see 5 environment variables ending in "_KEY" stored in "window.__INITIAL_STATE__"... crazy this got into production... view-source here -> https://iview.abc.net.au/ https://iview.abc.net.au/
harg 4y ago
I'm not sure how bad this actually is. I haven't examined all the env variables exposed, but it's fairly common to expose public-facing api keys for services that require client-side communication with a 3rd party API. E.g. for client-side bug tracking, search etc.
- blenderdt 4y ago
  If it is a paid service other can now use the service while you pay the price. And the API might also expose data you don't want to expose to the public. That's why you never put these on the client side. There are better options, for example a proxy that injects tokens into the header.
  - spicybright 4y ago
    Handing anyone your API key to use as they want is just asking for trouble. I'm shocked some people think that's an ok pattern to do...
    - kall 4y ago
      And yet it's incredibly common. I would guess 95% of users of services like Firebase, Supabase, Algolia, Sentry, Segment, Cloudinary, Auth0... do this, because it's the point and officially endorsed. They are intended to be "frontend safe" to an extent. Not against service abuse/scraping maybe, but against actual RCE, unauthorized actions or unauthorized data access. I guess you can proxy all that, but then what do you that the third party couldn't be doing for you? Can the user not accomplish the same thing through your proxy that they could through the key? It'll be easier to drop some requests than it is to revoke an API key I guess. You could use client-certificates, stuff along the lines of Cloudflare's API Shield etc but I would guess that only the top 5% of applications do this. I've certainly done it/am doing it right now, which is likely why I'm writing such a defensive comment. Honestly if an enterprising user/developer wants to do something like dump all data that is already accessible to them, more power to them.
    - harg 4y ago
      Usually the public facing keys are restricted in a number of ways to help prevent abuse. E.g. they'll have strict rate limiting, fine-tunable scopes, domain restricted, can only be used in conjunction with a server-side secret. E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail. Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.
nojs 4y ago
*.id.au is an interesting domain that I haven’t seen before. Apparently you can get an id.au iff you’re an Australian citizen, and it must approximately match your real name.
- Grimburger 4y ago
  From my experience it's very common with infosec students in Australia, the general public barely know it exists and probably consider it a weird second level domain. It doesn't need to be anything like your real name, much like only needing a registered aus company to own a *.com.au
- spellsaidwrong 4y ago
  It's a 2ld for individuals, much like .com.au is a 2ld for companies. In this case, it's not actually supposed to match your real name, but nicknames are allowed.
intunderflow 4y ago
Given it's Australia how long until ABC claim to have been "the victim of a sophisticated hack" and get the author arrested
ehnto 4y ago
The Algolia side is required and expected, no? I know you can hide said details to be even safer, but it's expected to have the API public tokens available to the client so they can use the API from your site. The keys shouldn't work on other sites since the API will whitelist your application URL, so stealing them is pointless.
- saimiam 4y ago
  wouldn't `curl <algolia url> -H 'api key' -H'origin:whitelist-url'` let you use Algolia as if you were ABC if all Algolia does is URL whitelisting?
  - anamexis 4y ago
    Yes, which is fine. Same is if you snagged a Google Maps API key off of any old site and used it with curl.
  - simonw 4y ago
    Yes, and that can't be avoided. Best you can hope for is that Algolia have their own rate limiting in place that will kick in if someone starts scraping their API with our API key.
  - chatmasta 4y ago
    You can also use your browser to go to the site and query Algolia. What’s the difference?
  - ehnto 4y ago
    You could, but I suspect it's not a issue in practice else Algolia wouldn't keep working this way. Nor would Google APIs etc.
darepublic 4y ago
Agile did not save their asses. Sprint planning, grooming, modern frameworks, all the trappings of modernity but crucially no one present to say "secret key in frontend is a no-no"
rhacker 4y ago
I wouldn't be surprised if there's a significant number of small or large deployments out there that use a nodejs build such as webpack, that has pulled in some kind of JSON configuration file with prod keys exposed hidden in those huge bundles.
hiisukun 4y ago
Broader context: iView (from the ABC in Australia, a publicly funded broadcaster) was pretty much first to market here for streaming TV, and view on demand. The other stations have all since caught up, but ABC have a tremendous amount of quality children's content so it's a very popular service with families. However, the current government is not a fan of funding the ABC and as such they've been operating with a very tight and reducing budget for most of the last decade. The edges of their products including interactive news pieces and election/pandemic coverage (and some of these API key issues) are a bit rough but the overall achievement is excellent.
- cormacrelf 4y ago
  Great summary. One last recent detail relevant to HN is that despite being a public broadcaster, they've recently started forcing everyone to make an account to watch things, in order to track viewers more closely & get better data. The BBC also does this, I think, not sure when they started. It's a good question -- should you have a right to view content from the public broadcaster without making an account?
ffhhj 4y ago
Also, almost every Android app in Google Play has all the Firebase API keys exposed in their manifests, and it's really easy to retrieve them from APK/AAB's.
andrewstuart 4y ago
The ABC is underfunded and under attack from the government. Even if they do have software issues I wouldn't be publicly running attacks against them cause it would just give the government more reason to cut their funding more. Likely the developers at the ABC are doing the best they can with the limited resources they have, and deserve our support rather than doing the Internet mob attack thing.

speedgoose 4y ago
Not really?
- zach_garwood 4y ago
  Kinda really. This entire class of security lapse can be avoided by not building a js app on the client.
  - gcommer 4y ago
    Plenty of server-rendered apps have been caught putting private data in responses. In this very same comment section people have mentioned the story of a state website that included teacher SSN's in hidden fields[1], and OJFord shared a story of a server that included a full env var dump in error messages[2]. This sort of thing happens all the time to all sorts of services. Rather than just blaming JS, it's far more productive to think of technical controls that could catch this. For example Taint Checking[3] or scanning server responses for API keys. [1]: https://news.ycombinator.com/item?id=31026374 https://news.ycombinator.com/item?id=31026374 [2]: https://news.ycombinator.com/item?id=31026415 https://news.ycombinator.com/item?id=31026415 [3]: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
  - deleted 4y ago
    [deleted]
  - speedgoose 4y ago
    Yes I guess if you don’t build apps you have fewer security issues.
- louissan 4y ago
  The reason I react (no pun intended haha) this way is because I have seen with my own eyes blue chip (US -- is that the right expression for "company name known quite literally the world over"?) companies doing exactly these sort of things. I have seen the plastering of webpacked-gulpified-obfuscated-minified-hoistpropified-younamedifiedit mind-blowing amounts of Javascript to create the latest "cool" app. I have seen web pages best described as "this webpage is so heavy not even light can escape it". The (not full) cast, not in order of appearance: . 5MB+ of Javascript (not kidding) -- _after_ the above . gazillions of HTTP requests . internal data bled through to the outside world (not always problematic from a security point of view, but one may as well: 1) save on the bytes 2) not give malicious ideas to you-know-who) . code coverage is inversely proportional: with grand score hovering around 3-5%..... End result: . from inside: a bloated over-engineered chaos (see entry: "Big Ball of Mud") . from outside: catastrophic load times of around 35 seconds w/o a primed cache. Talk about the latest shiny new "single page application"..... Granted, it's not always like that! :)
ovyerus 4y ago
No it's just bad code/devops
- zach_garwood 4y ago

I'd be careful about posting stuff like this as a young person in Australia. The modern situation is incredibly hostile towards this sort of disclosure. Especially regarding a government entity. It's not that you've done anything in the slightest bit wrong. It's that others with power can easily make it become wrong with little to no backlash in the current Australian climate. I understand the desire for recognition, but certainly think twice and at the very least wait until after election season is over in June so tech-illiterate political opportunists don't pounce to martyr you for their own gain. Would suggest looking into the fall of someone widely recognised like Dr Vanessa Teague, a professor who pointed out government failures in e-voting and claimed health anonymization measures to make up your own mind. One government department finally had enough and she was out, I'm sure it's a lot cheaper than actually fixing the problems raised. Behind the laid back "beers and beaches" mirage, Australia is an authoritarian country with huge public support for iron fists, this is clear to many.

mimentum 4y ago
Na you'd be alright -we're not authoritarian here
AdamJacobMuller 4y ago
That's really sad. I've never been there but definitely romanticized the beers and beaches and kangaroos motif. Oh well.
- Handytinge 4y ago
  It's also really untrue, don't believe the doom and gloomers!
derekbaker783 4y ago
The same applies in the US, unfortunately.
- reuben364 4y ago
  See: this ad from Gov Parson in response to a disclosure about a state website leaking social security numbers of teachers https://m.youtube.com/watch?v=9IBPeRa7U8E https://m.youtube.com/watch?v=9IBPeRa7U8E

account-5 4y ago

I'm not a web developer but this stuff, from the outside looking in, is reason enough for me to avoid. Obviously I'm no expert but this sort of stuff happens enough that I wouldn't even know where to start to learn this stuff properly.

zach_garwood 4y ago
The disappointing thing is that preventing this sort of thing doesn't take an expert. If you wouldn't post a secret to Reddit or Twitter, don't send that secret to a browser client. That's like webdev 101 stuff.

raxxorraxor 4y ago

To be fair, I think a lot of developers begin with that. There is a logistical problem in providing secrets to a process without getting the secret exposed. Environment variables are an often chosen approach. Of course when the software is tested and ready to be deployed, the step to use a secure container containing credentials is often neglected like it was probably done here. This isn't necessarily sloppy programming, it is just skipping an essential step. How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way?

3np 4y ago
Environment variables on the server side, sure, but having those end up in the client...? If you find that this is a relatable mistake, I hope you have someone with more experience reviewing your code and processes before they touch anything remotely sensitive in production... (Unless you're just trolling)
alias_neo 4y ago
The step they seem to be missing is _the entire development process_. If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend. If your "client" needs access to sensitive API keys, you need to rethink your architecture. As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.
- ratww 4y ago
  Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT. This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening. This is a problem in the CI coupled with a bad build process.

gitgud 4y ago

You can easily see 5 environment variables ending in "_KEY" stored in "window.__INITIAL_STATE__"... crazy this got into production... view-source here -> https://iview.abc.net.au/ https://iview.abc.net.au/

harg 4y ago

I'm not sure how bad this actually is. I haven't examined all the env variables exposed, but it's fairly common to expose public-facing api keys for services that require client-side communication with a 3rd party API. E.g. for client-side bug tracking, search etc.

blenderdt 4y ago
If it is a paid service other can now use the service while you pay the price. And the API might also expose data you don't want to expose to the public. That's why you never put these on the client side. There are better options, for example a proxy that injects tokens into the header.
- spicybright 4y ago
  Handing anyone your API key to use as they want is just asking for trouble. I'm shocked some people think that's an ok pattern to do...
  - kall 4y ago
    And yet it's incredibly common. I would guess 95% of users of services like Firebase, Supabase, Algolia, Sentry, Segment, Cloudinary, Auth0... do this, because it's the point and officially endorsed. They are intended to be "frontend safe" to an extent. Not against service abuse/scraping maybe, but against actual RCE, unauthorized actions or unauthorized data access. I guess you can proxy all that, but then what do you that the third party couldn't be doing for you? Can the user not accomplish the same thing through your proxy that they could through the key? It'll be easier to drop some requests than it is to revoke an API key I guess. You could use client-certificates, stuff along the lines of Cloudflare's API Shield etc but I would guess that only the top 5% of applications do this. I've certainly done it/am doing it right now, which is likely why I'm writing such a defensive comment. Honestly if an enterprising user/developer wants to do something like dump all data that is already accessible to them, more power to them.
  - harg 4y ago
    Usually the public facing keys are restricted in a number of ways to help prevent abuse. E.g. they'll have strict rate limiting, fine-tunable scopes, domain restricted, can only be used in conjunction with a server-side secret. E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail. Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.

nojs 4y ago

*.id.au is an interesting domain that I haven’t seen before. Apparently you can get an id.au iff you’re an Australian citizen, and it must approximately match your real name.

Grimburger 4y ago
From my experience it's very common with infosec students in Australia, the general public barely know it exists and probably consider it a weird second level domain. It doesn't need to be anything like your real name, much like only needing a registered aus company to own a *.com.au
spellsaidwrong 4y ago
It's a 2ld for individuals, much like .com.au is a 2ld for companies. In this case, it's not actually supposed to match your real name, but nicknames are allowed.

intunderflow 4y ago

Given it's Australia how long until ABC claim to have been "the victim of a sophisticated hack" and get the author arrested

ehnto 4y ago

The Algolia side is required and expected, no? I know you can hide said details to be even safer, but it's expected to have the API public tokens available to the client so they can use the API from your site. The keys shouldn't work on other sites since the API will whitelist your application URL, so stealing them is pointless.

saimiam 4y ago
wouldn't `curl <algolia url> -H 'api key' -H'origin:whitelist-url'` let you use Algolia as if you were ABC if all Algolia does is URL whitelisting?
- anamexis 4y ago
  Yes, which is fine. Same is if you snagged a Google Maps API key off of any old site and used it with curl.
- simonw 4y ago
  Yes, and that can't be avoided. Best you can hope for is that Algolia have their own rate limiting in place that will kick in if someone starts scraping their API with our API key.
- chatmasta 4y ago
  You can also use your browser to go to the site and query Algolia. What’s the difference?
- ehnto 4y ago
  You could, but I suspect it's not a issue in practice else Algolia wouldn't keep working this way. Nor would Google APIs etc.

darepublic 4y ago

Agile did not save their asses. Sprint planning, grooming, modern frameworks, all the trappings of modernity but crucially no one present to say "secret key in frontend is a no-no"

rhacker 4y ago

I wouldn't be surprised if there's a significant number of small or large deployments out there that use a nodejs build such as webpack, that has pulled in some kind of JSON configuration file with prod keys exposed hidden in those huge bundles.

hiisukun 4y ago

Broader context: iView (from the ABC in Australia, a publicly funded broadcaster) was pretty much first to market here for streaming TV, and view on demand. The other stations have all since caught up, but ABC have a tremendous amount of quality children's content so it's a very popular service with families. However, the current government is not a fan of funding the ABC and as such they've been operating with a very tight and reducing budget for most of the last decade. The edges of their products including interactive news pieces and election/pandemic coverage (and some of these API key issues) are a bit rough but the overall achievement is excellent.

cormacrelf 4y ago
Great summary. One last recent detail relevant to HN is that despite being a public broadcaster, they've recently started forcing everyone to make an account to watch things, in order to track viewers more closely & get better data. The BBC also does this, I think, not sure when they started. It's a good question -- should you have a right to view content from the public broadcaster without making an account?

ffhhj 4y ago

Also, almost every Android app in Google Play has all the Firebase API keys exposed in their manifests, and it's really easy to retrieve them from APK/AAB's.

andrewstuart 4y ago

The ABC is underfunded and under attack from the government. Even if they do have software issues I wouldn't be publicly running attacks against them cause it would just give the government more reason to cut their funding more. Likely the developers at the ABC are doing the best they can with the limited resources they have, and deserve our support rather than doing the Internet mob attack thing.