So a client came to me, freaking out, because a spammy end user had dropped a bunch of script tags (that just popped up new windows) into a textarea on a webform he'd created. This is easy enough to deal with in each webform's "additional processing" area, but it strikes me that you'd almost always want to strip out at least certain HTML tags from all textareas, or run the "filtered HTML" input filter on them, before putting them into the database. I think there's presently no way to do this, right? Would it be helpful if I wrote a patch that did it (at least for textareas)?

Comments

bdimaggio’s picture

bdimaggio
he/him
Location Boston, MA
CreditAttribution: bdimaggio commented

oops-- forgot to mention that these scripts were only causing a problem when the client went to "results" for the webform and looked at the table view, thus running the scripts in his browser.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Version: 5.x-2.6 » 5.x-2.7
Component: User interface » Code
Category: feature » bug
Priority: Normal » Critical
Status: Active » Fixed

This issue was fixed in the latest Webform release -- see SA-CONTRIB-2009-032.

It's actually a security issue, because the scripts that these users were able to post could easily be harmful. If you come across any potential security issues in the future, please make sure to report them privately to the Drupal security team rather than posting them in the public issue queue -- see http://drupal.org/security-team for more information. Thanks!

Also, one more thing... although it did turn out that there was a security flaw in the code that would allow the behavior you describe, it was something that would only be triggered under unusual circumstances. A more common possibility that would lead to the same behavior is if the site's default input format is not configured safely. So I recommend double checking that the default input format is configured safely and does not allow script tags or other harmful tags to pass through. I'm guessing from your description that you probably did experience the security issue (and therefore the site will be fine when it is upgraded to 5.x-2.7), but a poorly-configured default format is a more common mistake that would also lead to this problem as well as a variety of other security risks on your site, so I thought I'd mention it!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

omerida’s picture

omerida CreditAttribution: omerida commented

Friendly reminder - If you're working with multi-page forms and echo or reuse user supplied data from a previous page on a subsequent page, it will not be filtered/sanitized.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Additional friendly reminder: There's nothing about that problem that's specific to multi-page forms :)

You should always filter/sanitize user-supplied data before displaying it, regardless of whether it was just entered or whether you loaded it from the database. See, for example, http://drupal.org/node/28984