 |
 |
On 12/8/2011 11:19 AM, Robert Sanderson wrote: > If you blindly include whatever you get back directly into the page, > it might include either badly performing, out of date, or potentially > malicious<!cript> tags that subsequently destroy the page. It's the > equivalent of blindly accepting web form input into an SQL query and > then wondering where your tables all disappeared off to. Hmm, i'm not sure it's the _equivalent_, isn't JS (especially JS you wrote) going to only be getting HTML from servers running software you wrote/controlled? Even if a server is just adding HTML to a page (no JS involved), it COULD be subject to an HTML injection attack, if the server is basing the HTML on user input without properly sanitizing it. I don't think the fact that you've split the logic between the server and the JS neccearily changes things. It's essentially just a 'remote procedure call'. The server is STILL responsible for delivering secure HTML -- exactly as it was when there was no JS involved at all, no? Now, granted, it is a more complicated environment when there's JS involved, so there is more chance for a security bug. But I wouldn't say it's the equivalent of blinding accepting web form input etc.... whether JS is involved or not, if the server is generating HTML, it's the server's job to _not_ blinding accept web form input and stick it into HTML. If you have your JS asking _untrusted sources_ (instead of your own server) for HTML, then that might be a different story.