Lack of interest Add "Whitlisting" for File health check, for self changed Files

[Masetrix]

A whitelist for entries in the file health check to avoid this:



and so on.....

Reason:
I additionally compress the graphics on the server, as well as the graphics of Xenforo.
Then the "File health check" shows many "Falsepositves".

Also, I have to change the source code for many an addon which shows many "false positives" in the "File health check".
In principle, that's a good thing, but you do not recognize in the multitude of "false positives" anymore if an unwanted change to other checked files actually takes place.
A whitelist for yourself and wanted changed files could help here.

 

[Ozzy47]

Honestly, that would be a bad idea. Say you edit a file, and white list it. Now I as a hacker get access to your site. I see you have files whitelisted from the health check. I now know I can safely add my injection code into those files any you would be none the wiser.

 

[Masetrix]

Honestly, that would be a bad idea. Say you edit a file, and white list it. Now I as a hacker get access to your site. I see you have files whitelisted from the health check. I now know I can safely add my injection code into those files any you would be none the wiser.

The problem already exists when I have changed files and must ignore them in the FHC. Without whitelist or adaptation of new hashes, however, I do not see whether files have been changed that I have not changed, that's just not possible with hundreds of entries. With whitelisting I would notice such files but immediately as they appear in the FHC.

 

[Ozzy47]

Exactly, that is why it is recommended not to edit files.

Amyway, you can create your own hashes.json on for the addons after you make changes, then the changes won't trigger the health check.

XF 2.0 - How do I create hashes.json for changes in an addon

I paid a developer to create an addon for me and I have made changes to within the addon itself so the hashes.json file is all wrong. So I was wondering if someone could spell out for me in very simple terms how can I create a hashes.json file for the addon that now has the changes in it. Please...

xenforo.com

 

[Kirby]

Now I as a hacker get access to your site. I see you have files whitelisted from the health check.

Well, if an attacker can gain access to the system and modify files at will, he can also just modify hashes.json or modify the code to whitelist the modified files - that doesn't really add much protection

That said, I agree that a whitelist isn't a that great idea but I can also understand the desire to have such a feature.
It's pretty much the same for any kind of logs and why we have tools like logcheck and it's ignore rules.

As far as optimized resources are concerned:
This can be dealt with by using clever server configuration - store the optimized resources in another place (add a suffix, use another directory, etc.) and point the server there (via alias, try_files, rewrite, etc.).
This way you can easily serve optimized resources while not touching the original files.

Btw: Compressing Add-on icons (eg. images referenced from addon.json) is really unnecessary - those are being served inline as base64 in backend only; do you care for those being optimized?
If you really do, even that would be possible with by extending \XF\AddOn\AddOn::getIconUri().

The whole src directory is set as deny from all via .htacess, so with a default setup nothing can be served from there directly.
And if Add-ons are servering resources from there, they are IMHO badly coded and must be fixed - resources should go to js and styles.
Therfore, I personally would not bother with src at all.

Doing this would cut down the modified files from the screenshot significantly.

The modified files from the screenshot are extendable classes, so I'd just write extensions for them to add the required changes.

 

[frm]

Instead of whitelisting it, possibly have the option to ignore it to not see the message again, but, retain a copy of the newly edited file. Then, if it's edited again, show a warning with the last modification date so that it can be looked at again and quite possibly, in the same way, templates are, compare versions?

This would be better than whitelisting in my opinion as you can easily revert back to the "old" (your edit) or even back to the original (what ships with XF).

 

[Kirby]

IMHO, that doesn't sound too bad
Though "even back to the original" would be difficult, this would require to keep a pristine copy of the whole tree.
That would be huge amount of overhead and IMHO not worth it.

 

[Snog]

The whole src directory is set as deny from all via .htacess, so with a default setup nothing can be served from there directly.
And if Add-ons are servering resources from there, they are IMHO badly coded and must e fixed - resources should go to js and styles.
Therfore, I personally would not bother with src at all.

The images in src are the icons that are displayed in the admin add-on list. They should be there if they exist and are picked up during add-in installation via the addon.json file's "icon": "icon.png".

While I understand the idea behind a white list, it goes against the whole idea behind the file hash check. It's there to notify people if a file becomes corrupt or is somehow changed. Creating a white list would generally allow any changes to the files that are in the white list, thus opening a point of possible attack via those files or allowing those files to become corrupt and the site admin would never have any idea that happened.

As @Kirby said there are other, better methods to change file contents. So far as images go, I would be more inclined to create new images and use a template modification (not edit the stock template itself) to point to the new images.

 

[Kirby]

The images in src are the icons that are displayed in the admin add-on list. They should be there if they exist and are picked up during add-in installation via the addon.json file's "icon": "icon.png".

Of course. I implicitly talked about "production" resources only, eg. images/js/fonts/whatever that an Add-on would use by itself for normal operation.

Template modifications might also work, but depending on how an Add-on references a resource (hardcoded in a file?) it might be difficult.

 

[frm]

IMHO, that doesn't sound too bad
Though "even back to the original" would be difficult, this would require to keep a pristine copy of the whole tree.
That would be huge amount of overhead and IMHO not worth it.

Could be kept on XF servers and compared (hashes first to reduce bandwidth*), as updates are now pushed that way anyway.

 

[Snog]

Of course. I implicitly talked about "production" resources only, eg. images/js/fonts/whatever that an Add-on would use by itself for normal operation.

Template modifications might also work, but depending on how an Add-on references a resource (hardcoded in a file?) it might be difficult.

Well, if an add-on is modified, for now the easiest thing to do would be to completely remove the hashes.json file from the add-on folder. Then nothing will be checked for that add-on.

OR, remove the file that's been modified from the add-on's hashes.json file (untested).

 

[Kirby]

Could be kept on XF servers and compared (hashes first to reduce bandwidth*), as updates are now pushed that way anyway.

What about (paid) Add-ons?
XF would have to set up an infrastructure to keep original hashes for RM Add-ons (with dozens of versions) and authors offering Add-ons on their own website would have to maintan the same infrastructure as well.

 

[sbj]

I would agree that an "ignore" feature would be nice to have.

 

[Masetrix]

Exactly, that is why it is recommended not to edit files

Unfortunately, the editing of addons can not be avoided. There are add-on developers who do not patch their addons (anymore), or only very late. There is nothing left for me to do but modify myself. In some cases it is also easy to debugging an addon and find a mistake yourself as a contact to the developer.

 

[Vekseid]

Unfortunately, the editing of addons can not be avoided. There are add-on developers who do not patch their addons (anymore), or only very late. There is nothing left for me to do but modify myself. In some cases it is also easy to debugging an addon and find a mistake yourself as a contact to the developer.

It's best in this case to just make your own version of the mod.

 

[Ozzy47]

Unfortunately, the editing of addons can not be avoided. There are add-on developers who do not patch their addons (anymore), or only very late. There is nothing left for me to do but modify myself. In some cases it is also easy to debugging an addon and find a mistake yourself as a contact to the developer.

It's best in this case to just make your own version of the mod.

Which is why you edit the addons on a development site, then build the addon, and upgrade the addon on the live site with the new files.

Then you don't need to whitelist the files, and they will show up if anyone else changes them.

 

[Masetrix]

First of all, thanks for your answers.
Setting up an environment for software development exceeds the time I can spend on it. Then there would be synonymous nor the problem with the compressed graphics files what one has to rebuild each hash individually.
To save this time we have purchased a fee-based forum software. (...)

Maybe just a way to disable the feature could be integrated. Tripwire does a good job on our server and can do whitelisting.

 

[Ozzy47]

I’ve created a paid addon to ignore/whitelist files you know have been edited,

[OzzModz] Ignore Files From Health Check

At times we might need to edit core or addon files. The issue is that we are plagued with the dreaded file health check results showing up on the ACP index. Well this addon solves that. Now if you have edited a file, you can add it to the ignore...

xenforo.com

 

[Ozzy47]

@Kirby why sad?

 

[Kirby]

I don't like this suggestion and I therefore think it's a bad idea to offer an Add-on that does implement this.