Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iViewed your API keys

wale.id.au

Post reply on HN
Print view View original

71–80 of 116 posts

Re: iViewed your API keys

#71

Post by harg »

spicybright wrote: post #47
blenderdt wrote: post #40

Earlier quoted context omitted.

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.

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...

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.

Re: iViewed your API keys

#72

Post by harg »

jeroenhd wrote: post #45
harg wrote: post #36

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.

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.... ) 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…

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

Re: iViewed your API keys

#73

Post by cookie_monsta »

mardifoufs wrote: post #48
Grimburger wrote: post #3

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 why is the Australian government so "police state" minded? Is that really what the Australian people want? I'd guess they just don't care either way, but in that case why would the Australian politicians push for that? Canada has a pretty similar apathy towards politics but even then we don't see the government forcing Canadian citizens to implement backdoors or raiding the offices of a broadcaster. (Yes the rece…

> Is it a partisan issue in Australia or is it something both parties agree on?

They've been boiling the frog since 9/11. All anybody has to say is "national security" and the opposition party pretty much folds. Imagine the US without the Bill of Rights - that's the landscape.

Re: iViewed your API keys

#74

Post by ehnto »

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.

Re: iViewed your API keys

#75

Post by drdaeman »

nerdawson wrote: post #43
michaelt wrote: post #27

Earlier quoted context omitted.

Quite a few countries have laws from the 1980s that basically say "gaining unauthorised access to computer systems is a crime" Which is of course a very expansive definition. Think you've found a leaked database credential and you test it before reporting, so as not to create a false alarm? That's illegal hacking. Almost any persistent XSS? That's illegal hacking. Access an admin panel by entering a default password?…

Both the first and third example you gave would strike me as crossing the line. Without permission to test the security of a system, you shouldn't be trying credentials you've stumbled upon or defaults. If you randomly try my front door and find that it's unlocked, don't expect me to be thanking you.

> If you randomly try my front door and find that it's unlocked, don't expect me to be thanking you.

Why? If someone tries my front door, doesn't go in but confirms that it is unlocked by opening it by an inch (=verifies the DB credentials but doesn't run any queries) without really peering into my private spaces, then privately reaches out with "hey, hey, your door is not locked - I haven't went in but I know it's unlocked, you may wanna look into this" then I imagine while that could be odd situation (e.g. depending on whenever one has a lawn), I would be grateful and not in the least bit offended.

Surely, I wouldn't be happy if I'd get an alarm that my door is suddenly open (IDS alert) and would react accordingly. But if my door is not locked and I'm not aware and someone responsibly discloses this - I don't see how that'd be an issue.

Re: iViewed your API keys

#76

Post by ehnto »

spicybright wrote: post #47
blenderdt wrote: post #40

Earlier quoted context omitted.

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.

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...

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.

Re: iViewed your API keys

#77

Post by saimiam »

ehnto wrote: post #74

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.

wouldn't `curl -H 'api key' -H'origin:whitelist-url'` let you use Algolia as if you were ABC if all Algolia does is URL whitelisting?

Re: iViewed your API keys

#79

Post by anamexis »

saimiam wrote: post #77
ehnto wrote: post #74

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.

wouldn't `curl -H 'api key' -H'origin:whitelist-url'` let you use Algolia as if you were ABC if all Algolia does is URL whitelisting?

Yes, which is fine. Same is if you snagged a Google Maps API key off of any old site and used it with curl.

Re: iViewed your API keys

#80

Post by simonw »

saimiam wrote: post #77
ehnto wrote: post #74

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.

wouldn't `curl -H 'api key' -H'origin:whitelist-url'` let you use Algolia as if you were ABC if all Algolia does is URL whitelisting?

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.
Post reply on HN