6 ms·

Twitter's Vine source code dump

182 points by ssclafani 10y ago

madeofpalk 10y ago
Wow. Title is a bit misleading (there's no dump for me to download), but crazy nonetheless.
oggedintocom 10y ago
$10k isn't bad.
- raverbashing 10y ago
  I wonder why 10080 though
  - franjkovic 10y ago
    Every Twitter's bounty amount is divisible by 140.
mynewtb 10y ago
Wow, that's some easy money.
partycoder 10y ago
Like uploading your .git directory to a CDN.
- clishem 10y ago
  A .git directory with keys.
okket 10y ago
Can you please change the title from "Twitter's Vine Source code dump" to something that does not suggest that there is actual source code available?
- uxp 10y ago
  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.
  - avicoder 10y ago
    Thanks for clarifying on my behalf.
  - GordonS 10y ago
    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.
cocotino 10y ago
Bad title, there's no source code to download...
jondubois 10y ago
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.
- Matt3o12_ 10y ago
  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).
  - hderms 10y ago
    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.
- theli0nheart 10y ago
  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.
i336_ 10y ago
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.
sulam 10y ago
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. ;)
NathanKP 10y ago
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.

182 points by ssclafani 10y ago

madeofpalk 10y ago

Wow. Title is a bit misleading (there's no dump for me to download), but crazy nonetheless.

oggedintocom 10y ago

$10k isn't bad.

raverbashing 10y ago
I wonder why 10080 though
- franjkovic 10y ago
  Every Twitter's bounty amount is divisible by 140.

mynewtb 10y ago

Wow, that's some easy money.

partycoder 10y ago

Like uploading your .git directory to a CDN.

clishem 10y ago
A .git directory with keys.

okket 10y ago

Can you please change the title from "Twitter's Vine Source code dump" to something that does not suggest that there is actual source code available?

uxp 10y ago
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.
- avicoder 10y ago
  Thanks for clarifying on my behalf.
- GordonS 10y ago
  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.

cocotino 10y ago

Bad title, there's no source code to download...

jondubois 10y ago

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.

Matt3o12_ 10y ago
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).
- hderms 10y ago
  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.
theli0nheart 10y ago
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.

i336_ 10y ago

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.

sulam 10y ago

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

NathanKP 10y ago

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.