RE: Best practices for xss security in CMS?
Hi Guys, thanks for all the responses - much appreciated. Dave, this is an interesting idea which we haven't pursued yet. I don't have a clear sense of how the server configuration would work here. Would you have two separate db servers (one for authored content and one for published content) that would sync up? Or would you have an authoring infrastructure that would then generate more traditional static html? I'm just trying to get a sense of how the separation would work. N -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: Friday, February 28, 2014 8:29 AM To: cf-talk Subject: Re: Best practices for xss security in CMS? 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:357805 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Best practices for xss security in CMS?
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:r...@michaels.me.uk] 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 dwa...@figleaf.com 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
RE: Best practices for xss security in CMS?
Right now we are using a combination of portcullis plus home grown filters within the application as well within the web server (which we control). We would definitely consider looking at Fuseguard as well (but haven't yet). N -Original Message- From: Adam Cameron [mailto:dacc...@gmail.com] Sent: Friday, February 28, 2014 11:10 AM To: cf-talk Subject: Re: Best practices for xss security in CMS? Sorry, I only read as far as disabling Javascript and was commenting on that. The fact remains that anything done *clientside* is not reliable. It seems we're not disagreeing there, Certainly having a WAF is borderline essential on anything other than a trivial site. I'm not entirely sure doing @ CF level is the correct place to do it, but that's an aside. Sorry for confusion. -- Adam On 1 March 2014 07:59, Russ Michaels r...@michaels.me.uk wrote: I disagree 100% scanning All form fields globally for any dodgy content is the complete opposite of narrow sighted, it is a much more efficient way to make sure nothing gets through rather than instead trying to do these checks in multiple different places and potentially missing one. On Fri, Feb 28, 2014 at 6:56 PM, Adam Cameron dacc...@gmail.com wrote: That's a bit narrow-sighted. Hackers don't disable JS to bypass clientside pre-validation, they just post the form directly. Often the server code is not coded in such a way to be aware how a post is made (via a legit form, or just by a POST request). *Always* consider client-side pre-validation a nice to have and really more a UX (hey, you malformed that phone number, wanna try again? sort of thing) consideration than actual validation. And *always *do validation on the server. -- Adam On 1 March 2014 07:44, Russ Michaels r...@michaels.me.uk wrote: 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. ~| 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:357807 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Best practices for xss security in CMS?
Hi Adam, Can you tell me a little more about what you mean by coding in order to prevent posting directly to a form and bypassing validation? Nick -Original Message- From: Adam Cameron [mailto:dacc...@gmail.com] Sent: Friday, February 28, 2014 10:56 AM To: cf-talk Subject: Re: Best practices for xss security in CMS? That's a bit narrow-sighted. Hackers don't disable JS to bypass clientside pre-validation, they just post the form directly. Often the server code is not coded in such a way to be aware how a post is made (via a legit form, or just by a POST request). *Always* consider client-side pre-validation a nice to have and really more a UX (hey, you malformed that phone number, wanna try again? sort of thing) consideration than actual validation. And *always *do validation on the server. -- Adam On 1 March 2014 07:44, Russ Michaels r...@michaels.me.uk wrote: 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 dacc...@gmail.com 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 r...@michaels.me.uk 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 dwa...@figleaf.com 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:357808 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Best practices for xss security in CMS? - Related Question
Hi guys, Following up on this thread I have a related question - what are some examples of XSS scenarios other than comments and forum posts. As I have researched the topic, it seems like a lot of the XSS examples given relate to users posting to comments and forums. That's good to understand but is not a prominent part of our system at the moment. So, I'm hoping to get some other scenarios / examples where there may be risk. Many of our forms submit data but don't necessarily display back to other users the way that comments would. Any other prominent risk scenarios for XSS? N -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Friday, February 28, 2014 11:58 AM To: cf-talk Subject: Re: Best practices for xss security in CMS? tsk, not reading properly before replying is very naughty, I will set Charlie Arehart on you. I am quite confident that fuseguard would do a better job than a generic WAF on a CF site, and anyone of shared hosting wont really have the option to do a server wide solution. but certainly if you use multiple technologies on your server then I agree that a generic WAF would be the better way to go, and there are some IIS modules I which you can enable just on your own site using the web.config (helicon do this), so don't need server access, apache is probably the same. On Fri, Feb 28, 2014 at 7:10 PM, Adam Cameron dacc...@gmail.com wrote: Sorry, I only read as far as disabling Javascript and was commenting on that. The fact remains that anything done *clientside* is not reliable. It seems we're not disagreeing there, Certainly having a WAF is borderline essential on anything other than a trivial site. I'm not entirely sure doing @ CF level is the correct place to do it, but that's an aside. Sorry for confusion. -- Adam On 1 March 2014 07:59, Russ Michaels r...@michaels.me.uk wrote: I disagree 100% scanning All form fields globally for any dodgy content is the complete opposite of narrow sighted, it is a much more efficient way to make sure nothing gets through rather than instead trying to do these checks in multiple different places and potentially missing one. On Fri, Feb 28, 2014 at 6:56 PM, Adam Cameron dacc...@gmail.com wrote: That's a bit narrow-sighted. Hackers don't disable JS to bypass clientside pre-validation, they just post the form directly. Often the server code is not coded in such a way to be aware how a post is made (via a legit form, or just by a POST request). *Always* consider client-side pre-validation a nice to have and really more a UX (hey, you malformed that phone number, wanna try again? sort of thing) consideration than actual validation. And *always *do validation on the server. -- Adam On 1 March 2014 07:44, Russ Michaels r...@michaels.me.uk wrote: 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. ~| 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:357809 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
