hta security with adodb.stream
Reto Ravasio
machines.
pc1 (W2K-sp3, ADO 2.8, IE6 sp1) I get the following:
'this page is accessing information that is not under its control. This
poses a security risk. Do you want to continue?'
pressing yes results in:
'Safety settings on this computer prohibit accessing a data source in
another domain'
pressing no gives:
'permission denied'
pc2 (W2K-sp3,ADO 2.6, IE5.5 sp1)
works perfectly
pc3 (W2K-sp3,ADO 2.6, IE5.5 sp1)
'This page is accessing a data source on another domain. Do you want to
allow this ?'
pressing yes: works
pressing no results in:
'safety settings on this computer prohibit accessing a data source on
another domain
do you want to continue running scripts on this page?'
pc4&5: (XP Professional & Home latest stuff&patches installed)
works perfectly:
I think that pc1 & pc3 are acting differently because of the different ado
versions. what absolutely confuses me is that some pc's popup typical ie
warning messages. I always thought that MSHTA has a different security
implementation.
Can anyone explain this behavior or has anyone else encountered a similar
problems?
reto
Note:
- all the w2k pc's have 'access data sources across domains' for the local
computer enabled.
- the script is running from a local harddisk.
- there are some variations in installed patches (i'm still checking on
that)
********* httpget.hta *********
<html>
<head>
<script language="javascript">
function HTTPGet() {
var xhtm = new ActiveXObject("Microsoft.XMLHTTP");
xhtm.Open("GET",idSource.value,0);
xhtm.Send();
var shtml = new ActiveXObject("ADODB.Stream");
shtml.Mode = 3;
shtml.Type = 1;
shtml.Open();
shtml.Write(xhtm.responseBody);
shtml.SaveToFile(idDest.value,2);
}
</script>
</head>
<body>
<table>
<tr>
<td>input:</td>
<td><input id='idSource' type="text"
value="http://www.microsoft.com" style="width:200px"></td>
<tr>
<tr>
<td>output:</td>
<td><input id='idDest' type="text" value="C:\temp\test.txt"
style="width:200px"></td>
<tr>
<table>
<button onclick='HTTPGet()'>http Get</button>
</body>
</html>
***********
Torgeir Bakken (MVP)
> (snip)
> I think that pc1 & pc3 are acting differently because of the different ado
> versions. what absolutely confuses me is that some pc's popup typical ie
> warning messages. I always thought that MSHTA has a different security
> implementation.
> Can anyone explain this behavior or has anyone else encountered a similar
> problems?
>
>
> Note:
> - all the w2k pc's have 'access data sources across domains' for the local
> computer enabled.
> - the script is running from a local harddisk.
> - there are some variations in installed patches (i'm still checking on
> that)
Hi
Most likely the computers that doesn't work have KB870669 installed.
You can "remove" the effect of this fix with a simple registry edit,
see the "Important Notes" section (at the end) here for more on this:
How to disable the ADODB.Stream object from Internet Explorer
http://support.microsoft.com/default.aspx?kbid=870669
--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/community/scriptcenter/default.mspx
Reto Ravasio
"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:uNmsa3OZ...@TK2MSFTNGP12.phx.gbl...
> Reto Ravasio wrote:
>
> > (snip)
> > I think that pc1 & pc3 are acting differently because of the different
ado
> > versions. what absolutely confuses me is that some pc's popup typical ie
> > warning messages. I always thought that MSHTA has a different security
> > implementation.
> > Can anyone explain this behavior or has anyone else encountered a
similar
> > problems?
> >
> >
> > Note:
> > - all the w2k pc's have 'access data sources across domains' for the
local
> > computer enabled.
> > - the script is running from a local harddisk.
> > - there are some variations in installed patches (i'm still checking on
> > that)
> Hi
>
> Most likely the computers that doesn't work have KB870669 installed.
>
> You can "remove" the effect of this fix with a simple registry edit,
> see the "Important Notes" section (at the end) here for more on this:
>
> How to disable the ADODB.Stream object from Internet Explorer
> http://support.microsoft.com/default.aspx?kbid=870669
I have my doubts that 870669 is the culprit. The first reason beeing that
870669 is installed on 1 machine that is not running and on two machines
that are ok. The second reason is that the article above states:
"However, the ADODB.Stream object can still access your hard disk outside
Internet Explorer."
As I understand this: MSHTA is not Internet Explorer.
I verified your tip on pc1 but the behavior is still the same :-(
I still don't get it. Why is an HTA (which is supposed to behave like any
other exe securitywise) behaving like a normal web-page?
reto
Torgeir Bakken (MVP)
> thanks for your quick answer
>
> I have my doubts that 870669 is the culprit. The first reason beeing that
> 870669 is installed on 1 machine that is not running and on two machines
> that are ok. The second reason is that the article above states:
> "However, the ADODB.Stream object can still access your hard disk outside
> Internet Explorer."
> As I understand this: MSHTA is not Internet Explorer.
>
> I verified your tip on pc1 but the behavior is still the same :-(
>
> I still don't get it. Why is an HTA (which is supposed to behave like any
> other exe securitywise) behaving like a normal web-page?
Hi
You are correct, 870669 will not have any influence on a HTA.
I have tried your script on three different PC configurations,
and I am not able to reproduce your problem...
Torgeir Bakken (MVP)
> Reto Ravasio wrote:
>
>> thanks for your quick answer
>>
>> I have my doubts that 870669 is the culprit. The first reason beeing that
>> 870669 is installed on 1 machine that is not running and on two machines
>> that are ok. The second reason is that the article above states:
>> "However, the ADODB.Stream object can still access your hard disk outside
>> Internet Explorer."
>> As I understand this: MSHTA is not Internet Explorer.
>>
>> I verified your tip on pc1 but the behavior is still the same :-(
>>
>> I still don't get it. Why is an HTA (which is supposed to behave like any
>> other exe securitywise) behaving like a normal web-page?
>
> Hi
>
> You are correct, 870669 will not have any influence on a HTA.
>
> I have tried your script on three different PC configurations,
> and I am not able to reproduce your problem...
unless I run the hta file from a network location, then I get:
'this page is accessing information that is not under its control.
This poses a security risk. Do you want to continue?'
I know you noted that you ran the script from a local harddisk, I
just wanted to verify with you that this was really the case for
all your test scenarios?
Reto Ravasio
> Torgeir Bakken (MVP) wrote:
>
> > Reto Ravasio wrote:
> >
> >> thanks for your quick answer
> >>
> >> I have my doubts that 870669 is the culprit. The first reason beeing
that
> >> 870669 is installed on 1 machine that is not running and on two
machines
> >> that are ok. The second reason is that the article above states:
> >> "However, the ADODB.Stream object can still access your hard disk
outside
> >> Internet Explorer."
> >> As I understand this: MSHTA is not Internet Explorer.
> >>
> >> I verified your tip on pc1 but the behavior is still the same :-(
> >>
> >> I still don't get it. Why is an HTA (which is supposed to behave like
any
> >> other exe securitywise) behaving like a normal web-page?
> >
> > Hi
> >
> > You are correct, 870669 will not have any influence on a HTA.
> >
> > I have tried your script on three different PC configurations,
> > and I am not able to reproduce your problem...
>
> unless I run the hta file from a network location, then I get:
>
> 'this page is accessing information that is not under its control.
> This poses a security risk. Do you want to continue?'
on pc1:
'Error: Safety settings on this computer prohibit accessing a data source on
another domain.'
on pc3:
works perfectly :-o
---- seems that the local zone is more restrictive then the intranet
zone ----
I think I've seen your error on an xp box but I can't verify that at the
moment.
btw:
on what type of pc have you run the script?
Torgeir Bakken (MVP)
> btw:
> on what type of pc have you run the script?
Win2k SP2 with IE5.5 SP2
Win2k SP4 with IE6 SP1
WinXP SP2 (beta RC2) with IE6 SP2
Reto Ravasio
news:OCDmuoOZ...@tk2msftngp13.phx.gbl...
pc2:
Q295688, Q828026, Q828026, dx819696
pc3:
Q811493, wm828026, KB819696, KB810217, KB810217, Q811493, KB819696,
KB839643
all of these patches have nothing obvious to do with zone handling and/or
data access.
Reto Ravasio
> Reto Ravasio wrote:
>
> > btw:
> > on what type of pc have you run the script?
>
> Win2k SP2 with IE5.5 SP2
> Win2k SP4 with IE6 SP1
> WinXP SP2 (beta RC2) with IE6 SP2
with 2k-sp3 :-(
reto
name
Ms writes about "transport" protocols
that is the "t" in http and https.
---------------------------------------------------
But you can also 'trust' a site via file protocol
e.g. for a share
file://computername/folderDescriptionAliasfile
-----------------
I pointed my Win2003EnterpriseEval to a Win98 share
where trusted = file:// (see above)
Which does it.
-----------------------
This is preliminary. I want feeback on implications of
web site's ability to put a link on a page which could
call a standalone computer's share.
Should not be allowed to get there or even execute.
Higher level code appreciated.
(Password... don't know.)
============
Choke point is
if(this.protocol=="file:") {
this.xmlHttps = ok?arguments[0].xmlHttps():false
this.xmlHttp = ok?arguments[0].xmlHttp():false
}
where ok is window
===========
Can't say that will help.
=============
the are two pictures a http://web.tampabay.rr.com/leiblein/images/
1 and 2.
=======
Sorry, I am not Ms and not likely to wast more time on this.
"Reto Ravasio" <re...@nospam.com> wrote in message
news:uiHSuuQ...@TK2MSFTNGP09.phx.gbl...