Russian language is indo-european, therefore the result is much better than if you're translating from chinese or turkish.
Google translate is good at lexical translation but still can't bind words together properly (and probably never will unless they'd change their paradigm).
I have to add that original text is surprisingly incoherent. They surely didn't re-read it after they wrote it.
Actually, TFA isn't about svn repositories but about using working copies for your production site, and leaving .svn world-readable. svn repositories tend to at least use some kind of HTTP auth (if not https or ssh), but a world-readable .svn means your whole project is available.
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.
Spot on. Even with proper auth rules it would still trouble me knowing I had my source exposed to the world. I'm a big fan of exports and now, thanks to you and masskin(sp?), really digging the symlinks idea.
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.
one good idea I had was using a patch queue to insert database and other "secret" settings into a Mercurial pull.
So when I deploy updates to sites we pull and update the changes then merge a locally stored patch queue to reconfigure the settings.
Because the settings are locally stored on the server (not in the site root) there is no way for people to steal the details from the public mercurial server :D
> 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.
I will echo the sentiments of Sujan and masklinn. A production machine should not have a checked out version of a repository on it ever. If you want the ability to rollback, you have the last N exports of your repo in their versioned folders with a symlink from a 'current' folder pointing to the revision you want on live.
Don't blame the tool, blame the individual for using it improperly.
It's the former. Sure, it's not a problem if your code is already open-sourced, but plenty of people are working on things that aren't. And aside from code, you may have private data stored in your repository, such as API keys, or even just configuration information about your site setup that might help attackers.
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.
Well, don't forget about "security-in-depth". Combine "DB password on your website" with "remote unprivileged shell" on any server that can reach the DB, and now you've got a "shell into the DB".
Security exploits aren't just bad for what they directly allow, they are bad for how they often combine well.
(You, AndrewDucker, may already know this; I'm not trying to imply otherwise. I'm saying this because this is a point that needs to be made more often, too many people ignore it. Any unauthorized access into your system needs to be taken very seriously, because of this risk.)
I'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 practice. If it's not, it should be.
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.
This 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.
People mis-configure Apache all the time. They leave their site wide open for attack. They're vulnerable.
Saying it's not a vulnerability when 3,000 sites all have their source code visible to the world is like having your arm chopped off and saying "no it isn't, it's just a flesh wound."
I know it's not a cool remote root buffer overflow exploit hat trick 540 front side flip, but it's a security hole which people need to be educated about.
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
Yes, it is customary in Russian writing to write century numbers in Roman numerals. The Russian language is going through a significant anglicization phase right now, though, so this will probably change.
And 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)
The issue is not in "using SVN". It's in using any revision control system that has .svn .git etc directories, and accidentally making those directories world readable from a webserver.
We deploy like this, and it looks like I cannot get to the source files in the way described.
It appears that IIS is naively not serving up these file types. If I drop a plain html file in the .svn folder I can get to it, but any .svn-base file or files lacking an extension are unreachable.
50 comments
[ 65.1 ms ] story [ 831 ms ] threadGoogle translate is good at lexical translation but still can't bind words together properly (and probably never will unless they'd change their paradigm).
I have to add that original text is surprisingly incoherent. They surely didn't re-read it after they wrote it.
http://yoursite.com/index.php
then
http://yoursite.com/.svn/text-base/index.php.svn-base
for source code!
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.
http://www.subversionary.org/martintomes/preventing-access-t... http://blog.samdevore.com/archives/2006/05/01/hivelogic-prev...
The ideal way is to not take the risk in the first place. You can't forget something you don't have to do.
http://fr.php.net/.svn/entries secure
http://fr2.php.net/.svn/entries open
I use Mercurial on all my websites (disabling access to .*/.hg of course) and never use FTP for anything.
So when I deploy updates to sites we pull and update the changes then merge a locally stored patch queue to reconfigure the settings.
Because the settings are locally stored on the server (not in the site root) there is no way for people to steal the details from the public mercurial server :D
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.
Don't blame the tool, blame the individual for using it improperly.
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...
Security exploits aren't just bad for what they directly allow, they are bad for how they often combine well.
(You, AndrewDucker, may already know this; I'm not trying to imply otherwise. I'm saying this because this is a point that needs to be made more often, too many people ignore it. Any unauthorized access into your system needs to be taken very seriously, because of this risk.)
location ~ /\.(svn|git) { deny all; }
Oh. Now we're blacklisting.
If you are going to use this solution, you are better off blacklisting all dotfiles except .htaccess, assuming you allow it.
I thought not checking in safety critical things such as passwords or keys into the repository tree is a standard practice. If it's not, it should be.
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.
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.
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.
Saying it's not a vulnerability when 3,000 sites all have their source code visible to the world is like having your arm chopped off and saying "no it isn't, it's just a flesh wound."
I know it's not a cool remote root buffer overflow exploit hat trick 540 front side flip, but it's a security hole which people need to be educated about.
I guess it is a vulnerability of the same standard as "My password is: password".
I just don't understand why everyone is up-in-arms and so surprised by this "vulnerability." It's common sense...
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
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..
harm: We need more people who, upon finding a hole, go on to scan the whole Runet, for no nefarious reasons but just to warn unwitting site owners.
SilenceAndy: In olden times such people were called hackers, until journalists perverted that word to mean cyber criminals.
grayhex: This comment is impervious to Google Translate.
cancel: Google inurl:.svn/entries, lots of interesting stuff.
Nirvanko: This ain't new, see http://www.adamgotterer.com/2009/01/26/hacking-the-svn-direc...
SynteZ: IIS doesn't have this vulnerability :-) By default it doesn't send files without extensions, because it doesn't know the mime type.
varyen: Funny, Wii disks from SEGA also have .svn folders, though they're empty.
crazywebdev: Now I know how http://vkontakte.ru came about.
The issue is not in "using SVN". It's in using any revision control system that has .svn .git etc directories, and accidentally making those directories world readable from a webserver.
User error.
It appears that IIS is naively not serving up these file types. If I drop a plain html file in the .svn folder I can get to it, but any .svn-base file or files lacking an extension are unreachable.