Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.On any webform, if you insert a "<" before any word, it will make that word hidden from the report display. You can see it only when you Edit.
e.g.: for a First Name field, type John <Doe and only John will show.
But the most bizarre and possible-security issue is when you have a mandatory field, typing a single < can skip it, therefore making the mandatory field non-mandatory!
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | proper-escaping.png | 104.9 KB | quicksketch |
Comments
Comment #1
Vako CreditAttribution: Vako commentedThis issue is only applicable if you 'flush' a character after the "<", i.e.: no spaces after it.
Actually this 'phenomenon' is also applicable to the comment box in Drupal.
Try it by replying to this post and typing
"This is a test to <validate this issueeverything after the "<" will not be visible and you will only see "This is a test to".you can check it by clicking on the Preview button below.
Comment #2
Vako CreditAttribution: Vako commentedTesting:
This is a test to
Comment #3
vernond CreditAttribution: vernond commentedThe disappearing magic happens because of the text format input filters where Drupal strips out what appears to be invalid/not-allowed HTML from user input. Because there is no corresponding closing tag it strips everything from the opening tag to the end of the string. It's a security feature, not a security problem.
Comment #4
Vako CreditAttribution: Vako commentedDon't you think that people can hide malicious scripts in comments and webforms, make forms fail also cause confusion...?
I discovered this when some mandatory fields in my Webform report were empty...so this 'security feature' became a Webform problem for me.
Comment #5
quicksketchThis is indeed a bug if it is occurring on the data submitted by users from the front-end webform. Administrator fields (such as those for setting up the Label of a component) intentionally support only some HTML tags like
<em> <strong> <br>. Other HTML tags are stripped out. If you'd like to have a < sign (without a space after it), you would have to format your label as<Doe.From the report it's not clear which field you've filled out in which you're experiencing this behavior. If you're only having this problem when assigning a component a label, then it is indeed by design.
Comment #6
Vako CreditAttribution: Vako commentedIt happens on any of the form fields exposed to users. e.g.: if you have Name, Phone#, email and email being Mandatory, I can type
<blankin the email field and make it appear blank.Actually I found this when users were entering blank info on my form.
It's not urgent, but something to keep in-mind.
Comment #7
quicksketchThanks for the followup. All user-entered information should be displayed exactly as it was entered everywhere throughout Webform, so this looks like we have a call to _webform_filter_xss() somewhere (which strips out tags) where we should actually be calling check_plain() (which escapes HTML entities instead of stripping them).
Comment #8
Vako CreditAttribution: Vako commentedNote that this issue also happens on Drupal comments, like this one. I had to put the "
<code>" to be able to show you the message in post#6.Comment #9
quicksketchYes that's true that the same thing happens on Drupal comments and nodes, that's because both of them are specifically designed to accept HTML tags. If you want to post HTML code in a comment, you wrap your HTML in
<code>brackets.Webform on the other hand is *not* meant to accept HTML input of any type from the end-user, which is why this particular issue is a bug for Webform. We have the ability to fix this problem specifically, versus the way comments and nodes work in Drupal (which is by-design).
Comment #10
quicksketchIn the two years that have passed, this problem seems to have been cleared. I never saw the problem originally to begin with, which makes me think it may have been fixed in the versions even at the time this report was filed. Attached are screenshots of the 6.x-3.x branch showing the values getting properly escaped everywhere properly. If there's a situation where the characters are not escaped properly, please create a new issue detailing exactly the circumstances under which a field value disappears or shows unescaped.