Printable View
If Internet Explorer is used on the hard disk, there's an IE-prompt when we do things like<a onclick="location.href='some_file.html'">load some file</a>, <a onclick="top.location.href='some_file.html'">some file</a>etc., whereas there's no prompt when we do<a href="some_file.html" target="_self">some file</a>, <a href="some_file.html" target="_top">some file</a>etc.
Isn't that strange? Why shouldtarget=...be safer than(...).location.href?
===
Arie Molendijk
I think it's the href that it is being trusted over the onclick, not the target.
In its default configuration, all local javascript is suspect. I forget the exact settings, but this may be changed in the security advanced section.
Generally if you're just testing to see what's what before going live, you can just ignore the warning, click OK and proceed.
There's a real danger though in IE that a local javascript could access the hard drive. Only certain types can, but IE draws no distinction when issuing this warning.
So if you don't trust the code, don't click OK. But if you know it's just an ordinary javascript for a menu or images, don't worry about it.
The safest (and most representative) thing to do when testing in IE is to do so on a local server like xamp or wamp. Or you can use a virtual machine (accessing the files of the main machine, which then acts as a server of sorts). Doing it any of those ways, if you do get a warning, you should take it more seriously.
This holds true for certain situations with AJAX, frames and iframes in Mozilla (like Firefox, others) and WebKit (like Safari and Chrome, and others). With them it's different. If resource pages are in different folders on a local machine, these browsers might in the situations noted see it as a cross domain security violation and refuse to load/fetch/access the page. The cure is the same - use some sort of server.
This is why I always test on a live server, along with other reasons for doing that.
But I agree that IE is annoying about JS in that way.
Yes! And that's why I posted my question. Once we know that href is trusted over onclick, we could use that knowledge for malicious purposes. Or am I wrong there?Quote:
Originally Posted by bluewalrus
===
Arie.
I don't see how. Only the Javascript can be malicious (unless you happen to link to a malicious page, but that should, in theory, have it's own security restrictions). So if you have just href and target, then you can't do anything malicious. Once you add the JS in any way you'll get the warning, so you can't get around it that way either. I don't believe that adding a target or adding an href would disable the JS warning if you do have JS. Right?
The point is that you're looking about examples that have HTML and JS equivalents. Let's assume there is a JS function malicious(). Whatever it may be, there is no HTML equivalent, so that doesn't present any sort of security risk. There's no <malicious> tag for example.
The problem with IE is that it doesn't recognize that location.href is NOT malicious in JS (it just assumes all JS is malicious). So it's overprotective, not any sort of loophole.
Yes, you're right.Quote:
Originally Posted by djr33
You're right again. IE sees location.href as JS, but it accepts href as non-JS, although they are ment to do the same thing.Quote:
Originally Posted by djr33
===
Arie.
It's the javascript. IE doesn't differentiate. All local javascript is suspect to it. If you do:
Then the moment you click on it, even though it does little of note and nothing as regards security, you get a warning.HTML Code:<a href="javascript:void(0);">Whatever</a>
Something else to consider though. Once you approve a tab, you can load any ordinary javascript into it without warning. And again this is only for local pages.
That's just how it is. No rhyme or reason other than the fact that some local javascript can be dangerous, and IE doesn't differentiate as to which is and as to which is not dangerous.