View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0018566||phpList 3 application||Statistics||public||09-03-17 17:52||20-11-19 19:59|
|Target Version||next patch||Fixed in Version|
|Summary||0018566: Link clicks fail when signed with hmac|
|Description||After enabling SIGN_WITH_HMAC in the config file I found that link clicks failed with the message "Invalid request".|
It appears that on this particular server $_SERVER["REQUEST_SCHEME"] is not populated, which causes phplist to use an incomplete url when calculating the expected hmac value, within file lt.php.
Further, it appears that _SERVER["REQUEST_SCHEME"] is non-standard as it is does not appear in the php documentation of $_SERVER, http://php.net/manual/en/reserved.variables.server.php
One topic on stack overflow http://stackoverflow.com/questions/18008135/is-serverrequest-scheme-reliable suggests to use $_SERVER["HTTPS"] instead of or as well as $_SERVER["REQUEST_SCHEME"].
This particular server is running LiteSpeed with php 7.1.2 and does populate $_SERVER["HTTPS"] with "on".
But two other servers I looked at (apache/mod_php and FastCGI) do populate $_SERVER["REQUEST_SCHEME"] and have not populated $_SERVER["HTTPS"] but I am using http not https so that might be expected.
|Tags||No tags attached.|
Just looked at another server, which is running FastCGI, accessed using https.
Both $_SERVER["REQUEST_SCHEME"] (value "https") and $_SERVER["HTTPS"] (value "on") are populated.
It seems the existence of $_SERVER["HTTPS"] and its value equals "on" mean that the scheme is https.
I'm not fully aware of exactly what the hmac is protecting, presumably the tid parameter, but should the hmac verification process use the same method as the hmac generation?
The code that generates the hmac uses config values $public_scheme, $website etc, and those might not match the actual scheme or host when the link click is processed. For example if the web site redirects http to https then the actual scheme would differ from the scheme used in the hmac calculation.
Ah, that will be good to fix.
The HMAC protects "tampering" with the URL.
With the HMAC you can't change the parameters and see what happens.
||Is this issue now resolved?|
no, this is not resolved. I will need to do one of two:
1. not include the scheme before signing
2. better detect the scheme
I think 1 is the most failsafe for now.