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
