Form Bug?
Permalink
c5 8.1 (new) Form block. Tried adding a Select field with a colon in the 'Question' and received a series of 403 errors from the server when trying to save the block. Seems to work fine without the colon. Perhaps there's a lack of input sanitization (escaping) in the new block.
Anyone able to verify?
Anyone able to verify?
The 403 error suggests to me that it could be triggering mod security errors.
I don't think concrete5 itself return 403 errors anyway.
I'd say ask your host to check their mod security logs around the time that you've triggered the errors - they may need to whitelist some rules.
I don't think concrete5 itself return 403 errors anyway.
I'd say ask your host to check their mod security logs around the time that you've triggered the errors - they may need to whitelist some rules.
Thanks for your thoughts, guys.
The 403s are definitely from the server: the error message mentions litespeed.
It gets weirder. When I add a question 'date:' (including the colon), it's fine. When I add a question 'data' (without colon), it's fine. When I add a question 'data:' (with colon), I get the errors shown in the attachments.
I've tried 'select' and 'text' question types with the same results, so the field type does not appear to be relevant.
This issue is so strange that I'm loathe to mention it. Could it be that something somewhere is parsing for the string 'data:'??
The 403s are definitely from the server: the error message mentions litespeed.
It gets weirder. When I add a question 'date:' (including the colon), it's fine. When I add a question 'data' (without colon), it's fine. When I add a question 'data:' (with colon), I get the errors shown in the attachments.
I've tried 'select' and 'text' question types with the same results, so the field type does not appear to be relevant.
This issue is so strange that I'm loathe to mention it. Could it be that something somewhere is parsing for the string 'data:'??
Yep, pretty confident that's a mod security issue, not a concrete5 one.
You'll need to contact the server to either whitelist the rule that is being triggered or disable modsec. Sometimes you can do that via your host's control panel (I've seen it in cPanel a few times), but it is better to whitelist rules.
My guess would be that there is a mod security rule in play that is seeing data: as a potential malicious request. It's the start of what would be seen as a Data URI, which could then potentially have some sort of file in it. (e.g. you'll see that in this example:https://css-tricks.com/data-uris/)...
Whereas date: doesn't really have any meaning in css/html. So you're just inadvertantly triggering a mod security rule with the content you're entering.
You'll need to contact the server to either whitelist the rule that is being triggered or disable modsec. Sometimes you can do that via your host's control panel (I've seen it in cPanel a few times), but it is better to whitelist rules.
My guess would be that there is a mod security rule in play that is seeing data: as a potential malicious request. It's the start of what would be seen as a Data URI, which could then potentially have some sort of file in it. (e.g. you'll see that in this example:https://css-tricks.com/data-uris/)...
Whereas date: doesn't really have any meaning in css/html. So you're just inadvertantly triggering a mod security rule with the content you're entering.
Thanks mesuva; I guess that's credible. Shouldn't it mean that ANY attempt to store a string containing 'data:' should result in the same problem? I can say 'data:' in a content block without any problems. I still can't help but wonder if there's a parsing/escaping/sanitization thing happening or not happening in the Form context.
Mod security is (purposely) a bit of a mystery machine when it comes to knowing what it will pick up via its ruleset.
I've seen it pick up chunks of html with un-ordered lists, just because of particular words in it, or a certain combo of things. I've seen the same content work in a content block, but not in a page attribute, it all just comes down to the thousands of patterns that it uses to detect malicious activity.
I've never seen a 403 be returned from a server, when it's based on content, that hasn't been a mod security rule being triggered.
I've seen it pick up chunks of html with un-ordered lists, just because of particular words in it, or a certain combo of things. I've seen the same content work in a content block, but not in a page attribute, it all just comes down to the thousands of patterns that it uses to detect malicious activity.
I've never seen a 403 be returned from a server, when it's based on content, that hasn't been a mod security rule being triggered.
Thanks again. mod_security sounds like a maintenance nightmare. The path of least resistance will doubtless be for me to rethink the question!
It can be annoying, but i've found that it tends to happen fairly infrequently.
I'll test out a site, hit some 403s and just contact my host. They're used to whitelisting rules, so it's just a case of being able to point out the time and the script URL (if you can work it out). Tends to take less than 5 mins to resolve, then it's never a problem for that site to have. A good host will have support that can do that for you quickly.
It's one of those things where the benefits of having it on out weight the occasional nuisance of it.
I'll test out a site, hit some 403s and just contact my host. They're used to whitelisting rules, so it's just a case of being able to point out the time and the script URL (if you can work it out). Tends to take less than 5 mins to resolve, then it's never a problem for that site to have. A good host will have support that can do that for you quickly.
It's one of those things where the benefits of having it on out weight the occasional nuisance of it.
I was unable to reproduce the error.