As far as I know all links are generated with a site_url()
function which uses the URL that is set in the ipconfig.php file.
I’ve seen a thread here with a similar issue where a 403 was thrown because of the absolute URLs indeed.
I could not verify any http links in this situation.
What I could see is the following:
A: Cookie set to secure
The cookie is transferred through the https POST request to the server. For unknown reason (no logging) the server replies to the request sending a new cookie (session cookie if I am not mistaken).
B: Cookie not set to secure
The POST requested is sent in the same way except the cookie is not sent with the secure flags. The server reply sends as well a cookie with the same value as the one sent.
Conclusion:
The application/framework is either not accepting the cookie or is not able to match it to the established session as it seems. There is obviously a difference in handling this between the GET requests used to navigate the application (otherwise the login screen would be shown every time) and the POST requests.
How about configuring/enabling the use of the secure flags already from the application/framework? This could resolve the situation as the cookie sent from the server would be equally to the one the browser sends back.
If i remember correctly, symphony is used which seems to support it (https://github.com/symphonycms/symphony-2/issues/2627).
But I did not dig in that deep to understand which component is handling the cookies. I hope that helps.
You can already switch on secure cookies by adding COOKIE_SECURE=true
to your ipconfig.php file. Could you try this and check if it’s working?
By the way, the used framework is Codeigniter that uses some Symfony components.
Hi,
And I am back with more details.
The problematic element of the setting is not the “secure”, its the “HttpOnly”.
Is there a setting for it too?
Here is the culprit:
// Automatical CSRF protection for all POST requests
$.ajaxPrefilter(function (options) {
if (options.type === 'post' || options.type === 'POST' || options.type === 'Post') {
if (options.data === '') {
options.data += '?_ip_csrf=' + Cookies.get('ip_csrf_cookie');
} else {
options.data += '&_ip_csrf=' + Cookies.get('ip_csrf_cookie');
}
}
});
\InvoicePlane\assets\core\js\scripts.js
Line 147 + Line 149
Using JS to handle CSRF is very questionnable indeed
You might be interested in this as well: https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/X-XSS-Protection
For future reference: https://stackoverflow.com/questions/29680409/is-it-a-good-practice-to-store-the-csrf-token-in-meta-tag
Thabks for the setting. I will try it as soon as I can.
Thanks @musa, I use more then this one header setting preferences. I just listened only this one as the others seemed to be not relevant for this issue. - but thanks!
For completeness, there is a scanner from Mozilla called HTTP Observatory at https://observatory.mozilla.org/ which is able to check a website via ssl (https) and provides a list of good practice settings including the mentioned ones.
Sometimes people look in the wrong place.
Message: Access denied with code 403 (phase 2). Operator GT matched 255 at ARGS. [file “/usr/local/apache/conf/modsec_vendor_configs/comodo_apache/14_HTTP_Request.conf”] [line “24”] [id “210620”] [rev “1”] [msg “COMODO WAF: Too many arguments in request||www.invoices.domain.com|F|4”] [severity “WARNING”] [tag “CWAF”] [tag “Request”]
This one was actually the culprit on a cPanel server.
#
# Maximum number of arguments in request limited
#
SecRule &TX:MAX_NUM_ARGS "@eq 1" "chain, phase:request, t:none, block, msg:'Too many arguments in request', id:'960335', severity:'WARNING', rev:'2', ver:'OWASP_CRS/3.0.0', maturity:'9', accuracy:'9', tag:'application-multi', tag:'language-multi', tag:'platform-multi', tag:'attack-protocol', tag:'OWASP_CRS/POLICY/SIZE_LIMIT'"
SecRule &ARGS "@gt %{tx.max_num_args}" "t:none, setvar:'tx.msg=%{rule.msg}', setvar:tx.anomaly_score=+%{tx.notice_anomaly_score}, setvar:tx.%{rule.id}-OWASP_CRS/POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"