I don't see any issue with this title. A "source code dump" is usually an act of vandalism, as opposed to a "source code release", or "released as open source". Additionally, there was source code available. It appeared that Vine was/is written in an interpreted language, so by downloading the wwwroot Docker image, the author was capable of reading the entirety of the Vine application code without any weird decompilation or deobfuscation steps.
No, you can't personally go replicate the steps the author performed to retrieve the Vine source code on your own today, but that's the nature of responsible disclosure. Vine was responsive to the vulnerability report and closed that leak, which enabled the author to create this writeup of what happened.
Disagree. 'dump' strongly implies that the link is to a source code dump. Just changing 'dump' to 'dumped' would more accurately reflect the content of the article.
If that is true, that is seriously silly on behalf of Vine.
Multiple major security flaws:
1. Company source code should only be published to private docker images.
2. You should never store API keys or passwords inside the source code. A better approach is to use environment variables and have the container read those.
Be careful with environment variables. I've often seen that on some crashes all environment variables are dumped. While this should not happen in production configurations, it sometimes does. Furthermore, errors, along with the helpful debug parameters, are often sent by email and get into the hands of the wrong people (e.g. into the issue tracker where everybody has access to, including junior developers and interns who should never see production AWS keys).
A better way is to store it into a config file and store them into global variables at the start of the server (while globals are normally bad, it is ok to use them for thinks like configs if you don't plan to change them after initizalization. Environment vars are globals after all).
I'm not sure that's sufficient reason to say that config files are preferable to environment variables. Presumably the config file would be kept separately from the project code, so it doesn't reduce deployment complexity. Furthermore, environment variables work with basically every programming language and tool you're liable to use without modification.
I don't think using config files is a bad solution, it just isn't categorically better because some programs have been written to dump env vars on a crash.
There's no concept of "private" docker images in this case since they weren't using Docker Hub -- they were running their own registry (and didn't secure it).
I completely disagree with #2. It's incredibly valuable and helpful to be able to use source control to track API key updates. Unlike environment variables, this forces accountability whenever a change to your configuration is made. If you're worried about security, you can always encrypt the individual keys.
Sure it's OK if you have a small team and you can trust everyone on that team. But if you are in a big company with thousands of employees, you don't want a 'rogue' employee (or contractor ...ala Snowden) to start accessing and messing with your services without company approval - The fewer employees know the company access keys and passwords, the better.
Yet another comment requesting the title be changed - I went there benignly looking for source
EDIT: Rationale: The title of this thread reflects verbatim the title of the link, but I still think a more informative (less misleading) title should be considered since this is HN and at least 50% of the people who see this will think they can get source.
One thing I've learned leading a backend team is that a strong devops culture is necessary at any company that values its security. Engineers (especially non senior ones) will often adopt new technologies without doing all the research on how to use them securely.
Some years back it was people uploading their entire .git folder and accidentally hosting it online because they didn't understand how Git worked. Now its people accidentally hosting their docker images containing all their code publicly.
With each wave of technology its necessary to have devops people whose dedicated job is to understand how to set things up securely, and handle setting things up for engineers to use. Otherwise engineers will make mistakes through ignorance or just rushing to solve a problem without doing all the research. This doesn't mean that engineers can't be responsible for helping set things up or that they are free from responsibility to understand what they are doing, but a dedicated devops team serves as a protection to safeguard against issues like this.
A co-worker of mine accidentally published a large chunk (well over half) of the backend code for Twitter on their Maven repo one day. It was pretty awesome! Apparently he was the first to notice and no one downloaded it. ;)
