Also bear in mind that is only half the work. Whatever "pre-validation" or UX tweaks one does on the client, one still needs to do the actual validation on the server too.
On 1 March 2014 06:38, Russ Michaels <[email protected]> wrote: > > 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:357799 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
