You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My hosting provider runs a (rather basic) Web Application Firewall that prevents WP-DownloadManager from uploading files. When trying to upload a file with WP-DownloadManager, the following rule was tripped: ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "179"] [id "33340162"] [rev "294"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: URL detected as argument, possible RFI attempt detected"] [data "%TX:1,TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required.
After disabling the above rule, the next rule that caused problems is the following: ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "319"] [id "33340465"] [rev "56"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Remote File Injection attempt in ARGS (admin.php)"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "rx ://%{SERVER_NAME}/" against "ARGS:file_remote" required.
Unfortunately this rule cannot be disabled.
None of these rules are tripped if 'http://' is removed from "Remote File" field before uploading. Clearly, these rules are meant to prevent Remote File Injections, admittedly a little overzealous.
My expectation is that more people run into this issue but might not know how to read the error log. The WAF rules by Atomicorp are quite wide-spread. Now, these people will not be able to use the remote file upload through the form, as this would indeed by a RFI. However, we can still use the upload form without issue, provided it does not contain a stray 'http://' somewhere in the POST parameters.
Would you be open to changing this? Either by removing the default from the "Remote File" field (and maybe adding it when the user clicks it); or maybe even by splitting up the "Add File" form?
Cheers,
Niels
The text was updated successfully, but these errors were encountered:
Hi!
My hosting provider runs a (rather basic) Web Application Firewall that prevents WP-DownloadManager from uploading files. When trying to upload a file with WP-DownloadManager, the following rule was tripped:
ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "179"] [id "33340162"] [rev "294"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: URL detected as argument, possible RFI attempt detected"] [data "%TX:1,TX:1"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "beginsWith %{request_headers.host}" against "TX:1" required.
After disabling the above rule, the next rule that caused problems is the following:
ModSecurity: [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/50_plesk_basic_asl_rules.conf"] [line "319"] [id "33340465"] [rev "56"] [msg "Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Remote File Injection attempt in ARGS (admin.php)"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Match of "rx ://%{SERVER_NAME}/" against "ARGS:file_remote" required.
Unfortunately this rule cannot be disabled.
None of these rules are tripped if 'http://' is removed from "Remote File" field before uploading. Clearly, these rules are meant to prevent Remote File Injections, admittedly a little overzealous.
My expectation is that more people run into this issue but might not know how to read the error log. The WAF rules by Atomicorp are quite wide-spread. Now, these people will not be able to use the remote file upload through the form, as this would indeed by a RFI. However, we can still use the upload form without issue, provided it does not contain a stray 'http://' somewhere in the POST parameters.
Would you be open to changing this? Either by removing the default from the "Remote File" field (and maybe adding it when the user clicks it); or maybe even by splitting up the "Add File" form?
Cheers,
Niels
The text was updated successfully, but these errors were encountered: