glFusion CMS 1.7.9 Host Header ATTACK

[Topsec-bunney]

After modifying the host value, you can still request to the website. This can easily lead to Man-in-the-MiddleAttack

[mark0263]

Is there a proof of concept that shows how this can be exploited? I don't disagree with validating the Host (and X-Forwarded-Host) with some type of whitelist. Looking thru the glFusion code, glFusion does not rely on or user the Host header. Is this more of a web server concern?

[Topsec-bunney]

This problem can be solved through the web server, but because the website uses many absolute paths, this is also one of the unsafe factors. If you fix it, you can change the absolute path of the website to a relative path, which is safer.

[walterrowe]

I have always disliked having absolute paths. It makes it more difficult to move sites from one host to another, or clone a production site to a test environment. Relative paths would be a welcome improvement.

Walter

On Dec 8, 2021, at 8:59 AM, Topsec_bunney @.***> wrote:

 This problem can be solved through the web server, but because the website uses many absolute paths, this is also one of the unsafe factors. If you fix it, you can change the absolute path of the website to a relative path, which is safer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[leegarner]

It wouldn't hurt to validate the host header, I'm not sure if it would hurt anything since everything gets redirected to site_url or site_admin_url anyway. Normally spoofing a host header will simply allow you to load a virtual host by curling the IP address

The "absolute" path is determined by the web server config. Normally you'd have a directive setting the document root to, in your case,

/glfusion-1.7.9/public_html. If the complete glFusion package is installed in the web server's document root, then the path would look like you describe, which also allows access to the "private" directory which is a bigger concern (though not a critical issue unless the web server is misconfigured). On Wed, Dec 8, 2021 at 5:59 AM Topsec_bunney ***@***.***> wrote: > This problem can be solved through the web server, but because the website > uses many absolute paths, this is also one of the unsafe factors. If you > fix it, you can change the absolute path of the website to a relative path, > which is safer. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > Triage notifications on the go with GitHub Mobile for iOS > > or Android > . > >

[mark0263]

Closing as this is a web server configuration concern