[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Removing scripts

Tim Streater

1/10/2015 6:43:00 PM

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
7 Answers

Thomas 'PointedEars' Lahn

1/10/2015 9:32:00 PM

0

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.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Richard Damon

1/11/2015 3:08:00 AM

0

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.

Tim Streater

1/11/2015 9:16:00 AM

0

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

Christoph M. Becker

1/11/2015 11:57:00 AM

0

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

--
Christoph M. Becker

Thomas 'PointedEars' Lahn

1/11/2015 1:23:00 PM

0

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

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.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Christoph M. Becker

1/11/2015 1:47:00 PM

0

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

Tim Streater

1/11/2015 3:08:00 PM

0

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