It was a while ago when I wrote about a random site taken out from “Applications Developed With Symfony” section.
As you can remember I simply wrote about possible problems that may expect owner of this site. Preventing measures includes deleting of _dev files as well as extra securing of backend. There were a bunch of controversion comments regards to that posting – e.g. “Ryan Weaver” wrote that it’s great idea and “halfer” wrote that I’d need to inform site owner before write about security faults ( look for more info here: http://www.symfonylab.com/review-of-williamandersonca/ )
Today I quickly went through a few of the other sites listed in developed with symfony applications and figured out that both frontend_dev.php and backend_dev.php files are present on most of them, here are only a few samples:
[removed due to developer request]
Btw, based on web debug bar I noticed that a few sites (e.g. [removed due to developer request]) are using the same SQL to get content from DB:
SELECT sf_dynamic_cms_nav.ID, sf_dynamic_cms_nav.NAME, sf_dynamic_cms_nav.APPLICATION, sf_dynamic_cms_nav.CULTURE, sf_dynamic_cms_nav.ADMIN_CREDENTIALS, sf_dynamic_cms_nav.EDITOR_CREDENTIALS, sf_dynamic_cms_nav.TEMPLATES, sf_dynamic_cms_nav.CREATED_AT, sf_dynamic_cms_nav.UPDATED_AT FROM sf_dynamic_cms_nav WHERE sf_dynamic_cms_nav.APPLICATION=’frontend’
So it must be the same person who created them or maybe there is sharable plugin for content management. If so I’d like to take a look on that as well 🙂
Btw, when I made a search for sf_dynamic_cms_nav table I quickly found one more test site with the same content management:
[removed due to request]
That’s becoming funny.. So Google indexes symfony debug toolbar. Guys, you have to be carefull – today they control your _dev files and tomorrow they will drink your beer!
And another one about this CMS of unknown author, it looks quite universal (contains CREDENTIALS, APPLICATION, CULTURE fields) and at this moment I started to remember about symfony sfSimpleCMS plugin.. Oh shame on me.. I had to think about that! So it’s the same sfSimpleCMS plugin but seems to be customized.
Well, anyway, I was going actually to tell you about the other security hole where you can go down. That’s about sfGuardUser plugin. I wont tell here about the sites where this problem is available but it’s a sign for them to check out theirselves.
So if you use sfGuardUser and allow people to signup, please make sure you’ll restrict their access to backend and allow only admin group users to have access to there by adding security.yml:
credentials: admin # Access with the admin credential
I know someone finds it obvious but I’m sure (actually I know) there are a lot of sites where this is skipped.
This way you can signup as e.g. subscriber and have admin access to backend.
So I told you and dont say you did not hear 😛
10 replies on “A note about Symfony security faults”
Right, very. But that’s not fair with people having the problems you describe.
What exactly is not fair?
I actually fell for the _dev problem as well. And actually, I still forgot to add it to the rsync_exclude list. need to do that.
It looks like 3 of 4 your examples is made by same person. At least they are on same host.
Anyway good points which hopelly are obvious most of us…
What’s unfair is to publish the urls where the dev front controllers are publicly available. this is a major security hole as it shows db queries, server env vars and so on.
You encourage exploits attempts and script kiddies challenges. That’s unfair, IMHO.
[…] A note about Symfony security faults […]
The risk of _dev.php files making it into deployment was a major concern for me from day one. Frameworks should make it hard to fail. Languages should make it hard to fail. PHP does this and symfony for the most part as well.
The good news there is a fix:
My preferred method “Adapt url/asset helper url generation” will become even easier in symfony 1.1
[…] A note about Symfony security faults […]
Also, for the site being spidered by Google: there are META robots tags in default view set to “index, follow.”
In case I would accidentaly get my _dev front controller to the test site (God forbid!), I have made a change in my app’s view.yml – therefore, polite robots won’t index my dev page. It’s not a security measure except by obscurity, but better than to have a vulnerability automatically indexed, no?
Here’s the change:
Oops, entity filtering ate my post
robots: <?php echo((SF_ENVIRONMENT == ‘dev’) ? ‘noindex, nofollow’ : ‘index,follow’); ?>