Apache ofuscating/rewriting form elements id

Help! (Home for newbies)
1
SYSTEM INFORMATION
OS type and version Rocky Linux 9.7
Virtualmin version 7.40.1

Hello everyone:

After installing a new server, based in Rocky Linux 9.7, I have found an unexpected behaviour.

When serving HTML provided from a PHP application, the server alters content, rewriting ids of DOM elements related with forms, changing with random characters the original ids.

I know this is a security related practice, some times recommended, but I have never found myself in a host acting that way without a specific personalized configuration.

The problem comes from the fact the ids are used by some javascript codes, and while scripting included in content is updated in some elements, some other are not detected and changed, and shared javascript files are obviously unchanged, preventing many actions to work.

I know mod_security2 can be configured to make such behaviour, but it does not look like activated and neither being installed at all.

Is somebody aware of the origin of such behaviour and how to deactivate?

2

It is definitely nothing Virtualmin is doing. I’m pretty sure it’d have to be something in your app, either at the PHP or JavaScript level.

3

No, exactly the same application, with exactly same code, is executing in other two different servers and not showing such behaviour.

It is in house development - we know every line of code.

4

Hmmm…in that case, I think I’m stumped. None of the Apache modules that could do anything like that are enabled in a default Virtualmin system.

Have you enabled any extra modules in Apache? mod_perl, mod_substitute, anything along those lines?

If not, you’ll need to narrow it down somehow. Maybe some caching layer? Redis? Something else that might be serving old results? I dunno. But, probably not Apache (and definitely not Virtualmin, as we don’t manage any of the Apache modules that could do that).

5
  • Have you tried running your browser in private mode with no plugins and then read the html response?
  • A database connection collation issue? i.e. you store you stuff in utf8mb4_unicode_ci but the database connection is latin_swedish_ci etc…
6

I have partially adjusted description.

I have checked the process is made on the PHP part of ecuation. If serving plain HTML files it does not happen.

It happens in every browser, and not related with codepages at all - HTML content that is altered is mostly coming from included plain files, not generated by PHP processing

7

if you can disable apache modules until this behaviour stops.

8

If this is a new server why VM 7.40.1? I was going to ask the if you knew of any differences with the 2 that are ‘working’ and noticed this. Differing php versions?

9

This is the first one with Rocky 9, using default apache and php packages.

The others using Rocky 8, generally using PHP packages coming from REMI

10

A quick search brings this up.
drupal.stackexchange.com/questions/265806/messed-up-div-ids-for-ajax-modified-form-fielddrupal.stackexchange.com/questions/265806/messed-up-div-ids-for-ajax-modified-form-field

11

OK, I have found the issue as a strange behaviour in a included php security module.

Not a by defect configuration, but an inherited fail related to a non standard OVH operating system image. It got solved by some packages update.

Thanks a lot for your interest to all.

1 Like
12

which PHP module? :smiley:

13

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.