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

81–90 of 116 posts

Re: iViewed your API keys

#81

Post by baobabKoodaa »

dylan604 wrote: post #51
OJFord wrote: post #11

Earlier quoted context omitted.

I booked a hotel stay (in Canada, not Australia) and got an error page at some point that dumped out all env vars including database credentials. Tried my best to report (not publicly disclose) it, including asking the front desk for contact information for IT; no response. I think we're (on HN) often in quite a bubble of being (or striving to be) hot on this sort of thing, or frankly far trickier to exploit sorts of…

My favorite is just having the console open while visiting the web. It is amazing the amount of information devs "forget" to remove from sending to the console in production. A lot of console vomit is from JS frameworks. I don't know if there's a switch that can tell them to shut up in production or not, but it's one thing I look out for on anything I work on.

const log = function(thingToLog) { if (DEV_ENVIRONMENT) console.log(thingToLog) }

Re: iViewed your API keys

#82

Post by aspenmayer »

legalcorrection wrote: post #69
jacobsenscott wrote: post #53

Earlier quoted context omitted.

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.

The data was already publicly available. Didn’t he just publicize the url?

Re: iViewed your API keys

#83

Post by cookie_monsta »

dylan604 wrote: post #52
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…

Seeing as Australia was used as a prison colony, I'd have thought they'd be much more likely to be against a strong ruling class.

In the same way that you would expect most people in the US to adhere to puritan Calvinist beliefs?

Re: iViewed your API keys

#84

Post by aspenmayer »

greggsy wrote: post #20
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,…

They’ve been reasonable by waiting four months from initial contact, but in vulnerability disclosures it’s polite to add a better timeline of events. There’s still some detail that hasn’t been fully resolved, but it’s not clear what the residual impact is. This particular post doesn’t really seem to go into too much depth about what these keys are used for, or the damage that could be done, but I’m erring on the side…

> Lastly, the ABC is a corporate entity that is fully owned by the commonwealth (and beloved by most Australians) - tue article describes it as ‘state media’, which has sinister propaganda connotations of broadcasters in some other countries.

I’d compare ABC to PBS in America. They both are state media. I think more liberal usage of accurate terms in this way is needed. Folks ought to know who funded and produced the reporting that they consume, especially when it’s those same folks doing the funding. It seems like you’re saying that calling it “state media” is something like spreading FUD, but to object to it being said in neutral terms entirely? I don’t see who benefits from leaving that info out either.

I think the larger issues is these terms being used as dog whistles for propaganda in the first place. Those who have the power to label others as propaganda are not themselves subject to such labeling. Curious.

Re: iViewed your API keys

#85

Post by rhacker »

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.

Re: iViewed your API keys

#86

Post by ratww »

danenania wrote: post #65
greggsy wrote: post #32

Earlier quoted context omitted.

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.

Yep. Maybe just forbidding enumerating environment variables in the runtime would be enough for this case.

However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.

Re: iViewed your API keys

#87

Post by duskwuff »

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?

Hardly matters. If an endpoint is leaking anything as sensitive as national ID + name + address, a determined attacker will have no problem with scraping it slowly or using a network of proxies to avoid rate limits.

Re: iViewed your API keys

#88

Post by throwaheyy »

YPPH wrote: post #67
throwaheyy wrote: post #57

Earlier quoted context omitted.

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.

I’m well aware of the predecessor colonial governments pre-Federation. My point is that those were symbols and apparatus of British imposed rule, and it is relatively recent that the notion of an “Australian government”, as its own national sovereignty, came about. Specifically since the change in national identity had a direct impact on the government no longer being looked at as “the ruling class”.

Re: iViewed your API keys

#89

Post by throwaway744678 »

drdaeman wrote: post #75
nerdawson wrote: post #43

Earlier quoted context omitted.

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

A friend or a nice neighbor: why not. But a random stranger? I'd certainly be unhappy! Why would they even try to open the door in the first place?

Re: iViewed your API keys

#90

Post by chatmasta »

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

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.

Post reply on HN