Bug 298934 (sa15489)

Replace "[Javascript Application]" in content-originating sheets with something more useful (SA15489)

RESOLVED FIXED

Status

()

Core
Security
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: Simon Fraser, Assigned: dveditz)

Tracking

(Depends on: 1 bug, {fixed-aviary1.0.5, fixed1.7.9})

Trunk
fixed-aviary1.0.5, fixed1.7.9
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.9 +
blocking-aviary1.0.5 +
blocking1.8b3 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix], URL)

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
For security and usability reasons, we should replace the text "[Javascript
Application]" in sheets that are raised from content with something that shows
the URL of the requesting page, perhaps with the page title and/or favicon.

It should be clear that this request is content-generated, not
browser-generated. Perhaps the sheet should have a distinctive look?
(Reporter)

Comment 1

12 years ago
This is actually a core bug. "[Javascript Application]" comes from gecko as the
window title, and fixing this will involve API changes.
Assignee: sfraser_bugs → dveditz
Component: General → Security
Product: Camino → Core
Version: unspecified → Trunk
all / all.

This should prolly block 1.0.5 as there's discussion on the lists about it.
Flags: blocking-aviary1.0.5?
OS: MacOS X → All
Hardware: Macintosh → All
(Assignee)

Comment 3

12 years ago
I don't know if this will actually block, but we'd like it fixed.
Flags: blocking1.8b3+
Flags: blocking1.7.9+
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5+
*** Bug 171129 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 5

12 years ago
Created attachment 188014 [details] [diff] [review]
Use host as alert/confirm/prompt title (when known)
Attachment #188014 - Flags: superreview?(jst)
Attachment #188014 - Flags: review?(cbiesinger)
(Assignee)

Comment 6

12 years ago
Created attachment 188015 [details] [diff] [review]
same -w
(Assignee)

Updated

12 years ago
Whiteboard: need reviews
(Reporter)

Comment 7

12 years ago
Two things:
1. I'd much prefer we pass the host string down to the embedder explicitly,
   rather than buried in a "window title" string, so that embedders can do
   smart things with it. This would require changing APIs, I know.

2. Is this really necessary? Can't the code that displays the dialogs get the
   host from the location, using the nsIDOMWindow passed in?
Comment on attachment 188015 [details] [diff] [review]
same -w

hm, I don't get this code. Why are you not just using the host, instead of
first removing user:pass and then using the prePath?

also:
+	       aOutTitle = NS_ConvertUTF8toUTF16(prepath);

should be:
CopyUTF8toUTF16(prepath, aOutTitle);
(Assignee)

Comment 9

12 years ago
I'm pretty sure we're not up for changing API's on the aviary/1.7 branches.
nsIPrompt is one of the most basic frozen interfaces we've got, there might be a
lot of reluctance to change it even on the trunk. I doubt the pain is worth the
gain, but if you can get the embedding folks to agree I've got no problem doing
it that way (on the trunk).

(In reply to comment #7)
> 2. Is this really necessary? Can't the code that displays the dialogs get the
>    host from the location, using the nsIDOMWindow passed in?

Not in the case of javascript: or data: urls. Unless we go to the principal the
location doesn't tell us anything more than today's current "JavaScript
Application". And given that loophole that's  exactly what the next spoofing
demonstration would use.

(In reply to comment #8)
> hm, I don't get this code. Why are you not just using the host, instead of
> first removing user:pass and then using the prePath?

I thought the scheme and port might be good to have: makes it look more like an
address than a title, and in a few rare cases a non-standard port might be good
to know. I also tried putting just the host in [] like the current text; it was
a bit ugly but we could do that as well. If no one thinks the scheme is useful
it's a whole lot easier just getting the host.

> should be:
> CopyUTF8toUTF16(prepath, aOutTitle);

thanks
(Assignee)

Comment 10

12 years ago
Created attachment 188176 [details] [diff] [review]
just the host, not scheme://host[:port]

Is this better?
Attachment #188176 - Flags: superreview?(jst)
Attachment #188176 - Flags: review?(cbiesinger)
Comment on attachment 188014 [details] [diff] [review]
Use host as alert/confirm/prompt title (when known)

oh, I forgot that prePath includes the scheme. may be better to include it,
then.

When fixup is unavailable, should you maybe fallback to using the url
unmodified?

r=me with or without that, plus the CopyUTF8toUTF16 change.
Attachment #188014 - Flags: review?(cbiesinger) → review+
Comment on attachment 188176 [details] [diff] [review]
just the host, not scheme://host[:port]

(but if you want to go with this instead, feel free. r=biesi)
Attachment #188176 - Flags: review?(cbiesinger) → review+
Comment on attachment 188014 [details] [diff] [review]
Use host as alert/confirm/prompt title (when known)

sr=jst
Attachment #188014 - Flags: superreview?(jst) → superreview+
Comment on attachment 188176 [details] [diff] [review]
just the host, not scheme://host[:port]

The first patch in this bug (the one I just sr+'ed) I'm ok with, but this
version pretty much gives any spoofing site full control over the dialog title,
with the exception of being limited to the characters  that are valid in host
names. If we do this, we'd need to have some code to truncate long URLs to
prevent sites from fully controlling the dialig title... Maybe we need to
change our code so that our dialog code assumes everything before the first
space is a hostname and does the truncation based on the width of the dialog
etc, or a whole new API...?
Attachment #188176 - Flags: superreview?(jst) → superreview-

Updated

12 years ago
Whiteboard: need reviews → ready for landing

Comment 15

12 years ago
Comment on attachment 188014 [details] [diff] [review]
Use host as alert/confirm/prompt title (when known)

a=jay for the branches and trunk
Attachment #188014 - Flags: approval1.8b3+
Attachment #188014 - Flags: approval1.7.9+
Attachment #188014 - Flags: approval-aviary1.0.5+

Comment 16

12 years ago
Comment on attachment 188014 [details] [diff] [review]
Use host as alert/confirm/prompt title (when known)

a=jay for the branches and trunk
Attachment #188014 - Flags: approval1.8b3+
Attachment #188014 - Flags: approval1.7.9+
Attachment #188014 - Flags: approval-aviary1.0.5+
Created attachment 188403 [details] [diff] [review]
Trunk version of the first patch.
(Assignee)

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed-aviary1.0.5, fixed1.7.9
Resolution: --- → FIXED
(In reply to comment #14)
> If we do this, we'd need to have some code to truncate long URLs to
> prevent sites from fully controlling the dialig title...

Hm, but, don't both patches here have that problem?
(Assignee)

Updated

12 years ago
(In reply to comment #18)
> (In reply to comment #14)
> > If we do this, we'd need to have some code to truncate long URLs to
> > prevent sites from fully controlling the dialig title...
> 
> Hm, but, don't both patches here have that problem?

The first one much less so than the second one. With the first patch, the user
would at least see "http://...", whereas with the second one the user would just
see the beginning of the domain name the attacker site uses w/o any good way to
know that they're seeing the domain name.
(Assignee)

Updated

12 years ago
Whiteboard: ready for landing → [sg:fix]
(Assignee)

Updated

12 years ago
Summary: Replace "[Javascript Application]" in content-originating sheets with something more useful → Replace "[Javascript Application]" in content-originating sheets with something more useful (SA15489)

Comment 20

12 years ago
This is new MFSA2005-54 advisory;
http://www.mozilla.org/security/announce/mfsa2005-54.html now.

Comment 21

12 years ago
There is instructions written in June at my webpages
http://www.networksecurity.fi/#topic29 handling this issue in major and many
other browsers. Btw: this covers almost all browsers, from IE-based only Maxthon
(MyIE2)is immune. We were first who has fix now =)
"- Move the JavaScript dialog box from covering the original URL address at
location bar. [and that little extra window without content]
- When typing sensitive information to a Web site password-type dialog boxes, be
sure that this site is a legitimate site.
NOTE: Using multiple domain suffixes may indicate a spoofing attempt.
- In Mozilla-based browsers: Those dialog boxes mentioned are titled as
[JavaScript Application] (Javascript-sovelma in Finnish etc.)."
This advice is now available because many users has localized 1.0.4 while
waiting their own-language 1.0.6.

Comment 22

12 years ago
For some reason text

Replace "[Javascript Application]" in content-originating sheets with something
more useful (SA15489)

was in QA Contact: field which prevent updating (comment). Please someone with
rights enough add this again to this entry.

Comment 23

12 years ago
Could someone confirm whether this actually is, or should be fixed in Mozilla
1.7.10, 1.7.11, & 1.7.12RC.

Cause if so, & if I'm understanding the secunia report correctly, it does not
seem to be?

"Secunia"
http://forums.mozillazine.org/viewtopic.php?p=1753319

Updated

12 years ago
Blocks: 301873

Updated

12 years ago
No longer blocks: 301873

Updated

11 years ago
Flags: testcase+

Comment 24

11 years ago
See bug 301069 for the Mac version of this bug.

See bug 334893 for more discussion of the UI.
(Assignee)

Updated

11 years ago
Blocks: 301069

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?

Updated

10 years ago
Depends on: 386486
You need to log in before you can comment on or make changes to this bug.