Re: array2.equals(array1) how to show difference?
Is it possible there is whitespace appended to some of the array values? Byron Mann Lead Engineer Architect HostMySite.com On Feb 27, 2014 7:32 PM, morchella morchella.delici...@gmail.com wrote: hey guys i have two, 2 dimensional arrays. they have 3 columns. i have used #array2.equals(array1)# to show when they are difference and then just continue with normal logic. but now i have an instance where they say no the don't equal. but for the life of me i cant visually see the difference in the query's i am using cf9 locally and 10 on the server. how can i force the different record(S) to display. thanks a bunch, -m ~| 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:357787 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: array2.equals(array1) how to show difference?
Bear in minf that when you sue the .equals() method, you are using a *Java* method, so it will also be considering differences in type too (eg: Long vs Double, etc). Plus casing differences too. To check stuff at a CFML level, write a recursive function which takes both arrays, and which loops over the array, either doing a compare() if the value is simple (output both values, and the comparison result), or re-calling itself if it's an array. I'm interested to know what your data is in that you've found a two-dimensional array is the best fit for a data-type. That's pretty rare in business applications (which most CFML apps are, so assuming yours is too). -- Adam On 28 February 2014 11:29, Byron Mann byronos...@gmail.com wrote: Is it possible there is whitespace appended to some of the array values? Byron Mann Lead Engineer Architect HostMySite.com On Feb 27, 2014 7:32 PM, morchella morchella.delici...@gmail.com wrote: hey guys i have two, 2 dimensional arrays. they have 3 columns. i have used #array2.equals(array1)# to show when they are difference and then just continue with normal logic. but now i have an instance where they say no the don't equal. but for the life of me i cant visually see the difference in the query's i am using cf9 locally and 10 on the server. how can i force the different record(S) to display. thanks a bunch, -m ~| 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:357788 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: ColdFusion ListServ app
The other thing I'd recommend is using an email server with list capability and then having a CF front-end to handle web-based subscriptions and archives rather than doing the actual list distribution in CF. On 2/27/14 2:32 PM, Russ Michaels wrote: Thanks Joah, that is what I was thinking. The site it is tied to is a closed website where users have access via login and pw. I want to tie the front end to their user accounts and only allow posts from authenticated users. This is why I want it tied to CF and Google Group will not meet the requirements. Looks like I may have to write something. ~| 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:357789 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: ColdFusion ListServ app
Jonah, sorry. ~| 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:357790 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: ColdFusion ListServ app
actually google groups can do this. You can have private/closed groups using Google Apps (as apposed to the free gmail version) which are not publicly accessible, and users must login with their google login to access them on the web. You can then control membership via the web interface or via the api (using CF) The other most commonly use LlistServ I know of is MailMan On Fri, Feb 28, 2014 at 2:26 PM, Jeff Horne jeff.ho...@trizetto.com wrote: The other thing I'd recommend is using an email server with list capability and then having a CF front-end to handle web-based subscriptions and archives rather than doing the actual list distribution in CF. On 2/27/14 2:32 PM, Russ Michaels wrote: Thanks Joah, that is what I was thinking. The site it is tied to is a closed website where users have access via login and pw. I want to tie the front end to their user accounts and only allow posts from authenticated users. This is why I want it tied to CF and Google Group will not meet the requirements. Looks like I may have to write something. ~| 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:357791 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: array2.equals(array1) how to show difference?
ok that may be it. i have trinmed and lcased every thing, stripped out the html et. one array is populated from oracle, the other from mysql. weeks ago i had to put cfprocessingdirective pageencoding=UTF-8 in my cfc due to charecters coming in with odd junk. my reg cf comparison shows my data to be equal. just not using the .equals thingy i kinda dont trust it now... Thanks! -m On Fri, Feb 28, 2014 at 6:47 AM, Adam Cameron dacc...@gmail.com wrote: Bear in minf that when you sue the .equals() method, you are using a *Java* method, so it will also be considering differences in type too (eg: Long vs Double, etc). Plus casing differences too. To check stuff at a CFML level, write a recursive function which takes both arrays, and which loops over the array, either doing a compare() if the value is simple (output both values, and the comparison result), or re-calling itself if it's an array. I'm interested to know what your data is in that you've found a two-dimensional array is the best fit for a data-type. That's pretty rare in business applications (which most CFML apps are, so assuming yours is too). -- Adam On 28 February 2014 11:29, Byron Mann byronos...@gmail.com wrote: Is it possible there is whitespace appended to some of the array values? Byron Mann Lead Engineer Architect HostMySite.com On Feb 27, 2014 7:32 PM, morchella morchella.delici...@gmail.com wrote: hey guys i have two, 2 dimensional arrays. they have 3 columns. i have used #array2.equals(array1)# to show when they are difference and then just continue with normal logic. but now i have an instance where they say no the don't equal. but for the life of me i cant visually see the difference in the query's i am using cf9 locally and 10 on the server. how can i force the different record(S) to display. thanks a bunch, -m ~| 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:357792 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: array2.equals(array1) how to show difference?
Just a note: cfprocessingdirective pageencoding=UTF-8 has no bearing whatsoever on the content of DATA, it only relates to the code within the file itself, so will not be relevant unless you are populating of of the arrays via actual code (which you are not, based on what you say here). -- Adam On 28 February 2014 14:41, morchella morchella.delici...@gmail.com wrote: ok that may be it. i have trinmed and lcased every thing, stripped out the html et. one array is populated from oracle, the other from mysql. weeks ago i had to put cfprocessingdirective pageencoding=UTF-8 in my cfc due to charecters coming in with odd junk. my reg cf comparison shows my data to be equal. just not using the .equals thingy i kinda dont trust it now... Thanks! -m On Fri, Feb 28, 2014 at 6:47 AM, Adam Cameron dacc...@gmail.com wrote: Bear in minf that when you sue the .equals() method, you are using a *Java* method, so it will also be considering differences in type too (eg: Long vs Double, etc). Plus casing differences too. To check stuff at a CFML level, write a recursive function which takes both arrays, and which loops over the array, either doing a compare() if the value is simple (output both values, and the comparison result), or re-calling itself if it's an array. I'm interested to know what your data is in that you've found a two-dimensional array is the best fit for a data-type. That's pretty rare in business applications (which most CFML apps are, so assuming yours is too). -- Adam On 28 February 2014 11:29, Byron Mann byronos...@gmail.com wrote: Is it possible there is whitespace appended to some of the array values? Byron Mann Lead Engineer Architect HostMySite.com On Feb 27, 2014 7:32 PM, morchella morchella.delici...@gmail.com wrote: hey guys i have two, 2 dimensional arrays. they have 3 columns. i have used #array2.equals(array1)# to show when they are difference and then just continue with normal logic. but now i have an instance where they say no the don't equal. but for the life of me i cant visually see the difference in the query's i am using cf9 locally and 10 on the server. how can i force the different record(S) to display. thanks a bunch, -m ~| 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:357793 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Versions of Apache Supported on CF10 Linux?
On Tue, Feb 25, 2014 at 8:32 PM, Steve 'Cutter' Blades cold.fus...@cutterscrossing.com wrote: It does support Apache on 64-bit Windows, just not 64-bit Apache. I would not be surprised if the Linux stuff is the same. 64 bit Apache on Linux does work with CF10 and CF9 for that matter, I've set it up on several servers with out any issues. No building from source necessary. -- Pete Freitag - Adobe Community Professional http://foundeo.com/ - ColdFusion Consulting Products http://hackmycf.com - Is your ColdFusion Server Secure? http://www.youtube.com/watch?v=ubESB87vl5U - FuseGuard your CFML in 10 minutes ~| 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:357794 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: ColdFusion ListServ app
actually google groups can do this. You can have private/closed groups using Google Apps (as apposed to the free gmail version) which are not publicly accessible, and users must login with their google login to access them on the web. You can then control membership via the web interface or via the api (using CF) The other most commonly use LlistServ I know of is MailMan I'm in the process of moving my last lists from Mailman to Google Groups. I wouldn't recommend going the other way! Russ is right: you can certainly do this with Google Groups for Business. You'd need to buy a Google Apps for Business account, but you'd only need a seat or two, at a cost of $50/user/year. The Google Apps APIs can be used easily from CF. This would take far less time than building a listserv in CF, and would work a lot better. Your users would not actually need to have a Google account to send mail, though - they'd simply have to send email from the address that you've registered within the group. They would need to have a Google account associated with that address if they wanted to view the list posts in a forum. Fortunately, it's easy to create a Google account corresponding to any given email address, whether you're using Gmail or not. You'd have to provide instructions to your users on how to do that, but it's very simple - just choose I prefer to use my current email address in the signup form. 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:357795 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: ColdFusion ListServ app
For the mailing lists I run is powered by software called Sympa. www.sympa.org. It utilizes MySQL back end and I am working on a cfml interface for it Sent while utilizing a mobile device. Please excuse the Brevity of this message. On Feb 28, 2014, at 9:55 AM, Dave Watts dwa...@figleaf.com wrote: actually google groups can do this. You can have private/closed groups using Google Apps (as apposed to the free gmail version) which are not publicly accessible, and users must login with their google login to access them on the web. You can then control membership via the web interface or via the api (using CF) The other most commonly use LlistServ I know of is MailMan I'm in the process of moving my last lists from Mailman to Google Groups. I wouldn't recommend going the other way! Russ is right: you can certainly do this with Google Groups for Business. You'd need to buy a Google Apps for Business account, but you'd only need a seat or two, at a cost of $50/user/year. The Google Apps APIs can be used easily from CF. This would take far less time than building a listserv in CF, and would work a lot better. Your users would not actually need to have a Google account to send mail, though - they'd simply have to send email from the address that you've registered within the group. They would need to have a Google account associated with that address if they wanted to view the list posts in a forum. Fortunately, it's easy to create a Google account corresponding to any given email address, whether you're using Gmail or not. You'd have to provide instructions to your users on how to do that, but it's very simple - just choose I prefer to use my current email address in the signup form. 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:357796 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?
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:357797 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?
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:357798 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?
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:357799 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?
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:357800 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?
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:357801 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?
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. 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:357802 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?
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:357803 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?
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:357804 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
