Git is much nicer, because everything is in one .git directory and it can be kept outside the public webroot.
Using SVN makes your site extremely vulnerable
21–30 of 51 posts
Re: Using SVN makes your site extremely vulnerable
#22This isn't really a vulnerability - just developers not doing their job. Anyone who uses SVN (or any other version management system, for that matter) should know how it works.
I know SVN creates these hidden directories (named .svn) within every directory of my project that contains the working copies of the files within that directory. Therefore I either use export (to not upload the hidden folders) or I make them not accessible to the public via .htaccess.
Saying this is a vulnerability is like telling someone copying/pasting their code into a Pastie is a vulnerability. Common sense.
Re: Using SVN makes your site extremely vulnerable
#23It's not actually clear to me what the problem is. Are they saying that people can read your code (not actually a problem for open source projects) or that they can update it and thus alter your site? The former doesn't seem so bad - the latter is obviously catastrophic. I wish I spoke Russian...
Just reading. This is actually pretty bad. Consider all of the passwords embedded in connection strings and all the other various secrets contained in the source AND configuration files for a standard website. Even if your site uses all open source software, you still don't want J. Random Hacker to have write access to your database, for example.
Of course, you database _really_ shouldn't be externally visible...
Re: Using SVN makes your site extremely vulnerable
#24I'm no security expert but I'm not sure if I get it - assuming that your code is well written, how would exposing the source code and change history make it more vulnerable? By using this logic, every piece of open source software is "vulnerable". Security through obscurity is not really security. I thought not checking in safety critical things such as passwords or keys into the repository tree is a standard practic…
It depends on what the threat is. If the threat is finding vulnerability, then you are right. If the threat is leaking the source code to the competition, then it is a serious matter. Also, keep in mind the deployed source code is different than just the source code; it usually contains things like the database credentials and such.
Of course, but the "vulnerability" in this article was about the source code in the repository tree, not the deployed one. Also, I believe that database credentials should be stored in external configuration files (which, of course, shouldn't be browsable) so if they do an update, they don't have to add the credentials again.
About leaking the source: Yes, that could definitely be a problem, I agree, but I'm not sure if this can be considered as a vulnerability, more like carelessness on the part of the admin of the site.
Re: Using SVN makes your site extremely vulnerable
#25Earlier quoted context omitted.
. It's especially bad because svn puts a .svn in each directory. With e.g. mercurial or git, you can tuck the (visible) site in a subdirectory of the repo itself (project/pages), and the .hg/.git (project/.hg|project/.git) won't be accessible. Of course the best option is still to use exports and symlinks.
Of course, it's not too tricky to configure, say, Apache to block access to all the .svn directories: http://www.subversionary.org/martintomes/preventing-access-t... http://blog.samdevore.com/archives/2006/05/01/hivelogic-prev...
It's not, but if you ever forget to set this config anywhere, you're hosed.
The ideal way is to not take the risk in the first place. You can't forget something you don't have to do.
Re: Using SVN makes your site extremely vulnerable
#26Using a working copy as your website is a pretty bad idea. That's what svn export is meant for.
Using a working copy allows you to deploy your website faster and safer (only the changes gets transfered, you can have hooks to do some cleanup and rollbacks are almost free). I use Mercurial on all my websites (disabling access to .*/.hg of course) and never use FTP for anything.
> Using a working copy allows you to deploy your website faster and safer
It's clearly faster, it clearly is not safer, as the article demonstrate: if you forget to configure Apache to ignore the repo folders, your source code becomes available to the world.
> you can have hooks to do some cleanup and rollbacks are almost free
Export to versioned directories, then use symlinks to link your core to the right version of the site, and you get rollbacks for free as well. The only thing a WC gets you is deployment speed.
Re: Using SVN makes your site extremely vulnerable
#27[deleted]
Re: Using SVN makes your site extremely vulnerable
#28Summary:
A lot of people don't use "svn export" and leave .svn directories readable to everyone.
The authors of the article wrote a crawler that scanned 2.2 million domains, mostly in the .ru zone, for the vulnerability over the last couple of months.
They got access to (parts of) the source code of over 3 thousand sites, including some big ones like:
* yandex.ru and rambler.ru -- Russian search engines
* mail.ru -- Biggest Russian email host
* rbk.ru -- Large online publisher
* 003.ru, bolero.ru -- Online retailers
* habrahabr.ru -- Webdev/blogging/new media community site
* opera.com
Re: Using SVN makes your site extremely vulnerable
#29From the translation:
It would seem that in the XXI century is difficult to find such a vulnerability.
Do Russian speakers generally write the century in roman numerals like that? That's kind of neat..
Re: Using SVN makes your site extremely vulnerable
#30And as usual, PHP is at the top of the game: http://fr2.php.net/.svn/entries (note: interestingly, not all subdomains are open, the us* ones aren't, the uk* ones aren't either, and fr.php.net is also closed)