encoded URL is not shown / invisible in mail status line



MailNews Core
14 years ago
6 years ago


(Reporter: Markus Merz, Unassigned)



Windows 2000
Bug Flags:
blocking1.7 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:nse])



14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040606
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040606

Urlencoded URLs wncoded with the following scheme are not shown in Mail/News
status line (i.e. m%E4dchen inside of variables). For encoding I use the
following table. Normally I use it to do some deep linking into a database.

# encode URL
* Tabelle (s.u.): http://ffm.junetz.de/members/reeg/DSP/node13.html
* RFC: http://www.ietf.org/rfc/rfc2396.txt

Table 8.1: urlencoded
Zeichen Code 	Zeichen	Code 	Zeichen	Code
" " 	+ 	/ 	%2F 	{ 	%7B
! 	%21 	: 	%3A 	| 	%7C
  	%22 	; 	%3B 	} 	%7D
# 	%23 	< 	%3C 	~ 	%7E
$ 	%24 	= 	%3D 	ä 	%E4
% 	%25 	> 	%3E 	ö 	%F6
& 	%26 	? 	%3F 	ü 	%FC
' 	%27 	@ 	@ 	Ä 	%C4
( 	%28 	[ 	%5B 	Ö 	%D6
) 	%29 	\ 	%5C 	Ü 	%DC
* 	* 	] 	%5D 	ß 	%DF
+ 	%2B 	^ 	%5E 	--
, 	%2C 	_ 	_ 	--
- 	- 	` 	%60 	--
. 	. 	--

Inside the browser the status line presentation is OK.

Reproducible: Always
Steps to Reproduce:
1. Testcase to create a mail with a visible and an invisible Link in
the status line:

with encoded German Umlaut</a>
status line Link with German Umlaut</a>

The testcase is just to show the invisible link. The invisible link is not
working because google doesn't accept this specific encoding. I just want to
show that it is possible to hide the status line which might be a serious
security issue.
2. Compose a mail and insert the testcase as HTML
3. Send to yourself
4. Move mouse over links and check status line

Actual Results:  
second link from testcase is invisible in status line

Expected Results:  
link must be visible
Confirming: in the browser both URLs show a-umlaut in the status bar, in mail
the second one has a blank status bar. How does the browser know one is a UTF8
encoding and the other is Latin-1?

The UTF8 to UTF16 converter will return a blank string when fed invalid UTF8,
and E4 by itself is invalid UTF8 (E4 is the start byte of a three byte sequence,
but the next two bytes are not in the valid x80 - xBF range). My WAG here is
that mail is feeding the statusbar text through a UTF8 to UTF16 converter.

However URLs are not UTF8 encoded, %e4 is the correct URL encoding for ä. the
other sequence would be interpreted on most servers as ä

I don't think this needs to be security sensitive, the worst you can do is blank
the entire status bar at which point the user notices something weird (plus
blanking is easily accomplished in the browser where JS is on by default). This
is in contrast to a recent exploit where an attacker could truncate the status
bar text at an abitrary point leaving a completely false and misleading impression.
Group: security
Ever confirmed: true
Summary: (security) encoded URL is not shown / invisible in status line → encoded URL is not shown / invisible in mail status line
Whiteboard: [sg:nse]
cc mscott, might affect thunderbird too
Component: Security: General → Mail Window Front End

Comment 3

14 years ago
Again confirmed comment 0 in 1.7rc3
For QA 1.7-final I flagged it "1.7?"
Flags: blocking1.7?

Comment 4

14 years ago
   in some ways the only protection for these kind of exploits is going to come
through education of users to check the status bar before clicking on
suspicous/phishy links...  

with this added to the exploit a user sees nothing... 

so the story can be "if you see a bad site, or no site, when you hover over a
link, then don't go there..."

I guess it would just be good to simpilfy the message, since it will be a hard
one for most user to understand anyway, but looks like we are out of time to get
this in 1.7...

Comment 5

14 years ago
nsITextToSubURI::unEscapeURIForUI should be used to convert a URL fragment into
a user presentable string.  the charset parameter should usually be the value of


14 years ago
Flags: blocking1.7? → blocking1.7-

Comment 6

14 years ago
(In reply to comment #3)
> Again confirmed comment 0 in 1.7rc3
And again for 1.7.2
> For QA 1.7-final I flagged it "1.7?"
I don't flag it again. Maybe it will be solved, maybe not.
Product: Browser → Seamonkey


13 years ago
Assignee: sspitzer → mail


10 years ago
Assignee: mail → nobody
Component: MailNews: Message Display → Backend
Product: SeaMonkey → MailNews Core
QA Contact: backend
You need to log in before you can comment on or make changes to this bug.