Closed
Bug 155760
Opened 22 years ago
Closed 22 years ago
Changing content by JavaScript document.write => open insecure lock icon
Categories
(Core Graveyard :: Security: UI, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: juarez_jc, Assigned: KaiE)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
|
(deleted),
patch
|
javi
:
review+
peterv
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
BuildID: 2002053012
In a secure site (https) the lock indicating a secure conection changes from
closed to opened whem a iframe contente is changed by a javascript function.
In NS4.X and IE the lock continues closed.
Reproducible: Always
Steps to Reproduce:
1. Save the code in a httpS site:
<script>
var branco='<body></body>';
function Menu()
{
wMenu.document.open();
wMenu.document.write("<body>Menu</body>");
wMenu.document.close();
}
</script>
<body>
<a href='javascript:Menu();'>Menu</a>
<iframe name=wMenu src='javascript:top.branco;'
style='position:absolute;top:100px;left:100px;height:200px;width:200px;'></iframe>
</body>
2.Click the "Menu" link
Actual Results: The https lock indicator will change from closed to opened.
Expected Results: No change in the lock.
The same happens in the Mac 2002052917 build.
|
||
Comment 1•22 years ago
|
||
-> PSM
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 1.01
|
||
Comment 2•22 years ago
|
||
Marking works for me. Reporter, can you try today's build?
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
|
|
||
Comment 3•22 years ago
|
||
Reopening. Load the above URL and click on the Menu link. I get the mixed
content warning, and the lock icon is red, unnecessarily.
Status: RESOLVED → UNCONFIRMED
Priority: -- → P3
Resolution: WORKSFORME → ---
Version: 1.01 → 2.3
|
Assignee | |
Comment 4•22 years ago
|
||
Mitch, what is your opinion on this bug? Should we show a good lock icon,
whatever modifications a page is doing using JavaScript?
|
||
Comment 5•22 years ago
|
||
Tough question. If the page uses javascript to modify itself, then no insecure
content has been introduced...unless the javascript brings in data from an
insecure page, which it could do in some cases. If we want to be really safe,
the lock should open when javascript modifies the page. Otherwise we'll have to
make sure that no insecure content can be introduced.
|
|
Assignee | |
Comment 6•22 years ago
|
||
I agree. As long as we don't have a way to monitor every attempt by JavaScript
to load information over the network, I vote to leave the current behaviour as is.
I suggest to mark as wontfix.
Or, if you think we should start the effort: Please open a new RFE bug,
requesting the lock icon tracking code should be able to monitor any requests
and make decisions about the safety of the obtained information, and make this
bug depend on it.
|
Reporter | |
Comment 7•22 years ago
|
||
You dont have to monitor a javascript to verify if insecure
content is introduced. Think this way:
Today a javascript can change the href of a frame to a new page inside a
https site with no alert. This new page CAN have a insecure content and
no alert will be given.
Now, what is the diference if this insecure content is writen by a javascript
if this javascript came from the same https site? No diference.
Another thing to consider. Why should Mozilla be different of NS4.X, IE and
Opera ? No one of then give an alert if a javascript change the contente of
a FRAME or IFRAME.
|
|
Assignee | |
Comment 8•22 years ago
|
||
> Today a javascript can change the href of a frame to a new page inside a
> https site with no alert. This new page CAN have a insecure content and
> no alert will be given.
Are you sure? How would that be done? You might have in mind an older version of
Mozilla, but I believe the current version will detect the change.
Have a look at:
https://www.kuix.de/misc/test33/
Load the page, accept the site's cert, and after the page loaded, wait 5
seconds. The right frame will go to another page. You'll see a "mixed security"
warning, because some contents of the page are now no longer secure.
Do you know how to do that without a warning?
IE switches the security mode to insecure with my test case, too, (when you
decide to display insecure content), so we seem to agree here.
> Why should Mozilla be different of NS4.X, IE and
> Opera ? No one of then give an alert if a javascript change the contente of
> a FRAME or IFRAME.
NS 4.x did not support IFRAME at all, so we can't test your test case.
NS 4.x did support frames, and when I test with my test case, it DOES inform the
user that it is navigating to an insecure page, and the lock icon changes to
insecure.
I tested with Opera 6.02 on Linux with JavaScript enabled. Surprisingly, when I
connect to your page, it immediately shows on open lock icon, so it does not
like your page at all. (It shows a secure lock icon if I go to your home page on
the same server, so the certificate is recognized ok.)
I confirm that IE does continue to show a secure lock icon after you click the
menu link. But I wonder if that's a bug. We should probably test how IE behaves,
when you change your page to load data from a http URL and show information from
that URL in the iframe.
|
|
Reporter | |
Comment 9•22 years ago
|
||
In the https://www.kuix.de/misc/test33/ right frame You make it navigate to
a HTTP page outside the HTTPS main page. That is the reason of the
alert. IE shows an alert too. Make it navigate to a HTTPS site and You will
see no alert. Like here:
https://ww4.banrisul.com.br/bbm/menuA.htm.
With mozilla 1.1 build 2002071608 for WinNT or Mozilla 1.0 2002052917
for Mac OS9 or IE 4.0/5.0/5.5/6.0 for windows or IE 5 for Mac or NS4.7 for
win95 or NS4.7 for Mac OS9 or NS4.7 for Linux the lock is always closed.
Now with Opera 5.12 for NT I see the lock closed on the load, aferter
clicking in the Menu link the lock opens. What is right Mozilla or Opera?
Returning to the https://ww4.banrisul.com.br/bbm/menu.htm
You may say that IE has a bug or that it is out of the standards and NS4.7
is an old version, but the question is:
If with Mozilla 1.1 I can make a frame navigate to other page INSIDE the
HTTPS site of the main page without alert, why should I have an alert
when a javascript change the contente of a frame? Every thing came from
the same HTTPS site.
And it seens to me that there is nothing that I could do with a javascript
changing the contente of the second frame that I could NOT do puting the
code inside the new page of the second frame. Is there? Could You
give-me a sample? Of course if I make the second frame navigate to
outside the original site I should have an alert.
|
|
Assignee | |
Comment 10•22 years ago
|
||
> In the https://www.kuix.de/misc/test33/ right frame You make it navigate to
> a HTTP page outside the HTTPS main page. That is the reason of the
> alert. IE shows an alert too. Make it navigate to a HTTPS site and You will
> see no alert. Like here:
>
> https://ww4.banrisul.com.br/bbm/menuA.htm.
Yes. It was my intention to set up a test page, that shows what happens, when
you navigate from https to http in that frame.
> With mozilla 1.1 build 2002071608 for WinNT or Mozilla 1.0 2002052917
> for Mac OS9 or IE 4.0/5.0/5.5/6.0 for windows or IE 5 for Mac or NS4.7 for
> win95 or NS4.7 for Mac OS9 or NS4.7 for Linux the lock is always closed.
We agree here. If all content is loaded directly from the web site, and
everything is secure, the lock will stay closed.
> Now with Opera 5.12 for NT I see the lock closed on the load, aferter
> clicking in the Menu link the lock opens. What is right Mozilla or Opera?
I think you are refering to https://ww4.banrisul.com.br/bbm/menuA.htm . I can
reproduce what you describe with Opera 6.02 on Linux. Your page does not use a
direct link, but uses JavaScript to load a new URL in the right frame.
Mozilla detects the new content comes from the server and that https was used to
load it. It decides that everything is still secure and keeps the lock closed.
So I'd say, Mozilla is smart here.
Opera seems to be more restrictive with your page. The Opera programmers seem to
have decided that they switch to insecure, whenever JavaScript is used to change
the contents of the page. Even though all that is done here is to load a new
page. I'd personally say it is not required to open the lock in this situation,
because "what you seen on screen" is still something that came from the server
over https. I can't judge whether Opera's behaviour here is a bug or a wanted
behaviour.
> Returning to the https://ww4.banrisul.com.br/bbm/menu.htm
>
> You may say that IE has a bug or that it is out of the standards and NS4.7
> is an old version, but the question is:
>
> If with Mozilla 1.1 I can make a frame navigate to other page INSIDE the
> HTTPS site of the main page without alert, why should I have an alert
> when a javascript change the contente of a frame? Every thing came from
> the same HTTPS site.
A: Always load https from a server
B: Use JavaScript to dynamically modify the displayed information.
You say, if A is always locked then B should be always locked, too, because the
logic for B came from the server.
The JavaScript can use "simple" logic, that only uses content from the server to
modify the page. Your example is such a case.
But the JavaScript can also use complex logic, where the new displayed content
did not come from the original server.
Examples:
- prompt the user to enter something, display that string in the frame.
- query properties of the browser and display it.
- generate and display a random number.
- use LiveConnect (or similar) to fetch data from a running applet or plugin.
- access data loaded in a separate non-secure window.
It would be wrong if the lock icon stayed secure, if the shown content did not
originate from a trusted secure server.
In theory, we could have very smart logic, that properly detects, whether the
JavaScript is good or bad, i.e. whether it displays only data coming from a
trusted server, or whether it also displays other data. The lock icon could
depend on that.
But we don't have that logic implemented, it would be probably be very complex.
Therefore we currently assume the worst case and switch to insecure whenever
JavaScript modifies the page.
> And it seens to me that there is nothing that I could do with a javascript
> changing the contente of the second frame that I could NOT do puting the
> code inside the new page of the second frame. Is there? Could You
> give-me a sample?
The fact that you can produce the same content using both approaches does not
matter, in my opinion.
Of course, you can have JS in the left frame, to show "hello" in the right
frame, and alternatively, you can instead load a frame into the right window,
that is a document on the server which shows the word "hello".
The point is: If you do it with JavaScript, we can not guarantee the shown
content is from a secure server. The shown content could have been produced
using alternative ways, see the previous section.
While all shown content might indeed be what the server wanted to show, there is
the risk that some shown content has not been transfered from the server in a
secure way. And because we can not guarantee that everything shown was
transfered securely from the server, we play safe and open the lock.
> Of course if I make the second frame navigate to
> outside the original site I should have an alert.
Actually, we are not restrictive to the original site here, because sometimes
sites also load portions of the shown page from multiple machines having
different host names. We check is that everything comes from trusted secure
servers, which might be different servers.
|
|
Assignee | |
Updated•22 years ago
|
Summary: Wrong httpS lock indicator whem a iframe content is changed by a javascript. → Changing iframe content by JavaScript => open insecure lock icon
|
|
Reporter | |
Comment 12•22 years ago
|
||
.....
In theory, we could have very smart logic, that properly detects, whether
the
JavaScript is good or bad, i.e. whether it displays only data coming from a
trusted server, or whether it also displays other data. The lock icon could
depend on that.
But we don't have that logic implemented, it would be probably be very
complex.
.....
NS4.X Have this logic? I now, old code, just asking.
|
|
Assignee | |
Comment 13•22 years ago
|
||
The testcases so far are not applicable for 4.x, because 4.x does not support
IFRAMEs.
In order to create a testcase, that can be used with both 4.x and Mozilla, we
have to use usual frames.
I created yet another testcase at: https://www.kuix.de/misc/test33/fr/
It does what your testcase does, just with a left-right frameset instead.
And indeed, 4.x keeps the lock closed.
>> But we don't have that logic implemented, it would be probably be very
>> complex.
>NS4.X Have this logic? I now, old code, just asking.
I'd guess this kind of modification was simply not handled in 4.x.
While it is a pity that 4.x behaves differently from Mozilla, I personally would
like to keep the new logic in Mozilla and open the lock.
I tested other browsers out of curiousity. Opera opens the lock and behaves as
secure as Mozilla. IE keeps the lock closed in secure more...
|
|
Reporter | |
Comment 14•22 years ago
|
||
OK, Now a real world question.
I manage a Home Banking system that user HTTPS. It is working fine for
more than 4 years for IE and NS4.X. And it uses FRAMES/IFRAMES.
If You want it is possible to test it at https://ww4.banrisul.com.br/bto (just
portuguese, sorry).
In the first screen type 0030 for “Agencia”, 3500000506 for “Conta” and
000000 for “Senha”. Click “Validar”.
After the login You will see a menu at the left. Click the “Extrato” option.
You will see a secure alert. Click OK in the message box and click
“Extrato” again, and then in the “Conta Corrente” option.
In the next screen click the “Do Mes” option.
You will receive all the movements for the acount in the current month.
Now click in the filters “Conta”, “Poupanca”, “Cheques” ... You will note
that the movements are been filtered in the client side. To do this we use
FRAMES/IFRAMES.
In many other points we make a FRAME change the content of the another
one.
Of course the clients using Mozilla1.0 or NS7 do not like the secure alert.
We could make a solution for then without FRAMES, but they will loose
many features and will not like.
What should be my answer to then?
A - Complain to www.mozilla.org
B - Use NS4.X
C - Change to IE
|
|
Assignee | |
Comment 15•22 years ago
|
||
Well. I don't have more arguments. In the end you are right, we should be more
clever, but unfortunately, at the moment we are not.
I realized meanwhile that Communicator used a different approach to make the
lock icon decision. It seems to have used a protocol based approach, while
Mozilla makes a content based approach.
You might also be interested in my recent comments to bug 62178.
Right now, I don't have a solution for this bug.
|
|
Assignee | |
Updated•22 years ago
|
Summary: Changing iframe content by JavaScript => open insecure lock icon → Changing content by JavaScript => open insecure lock icon
|
|
Assignee | |
Comment 16•22 years ago
|
||
*** Bug 177330 has been marked as a duplicate of this bug. ***
|
|
||
Updated•22 years ago
|
|
|
Assignee | |
Comment 17•22 years ago
|
||
*** Bug 155173 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 18•22 years ago
|
||
*** Bug 187607 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Updated•22 years ago
|
Summary: Changing content by JavaScript => open insecure lock icon → Changing content by JavaScript document.write => open insecure lock icon
|
|
Assignee | |
Comment 19•22 years ago
|
||
Additional test case at:
https://www.kuix.de/misc/writelnsecure/
|
|
Assignee | |
Comment 20•22 years ago
|
||
Mozilla 1.0 to 1.3 always change the lock icon to insecure when using
document.write() / writeln().
This behaviour is different from Communicator 4.x and broke the security
appearance of some web sites.
We decided that we want to undo this change.
Patch coming up.
Keywords: 4xp
|
|
Assignee | |
Comment 21•22 years ago
|
||
This patch will make the lock icon tracking code ignore any change that is
caused by document.write. It does so by ignoring changes that come over an
nsIWyciwygChannel.
|
|
Assignee | |
Comment 22•22 years ago
|
||
While the patch causes web sites to no longer appear to be broken, there is one
thing that still concerns me, and I don't have a solution now:
- go to https://www.kuix.de/misc/writelnsecure/
confirm the warning about certificate
=> secure lock icon
- click the link
with the patch applied
=> secure lock icon
because we ignore the change of security state
(that's what this bug asks for)
- click the mozilla icon in the upper right corner to go to a different page
=> insecure lock icon
- now click back
You now see the page that was produced in memory by the call to document.write
=> insecure lock icon
(because we again ignore the security state)
(but even if we did not ignore the change, we no longer had security
state to extract, and we'd still show the insecure lock icon)
Is it acceptable that we show a different lock icon for the dynamically created
page, depending on whether you view it the first time, or whether you click back?
I fear you'll say it is not acceptable?
If it is not acceptable, the only idea I have is: Extend the object that
implements nsIWyciwyg implementation object to carry security state information,
and make our code set/read that information.
Status: NEW → ASSIGNED
|
||
Comment 23•22 years ago
|
||
I've been tracking this bug because it shows up when logged into my banking site
(www.southtrust.com). However, I'm now not sure that what I see is the same as
everyone else in this bug. I see a yellow padlock with a red line diagonally
through it -- not an open icon. I don't ever get a "mixed security" warning,
although that may be because I told Moz not to bother warning me about that. Do
I need to be tracking a different bug (or reporting it)?
FWIW, I'm running Moz 1.2.1 on Windows 95 (fast, cheap, out of control)
Thank god y'all are working in this now! Woohoo!
|
||
Updated•22 years ago
|
Attachment #119462 -
Flags: superreview+
|
|
Assignee | |
Comment 24•22 years ago
|
||
I have a good argument to go with the current patch, instead of addressing my
concerns from comment 22 when going back: Communicator 4.x behaves the same way
when going back, it does not solve the problem either.
So, the patch fixes the request of this bug, but when going back later, the page
will always be reported as insecure.
|
|
Assignee | |
Comment 25•22 years ago
|
||
Comment on attachment 119462 [details] [diff] [review]
Patch v1
Javi, can you please review?
Attachment #119462 -
Flags: review?
|
|
Assignee | |
Updated•22 years ago
|
Attachment #119462 -
Flags: review? → review?(javi)
|
||
Comment 26•22 years ago
|
||
Comment on attachment 119462 [details] [diff] [review]
Patch v1
r=javi
Attachment #119462 -
Flags: review?(javi) → review+
|
|
Assignee | |
Comment 27•22 years ago
|
||
fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 28•21 years ago
|
||
I would like to ask everybody on this bug, who was unhappy with the previous
behaviour, to test whether this bug is now indeed fixed. Please also try to
test, whether there are regressions or not.
Any feedback greatly appreciated. To help testing, please download the latest
nightly trunk build.
|
|
Reporter | |
Comment 29•21 years ago
|
||
It is OK in Windows 95, but the nightly builds are abending before the splash
screen in Windows 2000.
|
|
Assignee | |
Comment 30•21 years ago
|
||
> the nightly builds are abending before the splash
> screen in Windows 2000
What does "abending" mean?
Do you say the nightly builds don't even start up on your system?
(That would be a different bug, not related to this one.)
|
|
||
Comment 31•21 years ago
|
||
Verified, I found no problems, but to quote Kai "I would like to ask everybody
on this bug, who was unhappy with the previous behaviour, to test whether this
bug is now indeed fixed. Please also try to test, whether there are regressions
or not.
Any feedback greatly appreciated. To help testing, please download the latest
nightly trunk build."
Reopen the bug if you still see a problem.
Status: RESOLVED → VERIFIED
|
||
Comment 32•21 years ago
|
||
Worked great for us as well! Couldn't see any problems, and it resolved all of
our issues.
|
||
Comment 33•21 years ago
|
||
Comment on attachment 119462 [details] [diff] [review]
Patch v1
I want to check this patch into 1.4 branch, because one customer need it.
Attachment #119462 -
Flags: approval1.4?
|
||
Comment 34•21 years ago
|
||
If this landed on the mozilla trunk on 2003-04-19 then it should be in Mozilla
already. Anything that is in the trunk now will be in the branch when it's
created. Am I misunderstanding the request?
|
|
||
Comment 35•21 years ago
|
||
Comment on attachment 119462 [details] [diff] [review]
Patch v1
sorry for my misunderstanding.
it is already there.
Attachment #119462 -
Flags: approval1.4?
|
|
||
Comment 36•21 years ago
|
||
I am still seeing the problem at my banking site (www.southtrust.com). I see a
yellow padlock with a red line diagonally through it -- not an open icon. I
don't ever get a "mixed security" warning. Do I need to be tracking a different
bug (or reporting it)?
I'm running Moz 1.4final on Windows XP.
When I try to get to the login page at www.southtrust.com with Netscape 7.1, it
gives me a page saying my browser is not supported and lists browsers that are.
Ironically enough, it says Netscape 7.01 minimum. There is no Mozilla listed.
Doh, there was a link near the bottom to go the login page anyway. I don't have
an account there, so I could only test with invalid account, but for me the lock
icon showed safe site all the time (again, this with Netscape 7.1 on Win2k).
|
||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•