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 <[email protected]> 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 <[email protected]> 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 <[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:357802 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
