On Wed, 2010-01-20 at 10:30 -0800, Michael A. Peters wrote: > Rene Veerman wrote: > > Michael, while i respect your choices, i think you should know that > > jquery.com is pretty good at minimizing browser-incompatibility > > headaches (and keeping js apps small), and the quircks that are left > > are easy enough to learn about. > > > > for things whereby > > - the server needs to generate tons of HTML for a small(ish) dataset, or > > - the client generates data (also to be translated to html) that the > > server doesnt really need to know about (yet) > > > > js can really take some stress off the server. > > I also like to run any content that has user contributed data through a > server side filter that enforces Content Security Policy - > > http://www.clfsrpm.net/xss/ > > That filter makes sure the content sent to the browser does not include > stuff that violates the defined CSP, and thus greatly reduces the risk > of malicious content that input filtering missed from reaching the end user. > > Furthermore, when it does catch a violation, it reports the violating to > a log file notifying me of the problem. > > The only way that works for content generated client side would be if > the user was running a browser that is CSP aware, and right now, they > just don't exist. Firefox has an experimental add-on for CSP but > virtually no one uses it. > > Doing dynamic content server side allows me to run that content through > the enforcement filter server side thus catching policy violating > content before it is ever sent to the user. > > That itself, btw, is probably the biggest stress on the server. > > I understand prototype etc. is the "web 2.0" way but I really don't have > a high opinion of "Web 2.0". JavaScript, flash, etc. all have been used > far too often to do bad things. > > Right now, if I don't block except for white listed web sites, I end up > with advertisements I don't care about expanding and covering the > content I do care about. Unfortunately the web is full of jerks who do > rude things with scripts, and people who do malicious things with scripts. > > You wouldn't execute code that someone you don't know sent you an > e-mail, would you? I wouldn't, nor do I execute code someone I don't > know embeds in a web page. > > I surf with script blockers (NoScript to be specific) and when I come > upon web sites that don't properly function, I'm a lot liklier to head > elsewhere than to enable scripting for that site. Since I surf that way, > I expect others do as well, doing things server side that can be done > server side allows users like me who block scripting to access the > content without compromising the security of our systems. > It's for users like you that I keep saying to people that Javascript shouldn't define functionality but enhance it. People will turn their noses up at that attitude, but, like you said, some people get downright nasty with the things they do online with their scripts. I've not used that CSP thing you linked to before, it looks like it's not for validating user input going *to* your server, but to sanitise the downstream content from your server to the users browser. Validating user input should prevent this as best as possible, as it shouldn't lead to output from your script being used as part of an XSS attack. However, the real worry is with ISP's that modify your pages before they are output to the browser, as Canadian ISP Rogers has been found doing: http://www.mattcutts.com/blog/confirmed-isp-modifies-google-home-page/ No PHP class will be able to prevent that, as the ISP is modifying the content en route to its destination. Thanks, Ash http://www.ashleysheridan.co.uk
