Changing the way Pageimage renames resized files

[Nelson]

Hello everyone,

I've run into a issue with the way Processwire renames resized files in our company host provider.

Basically, this pattern: myfile.0x120.png, conflicts with their security policy which they tag with the following classification:

[severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"]

So, somehow, when requesting a file with the pattern above, the server mistakes it for a malicious request and throws a 403 Forbidden Access.

The quickest solution I've found for this was to dive into the Pageimage::size method and replace the characters used in the resized file name.

Instead of using double periods in the name file, I've replaced everything with the '-' (hyphen) character and now looks like this: myfile-0-120.png.

$basename .= '-' . $width . '-' . $height . "." . $this->ext(); // i.e. myfile-100-100.jpg

It's not the prettiest pattern and I liked the older one better but that's secondary. The main issue here is that this change is basically an hack and feels dirty changing core methods, but it was the quickest solution I've thought of.

What are your feelings on this?

[DaveP]

I suspect that the '0x120' is being mistaken for an injection attack as it is a hexadecimal number. (288 in decimal)

Pretty unsophisticated filter to reject a string for one (possibly) hex character.

[Exceptionz Project]

It would be better to contact your provider to disable that rule (by ID) / add an exception / or adjust the rules for your host (for that specified false positive)...

Some rule sets of mod_security (or other request filter / application layer firewalls) are producing false positives in such usage cases.

[Nelson]

Hi, thanks for the replies!

I've contacted the host support and asked if there's a possibility of adding an exception to the security rules so those requests wouldn't be blocked.

They responded that they can disable the protection software, ModSec Rules, to our user account. I know nothing about this software or what are the implications of disabling this protection but don't think it would be worth the risk for just one change in our code base.

[Exceptionz Project]

Providers are sometimes willful...

I would try again to convince your provider to add your request as an exception since it is only 3-4 lines in the exceptions config file in mod_security.

<LocationMatch /url/to/your/application/request>
<IfModule mod_security2.c>
SecRuleRemoveById IDHERE
</IfModule>
</LocationMatch>

By the way; mod_security could be -if configured well- a very efficient application layer firewall for webhosts... So it is better not to deactivate it for the vhost, if you don't have any other firewalls/security solutions for your vhost.

[Nelson]

Thank you Exceptionz, I really appreciate your help!

We've decided to keep it this way for now, although, if this proves to be a much of an hassle in the future, maybe then, we'll try to contact them again.

Thank you very much!