Re: Best practices for xss security in CMS? - Related Question
On Wed, Mar 5, 2014 at 11:16 AM, Nick Gleason n.glea...@citysoft.comwrote: 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:scriptCODE HERE/scriptThat will be a problem? Why? Hi Nick, Yes if you have the following: Content-Security-Policy: default-src 'self'; It will block any scriptcode here/script tags in your page, you can only use script src=/some/uri/script 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: script nonce=random_string_123code here/script 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:scriptCODE HERE/scriptThat 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 n.glea...@citysoft.com 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
On Sun, Mar 2, 2014 at 11:21 PM, Nick Gleason n.glea...@citysoft.comwrote:
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:
cfoutputYour search for #url.query# returned #search.recordcount#
results/cfoutput
There is an XSS risk there because someone could create a link to
/search.cfm?query=scriptalert('xss')/script (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? - 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
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? - 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
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
