Hi Russ, Yes, we can definitely turn these tags on and off. The challenge is that if we follow OWASP closely, then we shut off tags that clients genuinely need (e.g. iframe for youtube content). So, we're trying to figure out how to give clients adequate features without opening up too much risk. Of course, publishing is behind a login so there is that kind of restriction in place before you even get to an editor to publish.
I'm curious how wordpress handles this issue. From the little research I have done, it seems that none of these tags (iframe, embed, object) are blocked by default in wordpress installations. I would think that would open them up to some risk, but perhaps having the editor behind a secure login mitigates the risk to a large extent. Thanks again! Nick -----Original Message----- From: Russ Michaels [mailto:[email protected]] Sent: Friday, February 28, 2014 9:39 AM To: cf-talk Subject: Re: Best practices for xss security in CMS? with any decent editor including CKeditor and tinyMCE, you can specify down to a granular level which html tags and attributes are allowed/not allowed, just check the docs and there should be a config file somewhere in your CMS that instantiates the editor where you can modify these settings. So it is pretty easy to do as you need. It is also a good idea to restrict other tags to avoid numpty editors from just copying and pasting content which screws up the layout. On Fri, Feb 28, 2014 at 4:29 PM, Dave Watts <[email protected]> wrote: > > > I'm very interested in your feedback on best practices when 1) > > trying to mitigate risk of XSS and other hacks while 2) providing > > CMS functionality that includes a web editor that clients use to publish web pages. > > For example, there are many tags like <style>, <iframe>, and <embed> > > that are considered risks by OWASP and others but are also typically > > needed by CMS users to create web pages, embed youtube videos, and the like. > > We're thinking through how to manage the trade offs so that we > > protect clients but don't frustrate them in making their web pages. > > I'd love to know how others are managing these issues effectively. > > Our users who are creating web pages with an editor (FCKeditor) are > > generally working behind a login as administrators, so there is that > > login > security - > > not anyone can use the editor to create a web page. But, we have > generally > > had a lot more security than that. > > I'm assuming that there are users of Mura, Farcry and other CMS's on > > this list and I'd love to know how you have addressed these risks. > > While Pete's responses are great (as always), you might also consider > whether you can apply more "traditional" network access controls to > the problem. For example, you might be able to separate authoring from > publishing entirely, so that authors go to one server and viewers just > go to the production publishing server. We do this for quite a few of > our customers. This isn't necessarily a replacement for client > injection risk mitigation, but it can be a great complement. > > Dave Watts, CTO, Fig Leaf Software > 1-202-527-9569 > http://www.figleaf.com/ > http://training.figleaf.com/ > > Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA > Schedule, and provides the highest caliber vendor-authorized > instruction at our training centers, online, or onsite. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:357806 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
