Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I am getting a page forbidden because mod_security blocks it with Remote File Injection in ARGS rule.
How do I stop this apart from not including URLs in the form fields or removing the http:// prefix of the URL before submission to the update script (data is updated from the form).
The hosting company had to remove some rules to stop this happening before but even after rewriting the forms it is still happening.
How do I rewrite the form to stop the firewall error?
I am assuming your hosts are using the Atomicorp mod_security rule set. The error "Remote File Injection attempt in ARGS" is documented here; you can see the code here.
This rule disallows input that looks like a URL from all fields, on the assumption that any mention of a URL is an attempt to get the application to fetch and execute the content at that URL. This is vanishingly unlikely and pretty pointless, but no-one said WAFs were clever.
Because naturally this breaks almost every site, the rule includes loads of exceptions for widely-used web applications. It looks like if you put a string that resembles a known application in your URL (eg jomsocial/x/add), or use a known application's parameter name for your URL (eg origin), you'd probably be able to evade the rule. Of course the exceptions list contains lots of applications that actually have suffered from multiple serious security holes, but no-one said WAFs were clever.
In general WAFs like this and other complex mod_security rulesets aren't much good as intrusion protection for general-purpose web applications. They need specific configuration to recognise what input is and isn't expected, and for custom applications you wrote yourself the effort involved in doing that configuration is usually better spent making sure input is handled appropriately in the application itself.
(They can be useful for intrusion attempt detection, and for patching up problems in someone else's software you can't change - or as a temporary measure until you can fix it properly. But blanket-deploying them against random custom software is not sensible, and rewriting custom software to circumvent WAF blocks isn't really productive or sustainable.)
If your hosting company insists on using an instance of mod_security outside your control to block perfectly valid application input, I would look for a hosting company with more clever.
Ask your provider to make sure they are using modsecurity 2.7.3 or higher, and that they have enabled this option:
--enable-htaccess-config
When they compiled the Apache modsecurity DSO.
This will let you disable this rule, and other rules, using .htaccess. The format to disable a rule in .htaccess, provided this is enabled, is documented at the URL below:
https://www.atomicorp.com/wiki/index.php/Mod_security#Specific_actions_available_in_.htaccess
