will it all depends on several factors. how many forms do you have within your site that result in content being inserted into the database and then displayed on the page. If your CMS is the only place this happens and this is password protected then you can afford to be more flexible about what tags you allow. However relying on passwords alone is almost pointless these days unless you at the very least enforce some password strength, as your security is then only as strong as the person with the weakest password. You could consider some extra steps for any back end/cms system, such a restricting access by IP address, which is done at web server level. How you do this depends on how many users you have and if they have static IP's and if they are likley connect remotely from mobile devices etc. If you only have a small number of static IP's to allow, then do that. If adding specific IP's is bot viable, then use a VPN, and then just allow the IP of the VPN server, which will allow your users to connect from anywhere and any device as long as they have a vpn connection. The other other is 2 factor authentication. This is actually easier than it seems, take a look at google authenticator for a real simple solution.
On Mon, Mar 3, 2014 at 4:12 AM, Nick Gleason <[email protected]> wrote: > > 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:357810 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
