IE blocking active content

K

kaeli

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

I see no difference between IE6 and Firefox 1.0 on my system.

The problem is somewhere in your IE settings, not your script.

--
--
~kaeli~
Kill one man and you are a murderer. Kill millions and you
are a conqueror. Kill everyone and you are God.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
 
G

Grant Wagner

Emmett said:
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.
 
G

Grant Wagner

Emmett said:
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.
 
M

Michael Winter

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
 
R

Richard Cornford

Michael Winter wrote:
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\\Windows\\"+
"CurrentVersion\\Internet Settings\\Zones\\0\\DisplayName");

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

Richard.
 
G

Grant Wagner

Michael said:
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.
 
R

Robert

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
 
Y

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\CurrentVersion\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\CurrentVersion\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
 
R

Randy Webb

Yarek said:
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.
 
R

Randy Webb

Andrew said:
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.
 
A

Andrew Poulos

Yarek said:
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
 
F

Fred Oz

Andrew said:
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.
 
T

Thomas 'PointedEars' Lahn

Andrew said:
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,...)

JavaScript, or more precisely regarding IE, Microsoft JScript, is indeed
sandboxed and does not pose a potential threat in and of itself. But it
can be used as an interface language to host objects, including ActiveX
objects and those include objects to access file systems. Note that native
ActiveX support is not restricted to IE, Netscape 4+ for Windows includes
it as well.
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.

Not only ActiveX, the whole security concept of IE for Windows and of
Windows itself is flawed and compared to the one of Unix and Unix-based
systems, for example, ridiculous; including, but not restricted to,
Windows 9x/Me where every application runs with administrator privileges.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,014
Latest member
BiancaFix3

Latest Threads

Top