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