although these days if a user has javascript disabled they wont be able to use the cms at all as it is a requirement for the editor and all the AJAXy stuff. but what you can do, is apply filtering to all form fields at a global level, so any form submission any page will have anything dodgy removed. I believe FuseGuard will do this for you.
On Fri, Feb 28, 2014 at 6:34 PM, Adam Cameron <[email protected]> wrote: > > 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:357800 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
