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

61–70 of 116 posts

Re: iViewed your API keys

#61

Post by SomeCallMeTim »

Macha wrote: post #29
omegalulw wrote: post #18

Earlier quoted context omitted.

> 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? A credential/key storage service, either on device/server or as a separate device, with IAM to control whether the user executing that process can use that secret or not. The user in this case for…

There's a chicken and egg problem here. If you move your secrets to a secret management service, how do you provide the credentials to unlock to that? Whether it's on disk, in the environment or on an internal endpoint like IAM host roles there's ways for this to be exposed in the event of bugs or security vulnerabilities in your application

> in the event of bugs or security vulnerabilities in your application

The article talks about keys being published as part of the web page configuration.

That's far worse than "they could hack a server and gain its credentials!"

Re: iViewed your API keys

#62

Post by louissan »

speedgoose wrote: post #14
louissan wrote: post #2

Quoted post unavailable.

Not really?

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! :)

Re: iViewed your API keys

#63

Post by AdamJacobMuller »

cortesoft wrote: post #50
someotherperson wrote: post #41

Earlier quoted context omitted.

Leaks are everywhere. I went to a certain country and needed to register my phone, somehow ended up in a workflow that allowed me to enter any national registration number (similar to a social security number) and it would output the person's name, phone number, address and other details for me to confirm that that was me :) No rate limiting on the endpoint, doesn't require auth, didn't block my VPN, doesn't even set…

How do you know it wasn’t rate limited?

for((i=0;ihttps://site.com/info.php?id=$i > $i.json done

Re: iViewed your API keys

#64

Post by danenania »

raxxorraxor wrote: post #6

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 programm…

Shameless plug, but we built EnvKey[1] for exactly this purpose.

Instead of providing secrets directly to a server, you generate an ENVKEY token which is used to fetch and decrypt the app’s secrets/config and supply them as environment variables to the process.

The ENVKEY still needs to be protected, but you can limit which IPs can access it and if access is cut off, the process will be killed and secrets cleared immediately, so you do get some additional protection. All access attempts are also logged.

1 - https://envkey.com

Re: iViewed your API keys

#65

Post by danenania »

greggsy wrote: post #32
ratww wrote: post #25

Earlier quoted context omitted.

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 prob…

Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.

It’s crucial to always use an allow-list approach to passing config through to a client.

Re: iViewed your API keys

#66

Post by kall »

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

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.

Re: iViewed your API keys

#67

Post by YPPH »

throwaheyy wrote: post #57
mardifoufs wrote: post #48

Earlier quoted context omitted.

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…

In simple terms, Australia is a relatively young country that formed its own government in 1901. It was also isolated from the rest of the world and has a harsh environment with a lot of things that can kill you. This produced an overall culture of helping each other when you can (what gets called “mateship”), and trust in the government to help when it is needed. Australians generally like an orderly society, that t…

Slight nitpick: Australian colonial (State) governments existed well before the Constitution of the Commonwealth in 1901, at least since 1788.

I'm not so sure about the relevance of the so-called "harsh environment" to political culture. Although, it may be said Australians have a more deferential view of certain aspects of politics than other Western countries.

Re: iViewed your API keys

#68

Post by asojfdowgh »

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,…

Any sources to these claims, other than "it feels that way so it is"?

Re: iViewed your API keys

#69

Post by legalcorrection »

jacobsenscott wrote: post #53
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,…

Also in the US, where you can be sentenced to 41 months in prison for browsing a public URL at AT&T, and where the the Governor of Missouri wants to make it illegal to view the html source of a web page (because some state web site leaked all the SSNs of their teachers in some hidden html or something). If I found something like this on a site I don't think I would notify anyone. Too risky. Maybe over TOR if they hav…

weev didn’t just “browse a public url at AT&T”. That is dishonestly reductionist. He noticed the bug and then used it to retrieve and make public the private data of over a hundred thousand people.

Re: iViewed your API keys

#70

Post by AdamJacobMuller »

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,…

That's really sad.

I've never been there but definitely romanticized the beers and beaches and kangaroos motif. Oh well.

Post reply on HN