Closed Bug 130149 Opened 23 years ago Closed 23 years ago

Composer reveals login and password on publish in html-source

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: mz, Assigned: Brade)

References

Details

(Keywords: privacy, Whiteboard: verify DUPES after this is fixed)

Attachments

(1 file)

patch to address username/pw in urls, returning status to listener, and partially address absolutizing of links in Composer
(deleted), patch
adamlock
: review+
kinmoz
: superreview+
asa
: approval+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020311 BuildID: 2002031108 When publishing a local document with local images embedded composer changes the url and includes the login and password. i.e. <img src="file:///home/foo/bar.gif" alt="gif"> is on publish changed into <img src="ftp://login:pass@www.foo.com/img/bar.gif"> It's also happening on the 0.9.9. Reproducible: Always Steps to Reproduce: 1. rm -rf ~/.mozilla (remove old prefs etc.) 2. rm -rf ~/mozilla/ (remove old moz -- just to make clear what I'm doing) 3. untar mozilla (I'm using tar.gz) 4. start and create new account --- after that standard "stuff" it now gets important: 5. open new blank page to edit 6. write "hello world" 7. insert image -> "chose file" (from your local harddisk) 7a. don't activate "URL is relative to page location" 8. click on tab "<HTML> Source: this shows <img src="file:///..... (just to check) 9. File - Publish As... Site Name: foo Publishing URL: ftp:www.foo.com User name: foo Password: *** Filename: foo.html Include Images and other files (that's already activated) Use this subdirectory: /img/ (that's the important thing) --> click "publish" Actual Results: The <img src> tag is changed from <img src="file:///home/foo/bar.gif" alt="gif"> into <img src="ftp://login:pass@www.foo.com/img/bar.gif"> hmmm... looks like an invitation ;-) Expected Results: Okay: definitly not revealing any passwords... ;-) More seriously: <img src> tags should be adjusted to point to the image location as specified in the dialog. btw: there is another bug as the dialog cuts off the leading slash when invoked next time.
OK, I reproduced this. To repro, you need to enter teh password in the publish dialog (so that pw manager isn't called) Note that if you strip out the username/pw, then the result won't be correct (because the option to use relative urls isn't selected) and you end up with src="ftp://some.host/some/dir/relative/to/the/uploaders/home/dir"). If you upload images to img/, though, it makes sense to make them relative. I'm not sure what should happen, but inclusing the username/pw shouldn't. The easy fiux for this is to clone the url, SetUserPass(""), and then GetSpec that url. -> brade, who owns this stuff IIRC
Assignee: syd → brade
Severity: blocker → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1
CC'ing security meister
I think this is a duplicate of another bug on my plate... BBaetz is correct about Setting UserPass to "" before getting the spec. cc adamlock since he will need to review
Target Milestone: --- → mozilla1.0
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Comment on attachment 73696 [details] [diff] [review] patch to address username/pw in urls, returning status to listener, and partially address absolutizing of links in Composer Need to make sure this patch doesn't break save to disk, but otherwise r=adamlock. There is also a possibility that someone may have deliberately put user/pass links in their code and we should avoid stripping them out if possible. That's a lesser problem compared to this though.
Attachment #73696 - Flags: review+
Comment on attachment 73696 [details] [diff] [review] patch to address username/pw in urls, returning status to listener, and partially address absolutizing of links in Composer sr=kin@netscape.com
Attachment #73696 - Flags: superreview+
Is this the same as bug 127759. Or is there something different about this one?
*** Bug 127759 has been marked as a duplicate of this bug. ***
Whiteboard: verify DUPS after this is fixed
Comment on attachment 73696 [details] [diff] [review] patch to address username/pw in urls, returning status to listener, and partially address absolutizing of links in Composer a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73696 - Flags: approval+
fix checked into 1.0 trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
The original problem seems fixed, but it stirred up another: If the images are published into a subdirectory, Composer tries to publish them anonymously. But since my server does not allow anonymous upload, it won't let me. I filed a new bug on this: bug 131218 But when I check the source, the password is not there, so I guess I can Verify this one.
Status: RESOLVED → VERIFIED
Adding adt1.0.1 because folks are obviously not seeing the nsbeta1 nomination.
Keywords: adt1.0.1, privacy
Blocks: 143047
Keywords: nsbeta1 → nsbeta1+
Whiteboard: verify DUPS after this is fixed → [adt1 RTM] verify DUPES after this is fixed [ETA 06/21]
Target Milestone: mozilla1.0 → mozilla1.0.1
my bad. removing adt grafitti as the fix was checked to the trunk in before we branched for 1.0.
Keywords: adt1.0.1
Whiteboard: [adt1 RTM] verify DUPES after this is fixed [ETA 06/21] → verify DUPES after this is fixed
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: