4 ms·

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 th

by 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.
  - ehnto 4y ago
    Part of the selling point of Algolia is that they handle the misuse mitigation for search, and running queries directly through their API using public facing keys is the enabling feature for that. The way to hide your keys would be to bounce the search through a proxy server that then does the API call on behalf of the user, but you're really not gaining anything by doing that, and now you're on the hook for traffic misuse mitigation. Most APIs designed to be used this way also whitelist your token to your site domain, so they can't just steal your key and use it on their own site. Regardless, Algolia and services like it fully expect to be exposed to the full force of the internet at all times, so there's really nothing your API key can do that they're not already covering their bases for.
  - chatmasta 4y ago
    If your visitors are making requests to SaaS APIs on your behalf, how can a SaaS identify the visitors belong to you without a key? In general if a SaaS has a client-side SDK, they’ve designed around this and give you an API key just for the client bundle. It has only the permissions required for the client SDK, which - yes, could give a client the ability to run up your bill. But you could say the same about any usage based service. It’s up to you and the service to mitigate against that. I’m not familiar with every variable in the screenshot from this blog post. Of those I’m familiar with, I don’t see any secrets in there.
notamy 4y ago
If you look at the env vars in there, you can see things like $PATH and $HOME leaked.
jeroenhd 4y ago
Currently, most strange state keys seem to have been removed. When you check the web archive (http://web.archive.org/web/20211201000716/https://iview.abc.net.au/ http://web.archive.org/web/20211201000716/https://iview.abc....) though, you can see variables like "USER": "www-data", "HOME": "/var/www" and "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin". There's something called "DRM_WEB_SECRET" which isn't currently in the HTML anymore, I'm guessing they shouldn't have shared that.
- harg 4y ago
  Yes, that's not ideal. Thankfully not too sensitive by itself, but clearly something hasn't been done right.

by harg 4y ago

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.
- ehnto 4y ago
  Part of the selling point of Algolia is that they handle the misuse mitigation for search, and running queries directly through their API using public facing keys is the enabling feature for that. The way to hide your keys would be to bounce the search through a proxy server that then does the API call on behalf of the user, but you're really not gaining anything by doing that, and now you're on the hook for traffic misuse mitigation. Most APIs designed to be used this way also whitelist your token to your site domain, so they can't just steal your key and use it on their own site. Regardless, Algolia and services like it fully expect to be exposed to the full force of the internet at all times, so there's really nothing your API key can do that they're not already covering their bases for.
- chatmasta 4y ago
  If your visitors are making requests to SaaS APIs on your behalf, how can a SaaS identify the visitors belong to you without a key? In general if a SaaS has a client-side SDK, they’ve designed around this and give you an API key just for the client bundle. It has only the permissions required for the client SDK, which - yes, could give a client the ability to run up your bill. But you could say the same about any usage based service. It’s up to you and the service to mitigate against that. I’m not familiar with every variable in the screenshot from this blog post. Of those I’m familiar with, I don’t see any secrets in there.

notamy 4y ago

If you look at the env vars in there, you can see things like $PATH and $HOME leaked.

jeroenhd 4y ago

Currently, most strange state keys seem to have been removed. When you check the web archive (http://web.archive.org/web/20211201000716/https://iview.abc.net.au/ http://web.archive.org/web/20211201000716/https://iview.abc....) though, you can see variables like "USER": "www-data", "HOME": "/var/www" and "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin". There's something called "DRM_WEB_SECRET" which isn't currently in the HTML anymore, I'm guessing they shouldn't have shared that.

harg 4y ago
Yes, that's not ideal. Thankfully not too sensitive by itself, but clearly something hasn't been done right.