Does using /bundles/ path for assets expose any security risk?

Question

I am using the /bundles/ path for images in my twig template, e.g.

<link href="{{ asset('bundles/acmedemo/css/contact.css') }}" rel="stylesheet" />
<img src="{{ asset('bundles/acmedemo/images/image.jpg') }}">
<img src="/bundles/acmedemo/images/image.jpg">

is there any security risk to this, to where a user might then know im using the symfony fw, and exploit something, or a user might learn my bundle name, which who knows what this could lead to, or a user might be able to hot link files which i know can be corrected by server settings, but is there any problems with doing it this way as far as obfuscation and security go?

please note, im developing an enterprise site based on this fw, and im bound to non-disclosure, etc.., its not like its an open-source bundle or anything.

Answer 1

Nice question.

Theoretically, it shouldn't. Symfony should be secure enough so that, knowing you're using Symfony and/or even the exact version you're running, a hacker still won't be able to harm your application. (assuming that you've configured everything correctly, including your web server etc.)

However, in reality there always remains a possibility of a vulnerability in your code or in some vendor's code. You might indeed want to make it just a little less easier for a potential attacker, by hiding the framework you're using so that even if there is a vulnerability in your application, the attacker won't know that you're using that specific framework without trying all possibilities first.

An interesting article about this subject is Hide your Web stack. It basically gives the following tips to obfuscate not only the use of Symfony, but also of PHP and Apache (or whatever webserver you're using):

• (Symfony) Some obvious steps such as replacing the default Symfony favicon, not deploying app_dev.php and config.php in production, and creating custom error pages.
• (Symfony) Rename app.php or configure the web server to return a 404 if someone tries to access app.php directly, because the name of the file will be an indication of the use of Symfony.
• (Symfony) Serve your assets from a non-default location, because /bundles/etc is pretty characteristic for Symfony. For instance, use app/console assets:install path when you install your assets, replacing path with a custom location.
• (Symfony) Don't deploy default public assets that come with Symfony, such as stylesheets and images used by the debug bar. They are of no use in production, and because their history is publicly visible at GitHub they can be used to determine the version of Symfony you're using.
• (PHP) Change the default cookie name to obfuscate the use of PHP.
• (PHP) Disable extra HTTP headers that give away the use of PHP (such as X-Powered-By). This can be done by adding expose_php = off to php.ini.
• (Web server) As for PHP, disable extra HTTP headers that advertise the name and version of your web server.

You might even want to go a step further, by not only hiding the details of your application, but instead disguising it as something else. For instance, you could disguise PHP as another scripting language, in the hope that an attacker will try some specific vulnerabilities of that language, and give up after a couple of unsuccessful attempts. However, you should be careful with that, only do this when you're sure there are no unexpected side effects. Also, don't forget that if your actual software and the software you're disguising it as suffer from the same vulnerabilities, you're back where you started...