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.

Reply via email to