
Using SVN makes your site extremely vulnerable - fdeth
http://translate.google.com/translate?prev=hp&hl=en&js=y&u=http%3A%2F%2Fhabrahabr.ru%2Fblogs%2Finfosecurity%2F70330%2F&sl=ru&tl=en&history_state0=
======
hassy
Summary:

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

------
ionfish
For your Apache config.

    
    
      # Disallow viewing of .svn and .git directory contents
      <DirectoryMatch \.(svn|git)>
        Order allow,deny
        Deny from all
      </DirectoryMatch>

~~~
bcl
May as well throw in .hg

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.

~~~
ionfish
Even if you do use .htaccess files, you still shouldn't be showing them to
anyone who requests them from your web server!

~~~
bcl
Ha! Correct!

------
axod
Title is misleading and plain wrong.

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.

------
cousin_it
Russian speaker here, I'll translate some selected comments for your
convenience.

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...](http://www.adamgotterer.com/2009/01/26/hacking-the-svn-
directory/) _

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

------
Sujan
Using a working copy as your website is a pretty bad idea. That's what svn
export is meant for.

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

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

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

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

~~~
walesmd
But Apache isn't misconfigured in this instance - a file was uploaded and
people are claiming that being able to view that file is a vulnerability.

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

------
InclinedPlane
tl;dr Don't accidentally leave an svn working copy available to the internet,
it could be a security vulnerability.

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

~~~
InclinedPlane
Yup, exactly. s/repositories/working copies/. I've been using git/hg too much
lately.

------
brown9-2
From 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..

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

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

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

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

------
masklinn
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)

------
fdeth
Sorry for the machine translation but an English text is not up just yet.

~~~
DannoHung
It's actually surprisingly coherent. Is Russian easier to translate than other
languages or has Google's automated translation just gotten that good?

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

------
kennu
Git is much nicer, because everything is in one .git directory and it can be
kept outside the public webroot.

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

------
AndrewDucker
It'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...

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

~~~
AndrewDucker
Of course, you database _really_ shouldn't be externally visible...

~~~
jerf
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.)

------
bcl
Well duh. You shouldn't be publishing your repository. Use svn export instead.

