Blade templates directly accessible via web browser on server

sage
,
1

While testing our application, we noticed that we were able to get directly at the raw blade templates by going to https://our.server.com/wp-content/themes/theme-name/resources/views/template-for-page.blade.php. This is possible because we know the directory structure and can browse directly to view the files, so the likelihood of an end user hitting this is fairly slim. However, it still directly exposes template code to the world.

Is this permitted by Sage 9 by default? Is there a configuration option within Sage 9 that prevents this access? Or should we be relying on .htaccess files or other web server methods to hide direct access to this directory?

6 Likes
2

Nice find. Never thought about it since I’m used to Laravel not having it’s views in the public folder– in this case, it might be a little more tricky.

Deploying a fix in Trellis for example would be trivial, but to do it widespread…I’m not so sure yet.

In the mean time, yeah– if you are worried about it, just handle it with .htaccess if you are using Apache.

deny from all inside of your resources/views/.htaccess should do the trick.

If you are using nginx, you can do this with:

location ~* \.(blade.php)$ {
    deny all;
    access_log off;
    log_not_found off;
}

Edit: I’ve pushed a fix to Trellis as seen here. Since server-side is the only way to prevent access

Sage docs also now show how to secure Blade templates

4 Likes
3

This snippet should address the issue in Apache 2.2 and 2.4:

<FilesMatch ".+\.(blade\.php)$">
    <IfModule mod_authz_core.c>
        # Apache 2.4
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        # Apache 2.2
        Order deny,allow
        Deny from all
    </IfModule>
</FilesMatch>
2 Likes
4

And what about /vendor/? Aside from Trellis, is it recommended to Deny all there, too? I assume that it is probably safe not to do so, but since there’s a gazillion files & packages, you can never be 100% sure, right? And since it is all included it should not have any downsides, right? Or am I missing something? It kinda does feel like a stupid question :smiley:

5

Wouldn’t worry about vendor. Most libs (esp. ones that are stock with Sage) will result in a blank file if accessed directly. The reason the Blade templates are more evasive is due to it showing unwarranted source code of your theme in plain text.

6

ah, of course!
I was curious and checked the outputs like this:

for i in $(find vendor/ -name '*.php'); do
  url="$(jq -r '.devUrl + .publicPath' resources/assets/config.json)/$i";
  echo $url;
  curl $url;
done

non-empty outputs:

vendor/symfony/process/Tests/NonStopableProcess.php
received vendor/symfony/process/Tests/ProcessBuilderTest.php

vendor/symfony/process/Tests/SignalListener.php
Caught vendor/symfony/process/Process.php

vendor/symfony/translation/Tests/fixtures/extractor/translation.html.php
This template is used for translation message extraction tests

vendor/squizlabs/php_codesniffer/scripts/build-phar.php
Building phpcs phar
	=> REDACTED/vendor/squizlabs/php_codesniffer/scripts/phpcs.phar
	=> adding files from package.xml... Unable to load package file:

Not sure, but the scripts… look benign :slight_smile:

7

I’ve gone with adding the usual <?php defined('ABSPATH') or die(); ?> to the top of my blade templates in the past.

Anyone aware of any issues arising from the use of php tags in the template file (other than it being ugly)? All seems to function as expected in my experience.

8

Blades get compiled to actual PHP, so it shouldn’t cause any problems (unless you have blade or blade-y stuff inside your PHP tags, and then it…might do something?).

9

This topic was automatically closed after 42 days. New replies are no longer allowed.