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<script>  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.