Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #26526 > unrolled thread

Removing scripts

Back to article view | Back to comp.lang.javascript

Contents

  Removing scripts Tim Streater <timstreater@greenbee.net> - 2015-01-10 18:43 +0000
    Re: Removing scripts Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-10 22:32 +0100
    Re: Removing scripts Richard Damon <Richard@Damon-Family.org> - 2015-01-10 22:07 -0500
      Re: Removing scripts Tim Streater <timstreater@greenbee.net> - 2015-01-11 09:16 +0000
    Re: Removing scripts "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-11 12:56 +0100
      Re: Removing scripts Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-01-11 14:23 +0100
        Re: Removing scripts "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-11 14:47 +0100
      Re: Removing scripts Tim Streater <timstreater@greenbee.net> - 2015-01-11 15:08 +0000

#26526 — Removing scripts

I have some untrusted HTML, so I want to de-activate any <scripts> it
contains before shoving it into an iframe. Is there any reason not to
do the following?

newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
scripts = newdoc.querySelectorAll ('script');
num     = scripts.length;

for  (i=0;  i<num;  i++)
     {
     newdoc.removeChild (scripts[i]);
     }

iframePtr.open ();
iframePtr.write (new XMLSerializer().serializeToString (newdoc));
iframePtr.close ();


Of course it's a bit heavy to have the string parsed once so I can
reliably remove script elements, only to then have to serialise it so
that I can write it into the iframe (where it gets parsed again). But
it seems that once written into the iframe, the browser starts doing
speculative downloading in parallel with the rest of my javascript
thread execution - making it too late to prevent the remote end from
being aware that I have received their HTML.

-- 
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [next] | [standalone]

#26527

Tim Streater wrote:

> I have some untrusted HTML, so I want to de-activate any <scripts> it
> contains before shoving it into an iframe. Is there any reason not to
> do the following?
> 
> newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
> scripts = newdoc.querySelectorAll ('script');
> num     = scripts.length;
> 
> for  (i=0;  i<num;  i++)
>      {
>      newdoc.removeChild (scripts[i]);
>      }
> 
> iframePtr.open ();
> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
> iframePtr.close ();

Yes.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#26528

On 1/10/15 1:43 PM, Tim Streater wrote:
> I have some untrusted HTML, so I want to de-activate any <scripts> it
> contains before shoving it into an iframe. Is there any reason not to
> do the following?
>
> newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
> scripts = newdoc.querySelectorAll ('script');
> num     = scripts.length;
>
> for  (i=0;  i<num;  i++)
>      {
>      newdoc.removeChild (scripts[i]);
>      }
>
> iframePtr.open ();
> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
> iframePtr.close ();
>
>
> Of course it's a bit heavy to have the string parsed once so I can
> reliably remove script elements, only to then have to serialise it so
> that I can write it into the iframe (where it gets parsed again). But
> it seems that once written into the iframe, the browser starts doing
> speculative downloading in parallel with the rest of my javascript
> thread execution - making it too late to prevent the remote end from
> being aware that I have received their HTML.
>

When dealing with "untrusted" data, it is MUCH better to parse it and 
allow what you need to and is safe, rather than trying to think about 
all the bad things that could be and block them.

[toc] | [prev] | [next] | [standalone]

#26535

In article <hOlsw.607583$5U6.318062@fx01.iad>, Richard Damon
<Richard@Damon-Family.org> wrote:

>On 1/10/15 1:43 PM, Tim Streater wrote:
>> I have some untrusted HTML, so I want to de-activate any <scripts> it
>> contains before shoving it into an iframe. Is there any reason not to
>> do the following?
>>
>> newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
>> scripts = newdoc.querySelectorAll ('script');
>> num     = scripts.length;
>>
>> for  (i=0;  i<num;  i++)
>>      {
>>      newdoc.removeChild (scripts[i]);
>>      }
>>
>> iframePtr.open ();
>> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
>> iframePtr.close ();
>>
>> Of course it's a bit heavy to have the string parsed once so I can
>> reliably remove script elements, only to then have to serialise it so
>> that I can write it into the iframe (where it gets parsed again). But
>> it seems that once written into the iframe, the browser starts doing
>> speculative downloading in parallel with the rest of my javascript
>> thread execution - making it too late to prevent the remote end from
>> being aware that I have received their HTML.
>>
>
>When dealing with "untrusted" data, it is MUCH better to parse it and 
>allow what you need to and is safe, rather than trying to think about 
>all the bad things that could be and block them.

I'm letting the browser parse it; it will do a much better and more
complete job than I can.

-- 
"Please stop telling us what you feel. Please stop telling us what your 
intuition is. Your intuitive feelings are of no interest whatsoever, 
and nor are mine. I don't give a bugger what you feel, or what I feel. 
I want to know what the evidence shows."             -- Richard Dawkins

[toc] | [prev] | [next] | [standalone]

#26540

Tim Streater wrote:

> I have some untrusted HTML, so I want to de-activate any <scripts> it
> contains before shoving it into an iframe. Is there any reason not to
> do the following?
> 
> newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
> scripts = newdoc.querySelectorAll ('script');
> num     = scripts.length;
> 
> for  (i=0;  i<num;  i++)
>     {
>     newdoc.removeChild (scripts[i]);
>     }
> 
> iframePtr.open ();
> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
> iframePtr.close ();

Have you considered event handler attributes?  Have you considered to
set an appropriate sandbox attribute[1] on the iframe, instead.

[1] <http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-sandbox>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#26541

Christoph M. Becker wrote:

> Tim Streater wrote:
>> I have some untrusted HTML, so I want to de-activate any <scripts> it
>> contains before shoving it into an iframe. Is there any reason not to
>> do the following?
>> […]
>> iframePtr.open ();
>> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
>> iframePtr.close ();
> 
> Have you considered event handler attributes?

Pardon?

> Have you considered to set an appropriate sandbox attribute[1] on the 
> iframe, instead.
> 
> [1]
> [<http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-sandbox>

Interesting, but equally unreliable on the Web.

In general, filtering needs to be done server-side, and ISTM that the above 
is client-side code because of “iframePtr.open()” (whereas actually 
“iframePtr” is no pointer variable at all).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#26542

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> Tim Streater wrote:
>>> I have some untrusted HTML, so I want to de-activate any <scripts> it
>>> contains before shoving it into an iframe. Is there any reason not to
>>> do the following?
>>> […]
>>> iframePtr.open ();
>>> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
>>> iframePtr.close ();
>>
>> Have you considered event handler attributes?
> 
> Pardon?

The given script[1] only caters for script elements.  One reason not to
use it would be that event handlers on elements could contain malicious
script code, which would pass this "clean up".

> In general, filtering needs to be done server-side,

ACK.  However, a black listing approach is likely to be insufficient anyway.

[1] <news:100120151843135093%timstreater@greenbee.net>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#26544

In article <m8todg$hvs$1@solani.org>, Christoph M. Becker
<cmbecker69@arcor.de> wrote:

>Tim Streater wrote:
>
>> I have some untrusted HTML, so I want to de-activate any <scripts> it
>> contains before shoving it into an iframe. Is there any reason not to
>> do the following?
>> 
>> newdoc  = new DOMParser().parseFromString (untrustedHTML, 'text/html');
>> scripts = newdoc.querySelectorAll ('script');
>> num     = scripts.length;
>> 
>> for  (i=0;  i<num;  i++)
>>     {
>>     newdoc.removeChild (scripts[i]);
>>     }
>> 
>> iframePtr.open ();
>> iframePtr.write (new XMLSerializer().serializeToString (newdoc));
>> iframePtr.close ();
>
>Have you considered event handler attributes?

These are still a problem, even doing the above.

>Have you considered to
>set an appropriate sandbox attribute[1] on the iframe, instead.

Yes, I did that and then gave up. The reason is that I want to set two
event handlers on the iframe (drop and dragover), to prevent someone
dropping something on it. But with the iframe sandboxed, such event
handlers won't run.

-- 
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web