Re: Best practices for xss security in CMS? - Related Question
On Wed, Mar 5, 2014 at 11:16 AM, Nick Gleason wrote: > > Hi Pete, > I've been researching CSP and it sounds like a pretty cool option. But, I > just wanted to follow up on this comment that you made > below:-- it will also block inline > scripts and style elements-- > > Are you saying that even if you have the "self" or "default" values in > place, it will block a regular old script in your page? For instance, if > you just have something like this:CODE HEREThat will be a > problem? Why? > Hi Nick, Yes if you have the following: Content-Security-Policy: default-src 'self'; It will block any code here tags in your page, you can only use This is a recognized problem in CSP1.0 and CSP 1.1 is currently in development right now with two solutions for this use case, you can specify a nonce in the header, so you would do something like this: Content-Security-Policy: script-src 'self' 'nonce-random_string_123'; Then you can do this: code here You can do the same for inline style tags. See http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#nonce-usage-for-script-elements The second option in CSP1.1 is hash whitelisting, where you compute a hash of the script contents and put that in the header. See http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#hash-usage-for-script-elements -- 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:357861 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 Pete, I've been researching CSP and it sounds like a pretty cool option. But, I just wanted to follow up on this comment that you made below:-- it will also block inline scripts and style elements-- Are you saying that even if you have the "self" or "default" values in place, it will block a regular old script in your page? For instance, if you just have something like this:CODE HEREThat will be a problem? Why? That seems like a pretty big issue since there are lots of legitimate reasons to have a javascript in a web page. I just want to make sure that I am understanding the situation. Thanks! Nick ~| 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:357850 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
On Mon, Mar 3, 2014 at 5:11 PM, Nick Gleason wrote: > > Pete, > > Much appreciated. I guess where I'm being a bit of a dunce is that in your > example, if a malicious url.query variable was passed in by a hacker, > wouldn't the display only be available on that single request? And if I > come to the same search form 2 minutes later and do a normal search, won't > it be clean? I guess that, assuming we have no sql injection to the db, I > don't see how that attack stays persistent (as it would possibly for a > comment or forum post). Sorry to be over-simple on this. > Hi Nick, It is not a persistent attack unless it gets saved to a DB somewhere, etc. But it is still considered harmful, for example if I send you a link that uses javascript to write a login form on the page that submits to my server... then that is not a good thing. Normal visitors can't parse a query string to recognize that it is rewriting the DOM, especially when they see HTTPS they expect that everything on the page is as you intended it. Or the attacker might simply grab cookies and use them to hijack the victim's session. These examples are a bit more targeted, they will probably effect every user of the site but the attacker can use the hole to eventually get the info they are after. > Re: the content security policy, that looks very interesting. Watching a > presentation on it now. One quick question. If we are using that on a > site > and then an admin comes in and uses an iframe widget from youtube to > display > a video on a page in the site, does that get filtered by CSP (and require > an > exception for youtube)? I gather that would need to be excepted in the > frame-src header, right? > Yes you would have to allow the youtube.com domain in your CSP header, eg: Content-Security-Policy: default-src 'self'; frame-src 'self' youtube.com; One thing to keep in mind with Content-Security-Policy is that when you enable it, it will also block inline scripts and style elements, you can override that using unsalfe-inline but then you also loose a lot of the benefits of CSP. ~| 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:357846 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
To clarify, I was oversimplifying above when I said 'code is being executed on your server'. Pete's script example would of course need to link up with some other vulnerability for that to happen (i.e. an unpatched exploit of some kind). Since you can't predict such things, you minimize the number of liberties someone can take with your server's tender innocence. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:357817 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
Nick you are correct, strictly speaking. That simple example is harmless, it runs only one time and is 'visible' only to the single client. Consider what happens if the payload that is executed is nowhere nearly as benign. At that point, code of some kind is being executed on your server that does something you don't intend, and regardless of the fact it only executes once, it could make all sorts of mischief depending on its level of sophistication. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:357816 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, This is very interesting. In this case, we limit failed logins to a fairly small number before the login is disabled so in theory that would prevent dictionary style attacks, even against fairly weak logins. If you think that is flawed, let me know. We've discussed adding an IP filter, although I was thinking that we would try to do it within the application code rather than at the web server in case someone doesn't have access to the web server configuration. I suppose it could be done in web.config as well (on IIS), but it seems like it would be easier for client to manage to have the IP list within the user's record. It would be nice if we could essentially ban all foreign IPs from admin access (when it made sense for a client), but when researching that a while back it seemed a little tricky. With google style 2 factor authentication, I get the idea of requesting a numeric code in a text message - that doesn't sound terribly complicated. But, I'm sure that people would want to elect to "stay logged in on this computer" and I'm not clear on how best to manage that. Thanks again. Nick ~| 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:357814 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?
You could manage the web.config ip filter via cf. You can also have the option to disable 2 factor authentication for a specific computer for 30 days which is a common option, using either a cookie or ip logging. Russ Michaels www.michaels.me.uk cfmldeveloper.com cflive.net cfsearch.com On 3 Mar 2014 22:22, "Nick Gleason" wrote: > > Hi Russ, > > This is very interesting. In this case, we limit failed logins to a fairly > small number before the login is disabled so in theory that would prevent > dictionary style attacks, even against fairly weak logins. If you think > that is flawed, let me know. > > We've discussed adding an IP filter, although I was thinking that we would > try to do it within the application code rather than at the web server in > case someone doesn't have access to the web server configuration. I > suppose > it could be done in web.config as well (on IIS), but it seems like it would > be easier for client to manage to have the IP list within the user's > record. > > It would be nice if we could essentially ban all foreign IPs from admin > access (when it made sense for a client), but when researching that a while > back it seemed a little tricky. > > With google style 2 factor authentication, I get the idea of requesting a > numeric code in a text message - that doesn't sound terribly complicated. > But, I'm sure that people would want to elect to "stay logged in on this > computer" and I'm not clear on how best to manage that. > > Thanks again. > > Nick > > > > > > ~| 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:357815 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
Pete, Much appreciated. I guess where I'm being a bit of a dunce is that in your example, if a malicious url.query variable was passed in by a hacker, wouldn't the display only be available on that single request? And if I come to the same search form 2 minutes later and do a normal search, won't it be clean? I guess that, assuming we have no sql injection to the db, I don't see how that attack stays persistent (as it would possibly for a comment or forum post). Sorry to be over-simple on this. Re: the content security policy, that looks very interesting. Watching a presentation on it now. One quick question. If we are using that on a site and then an admin comes in and uses an iframe widget from youtube to display a video on a page in the site, does that get filtered by CSP (and require an exception for youtube)? I gather that would need to be excepted in the frame-src header, right? Nick ~| 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:357813 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
On Sun, Mar 2, 2014 at 11:21 PM, Nick Gleason wrote:
>
> 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.
> Any other prominent risk scenarios for XSS?
>
There are a lot of scenarios, essentially anywhere you output a variable
that originated in some part from an external source.
So for example, let's say you have a search form for your site with some
code like this:
Your search for #url.query# returned #search.recordcount#
results
There is an XSS risk there because someone could create a link to
/search.cfm?query=alert('xss') (now if you try that
example in a modern browser you will find that it might not actually work
due to the builtin XSS protection in browsers, but the hole is there and
there are ways to bypass the browsers xss protection).
So basically any time you take a variable that comes from the user or some
other untrusted source and output it, you have the potential for an XSS
hole.
Also you should checkout Content-Security-Policy headers this can help
reduce XSS risks significantly on browsers that support it. See:
http://content-security-policy.com/ for more info or come to my
cf.Objective(2014) presentation :)
--
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:357812
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?
> 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. It can vary, but it's usually pretty simple: an authoring environment and a production environment where content is published. This by itself really has nothing to do with preventing XSS on its face, but it prevents unauthorized users from being able to create content - the production environment simply has no way to allow users to create or edit content. These environments typically either share a database, or data is migrated automatically from one database to another. Of course, we still need to sanitize content prior to production, but we only have to worry about people with access to the physical network where the authoring environment lives. This is often a fairly small group, and hopefully a more trustworthy group. 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:357811 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?
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 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: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 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
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 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 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 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 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
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 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 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 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
> 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
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 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 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 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 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 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
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
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 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 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 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 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
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 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 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 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?
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 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 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 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 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
> > 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
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 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 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 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
> 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
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 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 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 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
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 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 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
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 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
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
Re: Best practices for xss security in CMS?
Thanks very much Pete. We have implemented Portcullis among other things and that will also block tags like the ones mentioned. I think that may be similar to the ones that you mention. I expect that Fuseguard has something similar. I guess my follow up question may have to be with what kind of policy to create. Blocking those tags 100% of the time feels draconian. Blocking them 0% of the time feels risky. I expect that we need to develop rules for allowing some people (e.g. web master, super user, etc.) to use them while perhaps blocking others. Does anyone on this list have experience with how to make those trade-offs effectively? Nick ~| 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:357716 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 Nick, It is tricky to handle HTML content while avoiding XSS, there are a two tools I'm aware of that can help you here: 1) scrubHTML() - This is one I built in pure CFML and I think it is pretty easy to build a whitelist of allowed html using it: https://github.com/foundeo/cfml-security it will use your whitelist and only allow HTML tags and attributes that you allow to come out the other end, anything not matching the whitelist is removed. 2) AntiSamy - written in java, widely used, but its policy files can be tricky to work with, example using it with CFML: http://www.petefreitag.com/item/760.cfm -- 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 On Wed, Feb 19, 2014 at 11:08 PM, Nick Gleason wrote: > > Hi All, > 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
Best practices for xss security in CMS?
Hi All, 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
