Robert Basic's blog

Posts tagged 'security'

PHP-FPM security limit extensions issue

by Robert Basic on February 03, 2017.

For the first time ever I saw this error:

2017/02/03 11:45:04 [error] 14656#0: *1 FastCGI sent in stderr: "Access to the script '/var/www/web' has been
denied (see security.limit_extensions)" while reading response header from upstream, client: 127.0.0.1, server:
proj.loc, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/www.sock:", host: "proj.loc"

I mean… what? security.limit_extensions? I honestly never heard of this before.

The PHP manual describes it as:

Limits the extensions of the main script FPM will allow to parse. This can prevent configuration mistakes on the web server side. You should only limit FPM to .php extensions to prevent malicious users to use other extensions to execute php code. Default value: .php .phar

Basically to avoid executing what an application might consider as a non-PHP file as a PHP file.

OK, cool, but why am I getting this error?

The currently top answer on Google suggests setting the list of limited extensions to an empty string, to practically disable the security.limit_extensions configuration. That fixes the error, but I’m really not comfortable with setting a security related configuration to a blank value, especially when people smarter than me set that configuration to a sane default value.

There must be a better, proper way to fix this, and this does feel like I misconfigured something in the nginx/php-fpm stack.

Accessing a folder as a script?

The Access to the script '/var/www/web' has been denied part of the error messages also looks weird. Why would php-fpm try to access /var/www/web, which is a directory, as a script? Seems like it doesn’t see the actual PHP script, and that sounds awfully similar to that old, dreaded No input file specified error message.

And that one is, in most cases, caused by not including the fastcgi.conf params file in the location block in the nginx configuration files. I double checked the configuration file and yup, I missed to include the fastcgi params file:

server {
    # configuration for the server
    location ~ \.php$ {
        # configuration for php
        include fastcgi.conf; # << I missed this!
    }
}

I restarted nginx and everything works just fine, without touching the security.limit_extensions configuration.

Happy hackin’!

Tags: configuration, fastcgi, limit_extensions, nginx, php-fpm, security.
Categories: Development, Software.

Defining multiple security rules in XML format for Symfony2

by Robert Basic on August 25, 2011.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

This one falls into a category of bogus Symfony2 documentation. Or inconsistent behavior. Or whatever. It’s a bit frustrating.

I’ve chosen to use XML to define different settings across my sf2 apps: routing, ORM, services and of course security.

Symfony2’s security stuff let’s you define rules based on URL matching witch is, to some extent, explained in the documentation. The examples for YAML works fine, but for XML it’s kinda bogus.

The example says:

<access-control>
    <rule path="^/admin/users" role="ROLE_SUPER_ADMIN"></rule>
    <rule path="^/admin" role="ROLE_ADMIN"></rule>
</access-control>

which will actually die in a fire with an ugly as hell exception: InvalidConfigurationException: Unrecognized options “0, 1” under “security.access_control.rule”. Thanks, that’s helpful. The funny thing is that if you have only one rule defined, it works!

After an hour of hunting up and down, I finally found the solution in the test fixtures of the SecurityBundle!

The solution is to omit the access-control tags:

<rule path="^/admin/users" role="ROLE_SUPER_ADMIN"></rule>
<rule path="^/admin" role="ROLE_ADMIN"></rule>

I thought about submitting an issue against the code, but as the fixtures use this format, I’ll open up a ticket against the docs. A real WTF moment.

Happy hackin’!

Update, August 26th, 2011:

Defining roles suffers from the same bug. So, instead of using:

<role-hierarchy>
    <role id="ROLE_ADMIN" >Admin</role>
    <role id="ROLE_SUPER_ADMIN">Super admin</role>
</role-hierarchy>

use:

<role id="ROLE_ADMIN" >Admin</role>
<role id="ROLE_SUPER_ADMIN">Super admin</role>
Tags: rule, security, symfony2, xml.
Categories: Development, Programming.

Importing Symfony2 security settings from a bundle

by Robert Basic on August 25, 2011.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

I started to work on/figuring out the security part in Symfony2 and one part where the docs fail so far is to explain how to import security settings from a bundle.

Once I put some thinking into it, it’s pretty easy actually. Simply import the needed security file in your main config file. Something like this will work:

# app/config/config.yml
imports:
    - { resource: parameters.ini }
    - { resource: '@AcmeDemoBundle/Resources/config/security.xml' }

where the security.xml file is the same as already described in the documentation.

Happy hackin’!

P.S.: Bonus tip: When googling for symfony2 stuff, start your query with +symfony2 to include only symfony2 results. Makes life a bit easier.

Tags: bundle, security, symfony2.
Categories: Development, Programming.

Bad Firebug!

by Robert Basic on December 21, 2009.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

We all know about Firebug, probably the best developer add-on out there, and how awesome it is and how many times it helped us debug some nasty Javascript code, mess around with CSS and HTML on-the-fly, to track the time load of every external page element our app loads… It’s so cool that it even has it’s own add-ons! (FirePHP, YSlow and FireCookie). Really, it helps our developer lives to suck a bit less.

Note: the following text is not about bashing other developers and their works, but to highlight the importance of proper input filtering. I myself have failed on this, several times.

Let’s go back to the part where we mess with the HTML by the means of this, may I say, application. You can add, hide, remove HTML elements, add, alter, remove, attributes from HTML elements… Adding, hiding, deleting - boring; altering - fun! I have this urge to try to break every form on every website I find. Not to do any harm, just to take a look how my fellow developer did his job and if I see anything that’s not right, I try to contact him to fix that, cause, y’know, I’m a nice person… Anyhow, I recently found some sites where all the textfields and textareas were filtered properly and no harm could be done - all my “hack” attempts were caught by their application. Nice. Oh, look, a select box! Right-click, inspect element, value=“xyz”, change that to value=“abc”, submit the form… and poof! A sexy SQL error. All that with the help of our li’l friend, Firebug. The elements where the user is required to provide some information “by hand” were processed correctly, but the select box was not.

OK, let’s take this one step further. On a site where the user can register an account and afterwards can edit his or hers profile. I register, go to the user panel, the usual stuff - change email, password, location, DoB (Date of Birth)… A quick inspection of the source - a hidden field “id” with a number in it. Hmm… Quickly, I register another account, note the “id” on that second account, go back to the first account, change the “id” of the first account to the “id” of the second account, change the DoB (just to see any actual information changing), click submit… “Your profile has been updated successfully.” Mine? Not really, the DoB is like it was in the first place… Go to the second account… Oh boy. I successfully changed the DoB of the second account, with my first account. Now, I haven’t seen their source code, but I can imagine what was going on. Something like this:

<?php
$id = (int)$_POST['id'];
$dob = $_POST['dob'];

$sql = "UPDATE users SET dob = '" . $dob . "' WHERE id = " . $id;

On the positive side, when I entered letters in that hidden field, I was told by the app that I haven’t filled all the fields correctly, which means they filtered even the hidden field, but skipped to check if that “id” is actually me.

OK, I know, the title is “Bad Firebug!” and the problems are actually about filtering user input, but I needed a catchy title to have your attention on Twitter :P

Even tho a field seems “unchangeable”, with a help of an awesome little app, it becomes changeable. And dangerous.

Filter input, escape output :)

P.S.: On the image above you can see my profile on a bulletin board, where I changed my year of birth from 1986 to 986 with Firebug. The years are in a select box; the lowest value is 1910. You can see my actual profile here.

Tags: escaping, example, filter, firebug, php, security.
Categories: Development, Programming, Software.