Hacker News Reader

Comment by wouldbecouldbe | Hacker News Reader

I made a similar mistake actually.

We used a nodejs cms called apostrophecms that had an admin panel called global settings.

We used that for managing api keys to our auth server.

We only found out a few months in that it was outputted in the html source code. They did this so it was available to JS, of course it was in their docs. So not blaming them. We glossed over it.

Annoyingly we paid a reasonable amount of money for a pen test with one of the big consultancy companies but they also didn’t see it.

I ended up finding it and checking the logs seems like it wasn’t abused but it was shocking and a big leak

View on HN

I think I'd be looking for at least a refund on that pen test. I've never come across one that was anymore than a box ticking exercise.

I've absolutely been involved (conducting, coordinating, and receiving) some high value pen tests over the years.

One problem is there is no hard definition of what is considered a "pen test". I've seen very highly reputable vendors claim essentially out of the box nessus scans as pen tests, automated burpsuite scans as pen tests.

In my own personal definition of a pen test: security practitioners may use those tools amongst others, but they generally leverage them as recon and then try to uncover pathways in from those vulns, in addition to abusing application logic and misconfiguration.

Second problem: paid pen tests have limited scope and time constraints. If the application surface is sufficiently large, that engagement may simply not be big enough to conduct a thorough test. Contrast this with Bug Bounty hunters (and attackers): they have unbounded time and resources. They can literally keep testing until they find something.. and best part, there are so many of them!

So these public bug disclosures are hard to compare to a private/paid for test. You could argue, the app owners didn't pay enough for a comprehensive test.. but the downside is: just because you paid more, doesn't mean the pen tester did a better job :( While they are high noise, I tend to think bug bounty programs are the best fit for the problem space. You end up with much deeper coverage, and a very positive ROI (even factoring in your engineers to triage the bounty reports).

Security is just box checking. Most IT work is. The deployed stack has limited set of parameters to learn and test for.

Leetcode is popular hiring criteria for a reason; that kind of code checks the “KISS/don’t be clever” and DRY rediscovering known algorithms boxes

Except in a few fields, most startups are pretty vanilla config ops and secops tasks.

Recent popularity among the working class has inflated the egos of run of the mill office workers. “Programmers are lazy” has long been waved around like a badge of honor.

Rather than Silicon Valley I’d like to see a Mad Men take on IT. Start in 06-ish with a bunch of entitled first world craft beer drunkards wasting nights on syntax art, framework wars, rise of cloud. End with Covid, launch LLM AI and a bunch of code school burnouts being laid off.

This actually sounds like a great idea for a show and one I'd watch with great interest.

Hello, I'm really sorry you had this unexpected exposure using ApostropheCMS. As you've mentioned, this data sharing was noted in the documentation but can still prove surprising.

A note for future researchers: the currently supported major version of Apostrophe no longer behaves in this way. Any data injection to the logged-out front-end would be a choice made at the developer level, specifically to avoid this sort of surprise.

That said, there are still use cases for including API keys as part of the configuration and 'content' of certain types of widgets.

For context, I am the head of design at Apostrophe and also play an engineering role.

Yeah, I didn't want to dunk on ApostropheCMS, this was our responsibility for not understanding the tech. I made another comment hoping to make that clear.

Overall it's a great & in current headless craze a unique product. V3 looks very good, but we never got that in production.

Why were you using a web-based content management system for secret management?

In apostrophecms you can easily create setting and content types with custom defined fields. There are quite a few good ideas in there.

Those are mostly used on the node side of things, but often for convenience also shared to the front end.

Edit: don’t wanna blame apostrophe cms here, it was our multi tenant setup and misunderstanding of apostrophe that lead to this situation

> it was in their docs. So not blaming them. We glossed over it.

You should be blaming them. You can't excuse dangerous behaviour by documenting it. I feel like this lesson should be known by now.

We always need to do our due diligence when using someone else's project. It's an open source project, available for free.

If they weren't very clear in the docs is one thing, but it doesn't appear so. Anyway, we won't combat these types of shenanigans by assuming others did everything up to snuff. We gotta be more careful ourselves.

If the panel setting was specifically for API keys, then yes, that's on apostrophecms.

If it's just some kind of generic settings with name/value pairs, then it might make sense to expose those to the browser, and make that very clear up front.

Yeah you can define extra global settings extending the existing fields, so we used that for our multi tenancy solution. And is available on the node side of things as well as on the frontend.

Reply on news.ycombinator.com