<a href="https://bytes.com/topic/javascript/answers/148334-ie-blocking-active-content">IE blocking active content

Emmett wrote:

I have a simple jacascript that randomizes the background of the top
frame of my webpage http://www.duke.edu/~efn. For some reason, my
Internet Explorer started blocking the background and displaying this
instead: http://www.duke.edu/~efn/pic.jpg. This problem didn't used to
occur, and it doesn't happen on Firefox. Is there some way I can alter
the script of the top frame http://www.duke.edu/~efn/top.html to
prevent this from happening? Thanks. -Emmett

Below is your script, and my comments on it:

<script language="javascript">

Use: <script type="text/javascript">

var bgNum = Math.round(Math.random() * 6);

Use: var bgNum = Math.floor(Math.random() * 6);
<url: http://jibbering.com/faq/#FAQ4_22 />

bgSel = new Array(7);
bgSel[0] = "1.jpg";
bgSel[1] = "2.jpg";
bgSel[2] = "3.jpg";
bgSel[3] = "4.jpg";
bgSel[4] = "5.jpg";
bgSel[5] = "6.jpg";
bgSel[6] = "7.jpg";

Use:
var bgSel = [
"1.jpg",
"2.jpg",
"3.jpg",
"4.jpg",
"5.jpg",
"6.jpg",
"7.jpg"
];

var base = bgSel[bgNum];

Note: You don't really need to assign this to another variable.

</script>

</head>

<script language="javascript">
document.write("<body background='" + base + "'>");
</script>

Note: you've got invalid markup here, because you've got a <script> tag
outside of <head></head> and <body></body>. And if Javascript is disabled,
the page gets no <body> tag at all.

Instead, you should use:

<head>
<style type="text/css">
body { background-image: url(default.jpg); }
</style>
<script type="text/javascript">
var bg = [
"1.jpg", "2.jpg", "3.jpg", "4.jpg",
"5.jpg", "6.jpg", "7.jpg"
];
document.write(
'<style type="text/css">',
'body { background-image: url(',
bg[Math.floor(Math.random() * bg.length)],
'); }',
'<\/style>'
);
</script>
</head>
<body>

Now you can expand the number of images by simply adding more elements to
the array (because we're using bg.length instead of a fixed number).

If the user has CSS disabled or over-ridden, they get no (or their choice
of) background-image.

If they have CSS enabled but JavaScript disabled they get the default
background-image (specified as default.jpg).

If they have CSS enabled and JavaScript enabled they get a random choice
of 1..7.jpg.

In no case do they get invalid markup or a page with no <body> tag.
Tested and working in IE 6.0.2800, Firefox 1.0PR, Netscape 4.78, Opera
6.05, Opera 7.54 and Mozilla 1.7.3.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #3

Emmett wrote:

I have a simple jacascript that randomizes the background of the top
frame of my webpage http://www.duke.edu/~efn. For some reason, my
Internet Explorer started blocking the background and displaying this
instead: http://www.duke.edu/~efn/pic.jpg. This problem didn't used to
occur, and it doesn't happen on Firefox. Is there some way I can alter
the script of the top frame http://www.duke.edu/~efn/top.html to
prevent this from happening? Thanks. -Emmett

And oh yes, Internet Explorer 6.0.2900 (Windows XP Service Pack 2) will
prevent the document.write() from occurring if you load the site locally.
But loaded off a Web server it should work okay.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #4

On Thu, 30 Sep 2004 20:53:31 GMT, Grant Wagner wrote:

...Internet Explorer 6.0.2900 (Windows XP Service Pack 2) will
prevent the document.write() from occurring if you load the site locally.
But loaded off a Web server it should work okay.

What is the logic of that? I would have expected
the opposite, if anything.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

Jul 23 '05 #5

Michael Winter

On Thu, 30 Sep 2004 22:16:40 GMT, Andrew Thompson <Se********@www.invalid>
wrote:

On Thu, 30 Sep 2004 20:53:31 GMT, Grant Wagner wrote:
...Internet Explorer 6.0.2900 (Windows XP Service Pack 2) will
prevent the document.write() from occurring if you load the site
locally.
But loaded off a Web server it should work okay.

What is the logic of that? I would have expected
the opposite, if anything.

I think it's to do with the security zones. IE has four: Internet, Local
Intranet, Trusted Sites, and Restricted Sites. However, local code runs in
none of them. It runs under My Computer. Perhaps because there are no
security settings for that zone, it's more restrictive.

A minor advantage to running a Web server on your machine: no content
blocking.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

Jul 23 '05 #6

On Thu, 30 Sep 2004 22:38:11 GMT, Michael Winter wrote:

A minor advantage to running a Web server on your machine: no content
blocking.

I need one in any case to view my JSP's, and it makes
links and resource URL's easy when you can simply refer
to the '/' root path.

Now if only I could get a static IP, 2+Gig of upload bandwith
per month, and a box/power supply reliable enough to hope to run
24/7, I might consider becoming my own host. ..Not quite yet. ;-)

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

Jul 23 '05 #7

Emmett

Grant Wagner <gw*****@agricoreunited.com> wrote in message news:<41***************@agricoreunited.com>...

Emmett wrote:
I have a simple jacascript that randomizes the background of the top
frame of my webpage http://www.duke.edu/~efn. For some reason, my
Internet Explorer started blocking the background and displaying this
instead: http://www.duke.edu/~efn/pic.jpg. This problem didn't used to
occur, and it doesn't happen on Firefox. Is there some way I can alter
the script of the top frame http://www.duke.edu/~efn/top.html to
prevent this from happening? Thanks. -Emmett

Below is your script, and my comments on it:

-snip-

Wow, great reply. Thanks a lot. I implemented your suggested changes.
-Emmett

Jul 23 '05 #8

Richard Cornford

Michael Winter wrote:
<snip>

I think it's to do with the security zones.
IE has four: Internet,
Local Intranet, Trusted Sites, and Restricted Sites. ...

<snip>

IE actually has 5 zones. Zone zero is the "My Computer"(file:) zone.
See:-

WshShell.RegRead("HKCU\\Software\\\Microsoft\\Wind ows\\"+
"CurrentVersion\\Internet Settings\\Zones\\0\\DisplayName");

But you can only play with it through the registry (or WSH).

Richard.

Jul 23 '05 #9

Michael Winter wrote:

On Thu, 30 Sep 2004 22:16:40 GMT, Andrew Thompson <Se********@www.invalid>
wrote:
On Thu, 30 Sep 2004 20:53:31 GMT, Grant Wagner wrote:
...Internet Explorer 6.0.2900 (Windows XP Service Pack 2) will
prevent the document.write() from occurring if you load the site
locally.
But loaded off a Web server it should work okay.
What is the logic of that? I would have expected
the opposite, if anything.

I think it's to do with the security zones. IE has four: Internet, Local
Intranet, Trusted Sites, and Restricted Sites. However, local code runs in
none of them. It runs under My Computer. Perhaps because there are no
security settings for that zone, it's more restrictive.

Given Richard's correction that there is a fifth unexposed (in the UI) zone,
this is pretty much correct. Allowing document.write() to occur on a page in
the My Computer zone would allow the potentional for malicious code to be
injected in a zone that has little to no security associated with it.

Ultimately, Microsoft should have fixed the underlying issues related to
cross-zone security, but they choose an easier route, and that is to deny the
writing of any dynamic content to a page loaded in the My Computer zone.

This way, if a script or page escapes the current security zone (as many
vulnerabilities have been exploited), it is impossible[1] to make the page
insert a <div> that contains a CLSID (or otherwise inject code) that could be
used to harm your system.

It appears Microsoft has moved the My Computer zone from "implicitly trust
everything" to "implicitly distrust everything", which is a prudent move,
considering how much damage can be done by scripts running in this zone.

[1] obviously this can not be proven. I'm certain there are thousands of
people working away trying to find a way around the barriers Microsoft has put
in place in Windows XP Service Pack 2, and if there is a vulnerability in the
methodology Microsoft has chosen (as there almost certainly is), it will be
located and exploited.
A minor advantage to running a Web server on your machine: no content
blocking.

To me, the extra burden placed on Web developers by requiring them to load the
pages they are developing from a real Web server (something they should
probably have been doing all along anyway) is well worth the trouble if it
cuts down on the amount of worms and trojans which can take advantage of
vulnerabilities in Internet Explorer.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #10

On Fri, 01 Oct 2004 15:22:38 GMT, Grant Wagner wrote:

Michael Winter wrote:
On Thu, 30 Sep 2004 22:16:40 GMT, Andrew Thompson wrote:
On Thu, 30 Sep 2004 20:53:31 GMT, Grant Wagner wrote:

...Internet Explorer 6.0.2900 (Windows XP Service Pack 2) will
prevent the document.write() from occurring if you load the site
locally.
But loaded off a Web server it should work okay.

What is the logic of that? I would have expected
the opposite, if anything.
I think it's to do with the security zones. ..

... this is pretty much correct. Allowing document.write() to occur on a page in
the My Computer zone would allow the potentional for malicious code to be
injected in a zone that has little to no security associated with it.

Thanks for the further information.

Something had been bugging me about this, then it
occured to me that I had intended to use Javascript
fairly intensively for browser based content presentation
coming off *CD*, including some document.write().

It sounds like that would fall under the 'My Computer' zone
and thus be subject to the same restrictions (though I'd
have to check it).

Lack of document.write() will not be a show-stopper,
but it makes some things more tricky and/or more effort.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.lensescapes.com/ Images that escape the mundane

Jul 23 '05 #11

Robert

Andrew Thompson <Se********@www.invalid> wrote in message news:<1n*****************************@40tude.net>. ..

Lack of document.write() will not be a show-stopper,
but it makes some things more tricky and/or more effort.

May be you can use innerHTML. Just put in a div or span and insert the html.

Glad I use Netscape.

Robert

Jul 23 '05 #12

Yarek

New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable. Try this code to slightly lower the
new security level imposed on a local machine scripting (this is a REG
file contents):

REGEDIT
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet
Settings\Lockdown_Zones\0]
"1200"=dword:0
"1400"=dword:0
"1405"=dword:0

It just enables basic functionality of ActiveX and scripting. Of course
it may possibly be dangerous, however we've all lived with it before the
service pack 2.
Notice that anything you'd like to do in Internet Options | Security
dialog box would fail, even if you know an MS secret way to display
settings for 'My Computer' zone (it's
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet
Settings\Zones\0\Flags=dword:0x0047, it worked pretty well before
service pack 2 but now you can forget about it: an icon is displayed,
and you can reset settings, but all the tuning will be ignored).

Yarek

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Jul 23 '05 #13

Yarek wrote:

New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable. Try this code to slightly lower the
new security level imposed on a local machine scripting (this is a REG
file contents):

And how is closing a security hole a "new idiotic MS Safety Strategy"?

I agree, its a pain when testing from local drives, but Apache is free,
a breeze to setup and cures that entire problem. It even makes a
*better* test platform because then you are seeing exactly what the
users will see as far as an HTTP server.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #14

On 24 Oct 2004 23:47:59 GMT, Yarek wrote:

New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable.

I have given some thought to the suppression of document.write()
(IE SP2 - local machine) and realized most things I wanted it for
could be achieved by writing the content as HTML and either
a) showing/hiding elements as appropriate (E.G. expandable menu)
b) altering an existing element to point at new content (E.G. slideshow)
or altering the existing (textual) content of an element.

Are there any situations you can put forward, that simply cannot
be done without document.write()?

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #15

Andrew Thompson wrote:

On 24 Oct 2004 23:47:59 GMT, Yarek wrote:

New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable.

I have given some thought to the suppression of document.write()
(IE SP2 - local machine) and realized most things I wanted it for
could be achieved by writing the content as HTML and either
a) showing/hiding elements as appropriate (E.G. expandable menu)
b) altering an existing element to point at new content (E.G. slideshow)
or altering the existing (textual) content of an element.

Are there any situations you can put forward, that simply cannot
be done without document.write()?

I agree with you about document.write. But, the new security restriction
in IE6 isn't limited to document.write though. Open a blank HTML page
locally, with no script elements. It loads fine (obviously). Then, add
an empty script element:

<script type="text/javascript">
//empty
</script>

And you get the security warning.
The only thing I can figure out (and maybe someone else can answer more
definitively) is that when it encounters the script tag, irregardless of
its contents, it throws the error message up.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #16

On Sun, 24 Oct 2004 20:50:38 -0400, Randy Webb wrote:

Andrew Thompson wrote:
On 24 Oct 2004 23:47:59 GMT, Yarek wrote:
New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable.
I have given some thought to the suppression of document.write()
(IE SP2 - local machine) and realized most things I wanted it for
could be achieved by writing the content as HTML and either
a) showing/hiding elements as appropriate (E.G. expandable menu)
b) altering an existing element to point at new content (E.G. slideshow)
or altering the existing (textual) content of an element.

Are there any situations you can put forward, that simply cannot
be done without document.write()?

I agree with you about document.write. But, the new security restriction
in IE6 isn't limited to document.write though. Open a blank HTML page
locally, with no script elements. It loads fine (obviously). Then, add
an empty script element:

<script type="text/javascript">
//empty
</script>

And you get the security warning.

Wow..

I have a particular interest, want to avoid having to use apache
for JS based projects off CD. Assuming as above, frames based,
do those messages come up for *every* new page opened that has
a script element? What if they are scripts that have already
been referenced (using <script src=..)?
The only thing I can figure out (and maybe someone else can answer more
definitively) is that when it encounters the script tag, irregardless of
its contents, it throws the error message up.

A dialog?

[ I do not want to install SP2 yet, since I doubt you could
reverse it short of reinstalling the OS.. ]

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #17

Yarek

Don't worry, just check my post somewhere about. These three register
keys will free all your JavaScripts even when service pack installed.
And the security level will be at least not worse than it could be
without the pack.

Yarek

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Jul 23 '05 #18

Yarek wrote:

New idiotic MS safety strategy succeeded in making all the javascript
code useless if run on a local machine. Instead of making things safe
they just made it (almost) unusable. Try this code to slightly lower the
new security level imposed on a local machine scripting (this is a REG
file contents):

I understand the potential danger posed by ActiveX controls on Windows
but what danger does JavaScript pose? I thought that JavaScript was
sandboxed (as is Flash, Java,...)

If there is no real threat posed by JavaScript then my guess is that the
new security measures in XP SP2 are to cover the fact that M$'s own
technology ,ActiveX, is flawed.
Andrew Poulos

Jul 23 '05 #19

On 25 Oct 2004 02:47:52 GMT, Yarek wrote:

Don't worry, just check my post somewhere about. These three register
keys will free all your JavaScripts even when service pack installed.
And the security level will be at least not worse than it could be
without the pack.

Unfortunately, that is not a workable solution for an audience
viewing a distributed CD. I do not intend distributing it with
the advice to 'adjust registry keys' if problems are encountered.. :-(

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #20

Fred Oz

Andrew Poulos wrote:

Yarek wrote: [snip] If there is no real threat posed by JavaScript then my guess is that the
new security measures in XP SP2 are to cover the fact that M$'s own
technology ,ActiveX, is flawed.
Andrew Poulos

Very likely. MS calls their implementation of JavaScript "JScript".
They treat all scripting as "ActiveScripting" and do not differentiate
between JavaScript and their own VBscript or JScript, both of which had
security issues (and likely still do).

The solution is much like their "fix" for Word macros - let them all
run, or turn them all off.

Fred.

Jul 23 '05 #21

Yarek

I confirm that just putting "<script></script>" anywhere in an html is
enough to wake up the security when service pack 2 installed. No special
instructions required :-(

If a scripted html MUST be run from a local machine (eg. as a part of a
cd distribution) there's one simple solution: just make an own small
browser, based on the explorer active-x. It's just 5 minutes of a
programming work in VC++ or VB, and new security measures are not
imposed on any other applications but the MSIE itself(tested!).

Yarek

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Jul 23 '05 #22

Yarek wrote:

I confirm that just putting "<script></script>" anywhere in an html is
enough to wake up the security when service pack 2 installed. No special
instructions required :-(
And there is a simple, documented solution to the problem.
If a scripted html MUST be run from a local machine (eg. as a part of a
cd distribution) there's one simple solution: just make an own small
browser, based on the explorer active-x. It's just 5 minutes of a
programming work in VC++ or VB, and new security measures are not
imposed on any other applications but the MSIE itself(tested!).

Or simply include:



in the HTML document.

<url:
http://www.microsoft.com/resources/d.../appendix.mspx
/>
Click "Local Machine Zone Lockdown"
Scroll down to "Feature Impact"

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #23

Yarek wrote:

I confirm that just putting "<script></script>" anywhere in an html is
enough to wake up the security when service pack 2 installed. No special
instructions required :-(
Yup, thats all it takes is a script element.
If a scripted html MUST be run from a local machine (eg. as a part of a
cd distribution) there's one simple solution: just make an own small
browser, based on the explorer active-x. It's just 5 minutes of a
programming work in VC++ or VB, and new security measures are not
imposed on any other applications but the MSIE itself(tested!).

Another solution is the "mark of the web". Search the archives and you
will find it.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #24

Yarek

The  mark of the Web solves
the problem! It's amazing, isn't it?

Well, what is the sense of the Service Pack 2 security extension if it
is so easy to avoid? What's the difficulty with adding this to any
malicious code? Isn't it a vulnerability that annihilates the security
introduced in SP2? Well, so, where do I miss the point?

Yarek
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Jul 23 '05 #25

Yarek wrote:

The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.
Andrew Poulos

Jul 23 '05 #26

On Tue, 26 Oct 2004 13:11:43 -0400, Randy Webb wrote:

(Security warning in local content, IE SP2)

Yup, thats all it takes is a script element. .... Another solution is the "mark of the web". Search the archives and you
will find it.

Cool. Now that my usenet feed is correcting itself,
I see your responses all over the place. :-)

Thanks to both you and Grant, I now feel much more
confident that I can go ahead with my JS/CD based
projects easily.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #27

On Wed, 27 Oct 2004 07:45:18 +1000, Andrew Poulos wrote:

Yarek wrote:
The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.

Even using relative URLs?

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #28

Andrew Thompson wrote:

On Wed, 27 Oct 2004 07:45:18 +1000, Andrew Poulos wrote:

Yarek wrote:
The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.

Even using relative URLs?

Yes, I believe so. Adding the "mark" makes IE think that the html file
is part of the internet zone. Links to local files fail because they are
in a different zone, the local zone.
Andrew Poulos

Jul 23 '05 #29

MikeT

Andrew Poulos <ap*****@hotmail.com> wrote in message news:<41***********************@per-qv1-newsreader-01.iinet.net.au>...

Yarek wrote:
The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.

True. This means that even 'mark of the web' won't solve people
providing html-based presentations on CD that link to PDF and other
content. We do this all the time (in our case with 3D models) and the
XP SP2 change has broken every one of them.

The only solution I've found that works reliably is to package the
whole thing in a .hta file that has a single iframe pointing to the
html content. Not graceful, but this works:

<html>
<head>
<title>CD title</title>
<HTA:APPLICATION ID="cdindex"
BORDER="thick"
INNERBORDER="no"
SCROLL="no"
CAPTION="yes"
SHOWINTASKBAR="yes"
SINGLEINSTANCE="yes"
SYSMENU="yes"
WINDOWSTATE="normal" />
</head>
<body style="margin: 0px;">
<iframe src="cdindex.htm" trusted="yes" width="100%" height="100%"
marginwidth="0" marginheight="0" border="0">
<a href="cdindex.htm">CD content is here</a>
</iframe>
</body>
</html>
The other thing I've noticed is that the active content blocking
didn't trigger when I accessed the content from another local machine
via a UNC path. So that's another 'hole' in Microsoft's solution. It's
a nasty kludge that is biting legitimate content but is trivial to
circumvent for anyone who wants to run malicious activeX on a windows
computer. Yuck.

Jul 23 '05 #30

Jim Ley

On 27 Oct 2004 01:41:21 -0700, ne**@chthonic.f9.co.uk (MikeT) wrote:

Andrew Poulos <ap*****@hotmail.com> wrote in message news:<41***********************@per-qv1-newsreader-01.iinet.net.au>... The other thing I've noticed is that the active content blocking
didn't trigger when I accessed the content from another local machine
via a UNC path. So that's another 'hole' in Microsoft's solution. It's
a nasty kludge that is biting legitimate content but is trivial to
circumvent for anyone who wants to run malicious activeX on a windows
computer.

That's not in the "localzone" but the intranet zone, and never had the
priviliges that MS decided weren't appropriate for the vast majority
of users, since the only thing they were used for was viruses.

Jim.

Jul 23 '05 #31

Yarek wrote:

The  mark of the Web solves
the problem! It's amazing, isn't it?

Well, what is the sense of the Service Pack 2 security extension if it
is so easy to avoid? What's the difficulty with adding this to any
malicious code? Isn't it a vulnerability that annihilates the security
introduced in SP2? Well, so, where do I miss the point?

Yarek

I wondered about this too until I thought about it for a while.

Here's the deal, the Local Computer zone used to be absolutely trusted,
which meant if a malicious Web site author could get code into an HTML file
on the local hard disk, they could pretty much do anything they wanted.

Now the Local Computer zone is considered least trusted. Code in an HTML
file on the local hard disk can't do anything without the user agreeing to
it (although apparently there are some vulnerabilities that allow you to
still execute any code from an HTML file on the local hard disk).

By adding the "mark of the web" (especially url=(0013)about:internet), it
places the HTML document on the local hard disk in the Internet zone, and
all the security policies associated with that zone apply to the local
document. If you load a document with a "mark of the web" locally and look
at the status bar of IE, it will say "Internet".

Now, if a malicious author manages to get an HTML document on the local
disk, one of two things will happen:

1) it will run in the Local Computer zone and be subject to the
restrictions of that zone (the user will have to agree to let code run).
2) the malicious author will put a "mark of the web" on the document, in
which case it will run in the Internet zone, and be subjects to the
restrictions of that zone.

Either way, something like the FSO (FileSystem object) won't be able to be
created and used against the user.

Now, some would argue that placing a local document in the Internet zone
makes it unusable for things like the FSO, and they'd be right. However, if
you're planning on using IE specific things like the FSO, then use an IE
specific solution like an HTA.

On the front page you could have:


<![if !IE 5]>
Content for non-IE browsers.
<![endif]>

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #32

Andrew Poulos wrote:

Yarek wrote:
The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.

Perhaps some content, but included external JavaScript seems to have no such
problems. I just did a test here:

test.htm--
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>Untitled</title>
<script type="text/javascript" src="test.js"></script>
</head>

<body>

</body>
</html>
test.js--
document.write('Hello, world!');

Loaded into IE 6.0.2900 (Windows XP Service Pack 2), it seems to work.
-htm\test.htm- and -js\test.js- with <script type="text/javascript"
src="../js/test.js"></script> also works fine. Can you provide a small
working example that demonstrates that the mark of the web on an HTML page
fails to allow external JavaScript to execute properly?
As for links to other HTML content, simply include the mark of the web on
those as well.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #33

MikeT wrote:

The other thing I've noticed is that the active content blocking
didn't trigger when I accessed the content from another local machine
via a UNC path. So that's another 'hole' in Microsoft's solution. It's
a nasty kludge that is biting legitimate content but is trivial to
circumvent for anyone who wants to run malicious activeX on a windows
computer. Yuck.

For a malicious author to use the mechanism you discovered, they would:

1) have to know all the names of computers on the network
2) have to know the names of shares that allow writing on those computers

The point of locking down the Local Computer zone is to prevent a malicious author from dumping HTML content to
c:\hackersRus.html and getting the user to visit it. Local content on a UNC share would be almost completely inaccessible to a
malicious author. He or she would need access to an ActiveX component to enumerate UNC paths available on the local machine so
they could save their code there to be executed, which is a bit of a Catch-22. They'd need malicious code to inject their
malicious code.

I agree locking down the Local Computer zone isn't perfect, but it should certainly help slow the wildfire spread of viruses
and trojans, and that, as Martha Stewart would say, is a good thing. If you want to do snazzy stuff, use an HTA and have your
main HTML document look something like:


<![if !IE 5]>
Content for non-IE browsers.
<![endif]>

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #34

On Thu, 28 Oct 2004 14:32:55 GMT, Grant Wagner wrote:

Now, if a malicious author manages to get an HTML document on the local
disk, one of two things will happen:

1) it will run in the Local Computer zone and be subject to the
restrictions of that zone (the user will have to agree to let code run).
2) the malicious author will put a "mark of the web" on the document, in
which case it will run in the Internet zone, and be subjects to the
restrictions of that zone.

Either way, something like the FSO (FileSystem object) won't be able to be
created and used against the user.

Now, some would argue that placing a local document in the Internet zone
makes it unusable for things like the FSO, and they'd be right. However, if
you're planning on using IE specific things like the FSO, then use an IE
specific solution like an HTA.

That (finally) makes sense to me.

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane

Jul 23 '05 #35

Grant Wagner wrote:

Andrew Poulos wrote:

Yarek wrote:
The  mark of the Web solves
the problem! It's amazing, isn't it?

I think you guys are missing the point! While it does seem that you can
just add a "mark" to get a page to work, if the page has any links to
other files (whether they be CSS, JS, HTML...) then those links will
still fail.

Perhaps some content, but included external JavaScript seems to have no such
problems. I just did a test here:

test.htm--
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<title>Untitled</title>
<script type="text/javascript" src="test.js"></script>
</head>

<body>

</body>
</html>
test.js--
document.write('Hello, world!');

Loaded into IE 6.0.2900 (Windows XP Service Pack 2), it seems to work.
-htm\test.htm- and -js\test.js- with <script type="text/javascript"
src="../js/test.js"></script> also works fine. Can you provide a small
working example that demonstrates that the mark of the web on an HTML page
fails to allow external JavaScript to execute properly?
As for links to other HTML content, simply include the mark of the web on
those as well.

Thanks for that. In my testing it didn't seem to work at all. I'll go
over what I've done and see if there's something obvious I did wrong.

One thing that still concerns me is your comment that begins "Perhaps
some content". This means to me that I won't know anything for sure
until I check. For example, whether linking to CSS and JS in the same
page fails, whether linking to multiple JS in the same pages fails...
Andrew Poulos

Jul 23 '05 #36