New vulnerability?
Evan Platt
Took me a while to figure out what I was missing:
The link is http://www.amazоn.com - the site 'says' amazon.com,
i.e.
fake site: <a href="http://www.amazоn.com">www.amazon.com</a>
Opera 7.6 7364b 'fails' - it takes me to the site and even in the
window shows the site as Amazon.com
i.e. doesn't - gives a DNS error. Firefox also 'fails' the test and
takes me to what appears to be the real site.
Should Opera fail this test and give me a DNS error like IE?
Evan
Mezev
the link. So, I was safe, right?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Evan Platt
wrote:
>IE gave an DNS Error, but Opera did nothing. It didn't even try to open
>the link. So, I was safe, right?
What version of Opera? It opened for me...
Evan
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
<ev...@TheObvious.espphotography.com> wrote:
>http://www.retrosynth.com/misc/phishing.html
>
>Took me a while to figure out what I was missing:
>
>The link is http://www.amazоn.com - the site 'says' amazon.com,
>i.e.
>
>fake site: <a href="http://www.amazоn.com">www.amazon.com</a>
What Opera connects to is the server www.xn--amazn-mye.com, the IDNA (RFC 3490)
encoding of the above servername.
>Opera 7.6 7364b 'fails' - it takes me to the site and even in the
>window shows the site as Amazon.com
>
>i.e. doesn't - gives a DNS error. Firefox also 'fails' the test and
>takes me to what appears to be the real site.
>
>Should Opera fail this test and give me a DNS error like IE?
Tried IE with this utility installed? http://www.idnnow.com/index.jsp
IE does not have support for IDNA. Something which is irritating a number of
people (Asians and Europeans to mention some) no end.
Opera and Mozilla does not fail, it is working precisely as it should according
to an established Internet Standard.
That some Unicode characters look visually similar to US-ASCII characters is a
known problem but one that cannot be solved by the clients but must be solved by
the IDNA standard itself or the standards the it is based on (such as Unicode or
the nameprep standard), and AFAICT there is currently no limits on the use of
the characters your testcase uses.
This is **NOT** a vulnerability, although one might make the case that the
registrars should put some characters out-of-bounds (which the security
considerations of RFC 3490 says they should). A case may, however, (I am not a
lawyer) possibly be made about Trademark infringement against whoever registered
those domains.
Mezev
--
Paul McGarry
Opera Software A/S) <yn...@opera.com> wrote:
> This is **NOT** a vulnerability, although one might make the case that
Presumably a "vulnerability" is anything that leads an unsuspecting user
to be vulnerable.
While it may be per spec ultimatly Opera is the user agent and is first in
line for looking after the users interests.
Surely there are some options here:
-Showing the expanded name (optionally).
-Alerting the user the first time they encounter such a URL and ask them
if they are likely to visit pages with non-ascii domain names.
-Something else
Someone has to be looking after "us".
> considerations of RFC 3490 says they should). A case may, however, (I am
> not a
> lawyer) possibly be made about Trademark infringement against whoever
> registered
> those domains.
I doubt most phishers are worried too much about that.
--
Paul McGarry
http://paulmcgarry.com/
Matthew Winn
> Presumably a "vulnerability" is anything that leads an unsuspecting user
> to be vulnerable.
>
> While it may be per spec ultimatly Opera is the user agent and is first in
> line for looking after the users interests.
>
> Surely there are some options here:
> -Showing the expanded name (optionally).
> -Alerting the user the first time they encounter such a URL and ask them
> if they are likely to visit pages with non-ascii domain names.
What about the second time? You can't interrupt the user every time.
> -Something else
Perhaps some sort of heuristic. It's not the use of Cyrillic or Greek
letters that's the problem, but the use of those letters in the middle
of a different part of the Unicode range. (The same problem occurs in
the other direction, of course.) Perhaps there could be some sort of
warning if and only if adjacent letters are from different character
blocks. An exclamation mark appearing at the start of the address:
click it for more information?
How about punctuation? Are characters like the one-dot leader (U+2024)
and the division slash (U+2215) valid in domain names?
--
Matthew Winn
[If replying by email remove the "r" from "urk"]
Rijk van Geijtenbeek
> On Tue, 18 Jan 2005 16:11:59 +1100, Paul McGarry
> <paul.m...@gmail.com> wrote:
>> Presumably a "vulnerability" is anything that leads an unsuspecting user
>> to be vulnerable.
>>
>> While it may be per spec ultimatly Opera is the user agent and is first
>> in
>> line for looking after the users interests.
>>
>> Surely there are some options here:
>> -Showing the expanded name (optionally).
>> -Alerting the user the first time they encounter such a URL and ask
>> them
>> if they are likely to visit pages with non-ascii domain names.
>
> What about the second time? You can't interrupt the user every time.
>
>> -Something else
>
> Perhaps some sort of heuristic. It's not the use of Cyrillic or Greek
> letters that's the problem, but the use of those letters in the middle
> of a different part of the Unicode range. (The same problem occurs in
> the other direction, of course.) Perhaps there could be some sort of
> warning if and only if adjacent letters are from different character
> blocks. An exclamation mark appearing at the start of the address:
> click it for more information?
From RFC 3490:
"To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual
indications where a domain name contains multiple scripts. Such
mechanisms can also be used to show when a name contains a mixture of
simplified and traditional Chinese characters, or to distinguish zero
and one from O and l. DNS zone adminstrators may impose restrictions
(subject to the limitations in section 2) that try to minimize
homographs."
Easier said then done...
--
The Web is a procrastination apparatus: | Rijk van Geijtenbeek
It can absorb as much time as | Documentation & QA
is required to ensure that you | Opera Software ASA
won't get any real work done. - J.Nielsen
|http://my.opera.com/Rijk/journal
Paul McGarry
>> Surely there are some options here:
>> -Showing the expanded name (optionally).
>> -Alerting the user the first time they encounter such a URL and ask
>> them
>> if they are likely to visit pages with non-ascii domain names.
>
> What about the second time? You can't interrupt the user every time.
You can if they answer the question with a "no". I expect I'd answer with
a no and would only come across such a page very rarely if at all. They
could be blocked with as much pain as popups are now
If they answer with a yes then you can explain to them that any such URLs
will be shown in a particular fashion in future or something.
> How about punctuation? Are characters like the one-dot leader (U+2024)
> and the division slash (U+2215) valid in domain names?
(Are there unicode characters that look like _other_ unicode characters?
Argh, I'm sure there are headaches after headaches here, but at this stage
surely a partial solution that works for a lot of users is better than
nothing)
Paul
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Steven V. Gunhouse
> 8.00 build 7401.
>
> On Mon, 17 Jan 2005 17:18:38 -0800, Evan Platt
> <ev...@TheObvious.espphotography.com> wrote:
>
>> On Mon, 17 Jan 2005 20:16:09 -0500, Mezev <aga...@mailworks.org>
>> wrote:
>>
>>> IE gave an DNS Error, but Opera did nothing. It didn't even try to open
>>> the link. So, I was safe, right?
>>
>> What version of Opera? It opened for me...
>>
>> Evan
>
Opera 8 won't even try to open a link with an invalid character or format.
Select text with a space in it and choose Go to URL, nothing will happen.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Peter Karlsson
> If they answer with a yes then you can explain to them that any such
> URLs will be shown in a particular fashion in future or something.
The problem is just how to properly detect a confusing URL. The case of
non-latin + latin can be quite simple to detect, but there might be
legitimate uses of these URLs, too.
> (Are there unicode characters that look like _other_ unicode characters?
There are several characters in Unicode that look similar. A number of
them are disallowed from IDNA because they are just separate forms of the
other characters, wheras it in this specific case is the difference
between scripts, the latin letter o looks very much like the Cyrillic
letter о. Enough to be able to fool people that "amazоn.com" really is
"amazon.com".
This is quite similar to the case where people register domains like
"goggle.com" or "micr0soft.com", but potentially a lot more confusing.
--
\\// Peter Karlsson, software engineer, Opera Software
The opinions expressed are my own, and not those of my employer.
Please reply only by follow-ups in the newsgroup.
Peter Karlsson
> Opera 8 won't even try to open a link with an invalid character or
> format.
You can't copy-paste the URL as posted in the original post in this
thread, since it used the HTML escaping. The links on the web page work,
though.
The first version with partial support for international domains according
to IDNA was 7.20, IIRC.
Matthew Winn
> From RFC 3490:
>
> "To help prevent confusion between characters that are visually
> similar, it is suggested that implementations provide visual
> indications where a domain name contains multiple scripts. Such
> mechanisms can also be used to show when a name contains a mixture of
> simplified and traditional Chinese characters, or to distinguish zero
> and one from O and l. DNS zone adminstrators may impose restrictions
> (subject to the limitations in section 2) that try to minimize
> homographs."
>
> Easier said then done...
I don't think it's all that difficult to deal with multiple scripts.
All you need is a list of the lowest character numbers in each
character block, and give each block in the list a unique number:
0000 : 1
0250 : 2
0370 : 3
0400 : 4
0530 : 5
0590 : 6
0600 : 7
...
Then for each segment of the domain name:
Allocate an array of integers the same size as the segment.
For each character in the segment set the corresponding integer
in the array just allocated as follows:
If the character is a letter scan though the list of
character blocks and set the array element to the
unique number from the table above.
Otherwise set the array element to zero.
If there are any adjacent, different, non-zero values in the
array, warn the user.
It's not a particularly fast algorithm, but as it's only used when
the domain name in the address bar changes it doesn't need to be fast.
Peter Karlsson
> All you need is a list of the lowest character numbers in each character
> block, and give each block in the list a unique number:
Yes, this simplistic approach works fine until you come to the block of
Han characters, where forms used in traditional Chinese, simplified
Chinese, Japanese and Korean is all mixed together...
> If there are any adjacent, different, non-zero values in the
> array, warn the user.
Unfortunately, this would also warn for a Cyrillic domain name containing
digits, since the same digits are used as for latin text. Same applies for
Greek...
Matthew Winn
> Matthew Winn:
> > All you need is a list of the lowest character numbers in each character
> > block, and give each block in the list a unique number:
>
> Yes, this simplistic approach works fine until you come to the block of
> Han characters, where forms used in traditional Chinese, simplified
> Chinese, Japanese and Korean is all mixed together...
I'm thinking of an algorithm that will work for most situations, not
for every possible case. It's a starting point, not finished code.
If you have a situation where block 1 is used in language A, block 2
is used in languages A and B, and block 3 is used in language B, then
you have no choice but to add a special case to the code to check that
blocks 1 and 3 are not used together while allowing blocks 1 and 2 or
blocks 2 and 3 to be combined. There's no way to avoid that, but if
you can deal with most cases generically the number of special cases
you have to deal with is small.
> > If there are any adjacent, different, non-zero values in the
> > array, warn the user.
>
> Unfortunately, this would also warn for a Cyrillic domain name containing
> digits, since the same digits are used as for latin text. Same applies for
> Greek...
That's why I said "letters", not "letters and digits". The point is
to catch places where someone drops a fake letter into the middle of
a word, not to complain every time more than one character block is
used.
Besides, it's just a warning: "This domain has mixed character blocks,
so if it doesn't look as though it needs mixed character blocks you
should take care." It might be annoying if it's occasionally
overenthusiastic, but it's not fatal.
Steven V. Gunhouse
> Steven V. Gunhouse:
>
>> Opera 8 won't even try to open a link with an invalid character or
>> format.
>
> You can't copy-paste the URL as posted in the original post in this
> thread, since it used the HTML escaping. The links on the web page work,
> though.
>
> The first version with partial support for international domains
> according to IDNA was 7.20, IIRC.
>
I didn't copy-paste, I just tried clicking it in the email. It was
highlighted like a URL, but didn't go anywhere. Should Opera handle that
differently?
Brian L Johnson
To clarify:
What the OP intended was for people to go to the webpage:
http://www.retrosynth.com/misc/phishing.html
and then try clicking on the various links on that page.
--
blj
Steven V. Gunhouse
Strangely enough, there is a minor difference in the fonts. When I
actually hover back and forth between the links, I can see a small
difference in the letter o's (or the y in paypal). But that's here in the
Linux version, with my font settings.
Still a question of what should have happened with the link in the
message. But maybe he didn't copy it properly - if I actually paste it
here http://www.amazоn.com/ (now that looks really ugly in Linux, the "o"
is the wrong size) ... anyway, if I actually paste it here I don't get
that HTML entity code and hence it might actually work.
Peter Karlsson
> I didn't copy-paste, I just tried clicking it in the email.
The link in the e-mail contained the raw HTML code. &, # and ; are not
allowed in links, so the link isn't clickable. In the linked page, the
HTML is interpreted by a HTML parser before being shown, so there the link
*is* clickable.
> It was highlighted like a URL, but didn't go anywhere.
Yeah, the URL highlighting doesn't validate the link. Perhaps it should.
Peter Karlsson
> Strangely enough, there is a minor difference in the fonts.
Yes, here too. My default font (Bitstream Vera Sans) has slightly
different glyphs for o (latin letter O) and о (Cyrillic letter О). I
didn't compare the y (lattin letter Y) and the у (Cyrillic letter У) very
closely, but if there is any difference in the fonts, it is quite small.
> anyway, if I actually paste it here I don't get that HTML entity code
> and hence it might actually work.
It does indeed.
Brian L Johnson
>> http://www.retrosynth.com/misc/phishing.html
>>
>> and then try clicking on the various links on that page.
>>
>
> Strangely enough, there is a minor difference in the fonts. When I
> actually hover back and forth between the links, I can see a small
> difference in the letter o's (or the y in paypal). But that's here in
> the Linux version, with my font settings.
Might be a Linux thang. Here on XP-H+SP2 with clean install of Opera8
with no font mods, I see no difference at all between the fake and real
links -- either hovered or not, Author mode or User mode.
> Still a question of what should have happened with the link in the
> message. But maybe he didn't copy it properly - if I actually paste it
> here http://www.amazоn.com/ (now that looks really ugly in Linux, the
> "o" is the wrong size) ... anyway, if I actually paste it here I don't
> get that HTML entity code and hence it might actually work.
>
Selecting the entire page, rt-clicking and Copy Text, I get this on the
clipboard:
*----cut here----*
fake site: www.amazon.com
real site: www.amazon.com
fake site: www.microsoft.com
real site: www.microsoft.com
fake site: www.paypal.com
real site: www.paypal.com
<snip>
a = а
e = е
o = о
y = у
*----cut here----*
Just to rule out anything else, if I rt-click one of the links and choose
'Copy Link Address', I get this:
http://www.amazоn.com/
If I paste any of the copys into a hex editor, (instead of this M2 compose
page) I still get exactly the same.
http://www.amazоn.com/
So, for me, the 'deception' is pretty much foolproof: without examining
the source code, I couldn't tell the difference between real and fake
links until I land on the appropriate page.
--
blj
Steven V. Gunhouse
In my status bar in Windows, the Cyrillic "o" is offset lower than the
surrounding Latin text. Ah ... the version of Times New Roman (my toolbar
font) on this system doesn't include Cyrillic, so I'm getting the "o" from
Verdana. (This is a 98 SE system. Presumably a more recent version of
Times New Roman would include Cyrillic ...)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
rja.ca...@excite.com
Paul McGarry wrote:
> On Tue, 18 Jan 2005 02:28:48 +0100, Yngve Nysaeter Pettersen
(Developer,
> Opera Software A/S) <yn...@opera.com> wrote:
>
> > This is **NOT** a vulnerability, although one might make the case
that
>
> Presumably a "vulnerability" is anything that leads an unsuspecting
user
> to be vulnerable.
Never mind Unicode URLs. What about www.amaz0n.com ?
(Okay, it displays as www.ama20n.com, which is going to stand out.)
I think the real message may be... never trust URLs even if they look
good. Don't trust your own ability to detect when you're being
suckered. If people could do that reliably, there would be no such
word as "sucker". So if you get an e-mail (or a Web page) of uncertain
provenance that says "Go to Amazon here", either skip the link and type
Amazon's address yourself, or take the link but don't take out your
wallet.
That isn't to say that there's nothing for Opera to do here. For
instance, an additional level of trust-of-URL indicator could be
provided - say, your bookmarks carry a trust level setting, and when
you visit a site that you bookmarked (even if not through the
bookmark), the trust rating is displayed. Maybe, date of your last
visit. When you visit a phisher, no familiar-site icon. Of course
this involves defining and then detecting other pages that match the
URL, so it isn't simple... Just a suggestion. I'm sure there are
other ways to achieve similar good results.
The other part of the message is - try not to use a Web browser where
your PC can get hacked just because you went to a bad Web site. Opera
scores fairly well there...
Paul McGarry
<rja.ca...@excite.com> wrote:
>> Presumably a "vulnerability" is anything that leads an unsuspecting
> user
>> to be vulnerable.
>
> Never mind Unicode URLs. What about www.amaz0n.com ?
>
> WWW.AMA20N.COM ?
There's an interesting suggestion here:
http://weblogs.mozillazine.org/gerv/archives/007359.html
I'm not sure it's exactly feasible. I can imagine most users being
confused by all the different colours rather than understanding them but a
bit of "out of the square" thinking about the issue isn't a bad thing.
Matthew Winn
> There's an interesting suggestion here:
> http://weblogs.mozillazine.org/gerv/archives/007359.html
>
> I'm not sure it's exactly feasible. I can imagine most users being
> confused by all the different colours rather than understanding them but a
> bit of "out of the square" thinking about the issue isn't a bad thing.
It's an interesting idea, but it won't work.
To start with, there aren't that many colours to choose from. To be
effective such a scheme would have to use colours that are easily
distinguishable from memory, and that reduces the total set of useful
colours to around half a dozen. That makes it a trivial matter for a
phisher to try variations on a domain name until one with the correct
colour appears. If www.amaz0n.com doesn't match try www1.amaz0n.com,
www2.amaz0n.com, and so on.
The other problem is for the user to learn the colours. Anyone who
uses the web extensively may well visit dozens of sites on a regular
basis and remembering the colours for each one would be difficult.
And the sites where it most matters are the ones that people visit
least often. What percentage of pages that you visit are ones where
you're paying for something? For me it's somewhere down below 0.01%.
That's not enough that I'd notice if a site had the wrong colour.
Richard Grevers
<o*@matthewwinn.me.urk> wrote:
>
> The other problem is for the user to learn the colours. Anyone who
> uses the web extensively may well visit dozens of sites on a regular
> basis and remembering the colours for each one would be difficult.
> And the sites where it most matters are the ones that people visit
> least often. What percentage of pages that you visit are ones where
> you're paying for something? For me it's somewhere down below 0.01%.
> That's not enough that I'd notice if a site had the wrong colour.
>
However, colouring the address field background (maybe with a ? link at
the right-hand end of it) would be an obvious but non-intrusive way of
indicating when an URL is using a mix of ascii and internationalized
characters. It has similarly been suggested that the address field
background could be tinted for secure pages.
(maybe green for security, pink if there's a problem with security, orange
for phishing alert).
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
rja.ca...@excite.com
Thanks! I dived in there and refined my bookmarks idea. Optionally
colour code by bookmark folder, so your bank and your porn sites don't
look the same.
It's kind of like the well-known, much-copied Evil Overlord to-do list,
with tips like "don't tell the Hero your master-plan right before you
kill him". What I mean is, there are lieutenants and there are trusted
lieutenants. Even though they all should be on your side, it's
important to keep straight which is which, for instance planning the
guard rota for the Hero's True Love's cell in the dungeon. Actually,
maybe the heaviest guard should be around the cell I asked the trusted
lieutenant to use while we redecorate his quarters... I'm not thinking
about the browser any more, am I? Sorry. ;-)
Nisse Engström
> In my status bar in Windows, the Cyrillic "o" is offset lower than the
> surrounding Latin text. Ah ... the version of Times New Roman (my toolbar
> font) on this system doesn't include Cyrillic, so I'm getting the "o" from
> Verdana. (This is a 98 SE system. Presumably a more recent version of
> Times New Roman would include Cyrillic ...)
I too use Times New Roman on my 98SE box. In my
case, the two links are identical in the status bar
and the links panel. A magnification of the links
panel shows that the spoof is pixel perfect.
I'd *really* like to see a clear indication when
a URL is obfu^Winternationalized, and an option to
see the sens^WASCII version of it.
--n
rja.ca...@excite.com
ASCII is a step backwards in this context, though. It's fine for the
American-speaking user, but the rest of the world needs Unicode - or
better. At least if we're going to include the whole planet... And
Opera comes from... dang... Norway, wasn't it?
We're talking about identity theft: theft of the identity of a bank, or
an online trading site of some other kind, usually. Your URL is your
identity. Well, we need to have something done about that. A lot of
things, probably. Better laws. A culture where identity theft in
either direction is just severely uncool. And, yes, a technological
solution would be good.
Perhaps instead of the browser, we could build a screening technology
into a proxy server. At work we have a proxy server that blocks Web
sites that the company doesn't want us to use. For a while they ran
amuck and systematically blocked search engines, until I guess someone
high up pointed out they couldn't DO THEIR JOB without access to Web
sites. So... how about, on the PC, ... wait, maybe this has been done
anyway. What I have in mind is this - let's see if I get how it works:
a URL is submitted to the proxy server from the browser. (Opera knows
how to do that.) The proxy server fetches the address for the URL,
then fetches the data and passes it on to Opera. So I propose a
behaviour where if the URL doesn't really amtch a site that you visited
before - maybe also if the IP address changes (that will catch DNS
interference, but will also hit when someone really changes your
address) - then the proxy server pauses and sends a popup to say "This
is a new Web site. Do you want to go ahead and visit it?" This can be
done outside the browser, which doesn't need to know that it's
happening.
A basic set of useful functions could include:
- Permit this URL for the duration of this session
- Permit all unfamiliar URLs for the duration of this session
- Permit all unfamiliar URLS except known bad places
- Permit this URL at any time in the future
And what gets permitted can be either the domain name, or the identical
URL as far down as the latest slash in the file name... or can be
presented to the user for editing.
Of course it also means one more place which logs every URL that you
visit, and where you have to erase your history of porn sites - and of
course people will suspect that it's spyware just like Opera itself,
and will refuse to use it. But you know what? We can steal their bank
account details and buy ice cream. So that's okay.
Brian L Johnson
>> Surely there are some options here:
>> -Showing the expanded name (optionally).
>> -Alerting the user the first time they encounter such a URL and ask
>> them if they are likely to visit pages with non-ascii domain names.
>
> What about the second time? You can't interrupt the user every time.
Yes, you can.
I'd like to be asked every time I visit a new site. I'd like the d/log to
be pretty much the same as the Wand one. I'd like to be able to (a)
accept this time only, (b) always accept, (c) reject this time only, (d)
always reject.
--
blj
Matthew Winn
That's great if you live in the US but in many parts of the world
nearly every URL will (eventually) contain non-ASCII characters.
Users would soon get fed up with having to say "Yes, I really want
to access this non-ASCII domain" every single time they go to a new
site.
Brian L Johnson
> On Sun, 23 Jan 2005 21:17:51 -0000, Brian L Johnson
> <no.e...@address.invalid> wrote:
>> Matthew Winn wrote:
>>
>> >> Surely there are some options here:
>> >> -Showing the expanded name (optionally).
>> >> -Alerting the user the first time they encounter such a URL and ask
>> >> them if they are likely to visit pages with non-ascii domain names.
>> >
>> > What about the second time? You can't interrupt the user every time.
>>
>> Yes, you can.
>>
>> I'd like to be asked every time I visit a new site. I'd like the
>> d/log to be pretty much the same as the Wand one. I'd like to be able
>> to(a) accept this time only, (b) always accept, (c) reject this time
>> only, (d) always reject.
>
> That's great if you live in the US but in many parts of the world
> nearly every URL will (eventually) contain non-ASCII characters.
IWC, a separate checkbox saying something like '[_]Never Ask Me Again
About ANY Sites Like This' would seem to be in order.
> Users would soon get fed up with having to say "Yes, I really want
> to access this non-ASCII domain" every single time they go to a new
> site.
Once they've had their bank accounts emptied a couple of times, they'll
either (a) put up with the annoyance of answering a yes/no question or (b)
choose not to visit such sites. <g>
--
blj
Steven V. Gunhouse
<rja.ca...@excite.com> wrote:
Sounds awful complex. How about a paradigm which says that URLs probably
shouldn't mix western and non-western characters? It isn't likely that a
real address would contain only one cyrillic character (as was the case in
those examples), so have a popup from your firewall or proxy that
indicates the address is mixed and hence suspect. (Not that Opera couldn't
do that also, but if someone does add it to their proxy then you'd end up
being asked twice ...)
A place of business may very well restrict you to certain addresses, but
for the home user it is unlikely.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Matthew Winn
> Sounds awful complex. How about a paradigm which says that URLs probably
> shouldn't mix western and non-western characters?
It has to be a mixture of letters (not characters), and it has to be
any mixture of any character blocks (not just western and non-western).
You get the same problem with a mixture of Cyrillic and Greek, for
example: both contain several similar glyphs.
rja.ca...@excite.com
Again, it depends what you mean by "non-western characters". And for
instance, both Russia and China are quite keen on "HARRY-POTTER", and
if they don't spell him out in Western then the Japanese will do, so,
...
> A place of business may very well restrict you to certain addresses,
but
> for the home user it is unlikely.
YMMV, but I'd expect to see that a large percentage of my Internet
access is to a small set of Web sites - my regulars. So if I have to
okay individual exceptions - or just take the training wheels off for
an afternoon - that's satisfactory.
A minute or so with Google didn't turn up anyone doing this in a proxy
server at the moment, but that doesn't make me an expert.
Peter Karlsson
> Once they've had their bank accounts emptied a couple of times, they'll
> either (a) put up with the annoyance of answering a yes/no question or
> (b) choose not to visit such sites. <g>
The problem is that there are perfectly valid domain names that mix ASCII
and non-ASCII characters. For example, showing a warning for
http://www.rödakorset.se/ - The Swedish Red Cross - is not doing anything
for making people think it is a credible warning.
Peter Karlsson
> How about a paradigm which says that URLs probably shouldn't mix western
> and non-western characters?
The problem is defining what is mixing and what is not.
http://www.opẹra.com/ is made up entirely of characters valid in
Vietnamese, still it does look very much like Opera's home domain. Also,
the domain http://www.орега.com/ also looks a lot like Opera's home
domain, but is made up entirely of Cyrillic characters, so no mixing going
on (of course, the "г" doesn't really look like "r", but at a quick glance
it could fool a lot of people).
rja.ca...@excite.com
Peter Karlsson wrote:
> Steven V. Gunhouse:
>
> > How about a paradigm which says that URLs probably shouldn't mix
western
> > and non-western characters?
>
> The problem is defining what is mixing and what is not.
> http://www.opẹra.com/ is made up entirely of characters valid in
> Vietnamese, still it does look very much like Opera's home domain.
Also,
> the domain http://www.орега.com/ also looks a lot like Opera's
home
> domain, but is made up entirely of Cyrillic characters, so no mixing
going
> on (of course, the "г" doesn't really look like "r", but at a quick
glance
> it could fool a lot of people).
I presume this particular example wouldn't work at all if it wasn't in
the real dot-com top-level domain - but am I wrong?
Steven V. Gunhouse
<rja.ca...@excite.com> wrote:
Well ... of course the other top-level domains would have the same issues.
But I presume that you mean they can't use a fake "o" in the "com" part.
The answer there would appear to be yes, however they would translate
"com" with a fake "o" is not likely to be a valid top-level domain.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Brian L Johnson
>> Once they've had their bank accounts emptied a couple of times, they'll
>> either (a) put up with the annoyance of answering a yes/no question or
>> (b) choose not to visit such sites. <g>
>
> The problem is that there are perfectly valid domain names that mix
> ASCII and non-ASCII characters. For example, showing a warning for
> http://www.rödakorset.se/ - The Swedish Red Cross - is not doing
> anything for making people think it is a credible warning.
In the past, other vulnerabilities have allowed true URLs to be masked in
the URL-bar, and the browser manufacturers have subsequently issued
patches to close these security holes.
Are we saying now that because the URL is perfectly valid, it's NOT a
vulnerability?
If we are, then I'd like to cast my vote for a version of Opera *without*
Unicode support please.
--
blj
BattleTroll
> If we are, then I'd like to cast my vote for a version of Opera
> *without* Unicode support please.
>
I guess not very much people outside the USA and the remnants of the
british empire will cast a vote for that... for only the people whose
native language is english use only a tiny fraction of ISO-8859 and don't
have even the slightiest desire to learn something else (neither languages
nor writing systems).
where as 1 thousand 2 hundred chinese, the same amount of indians and some
other millions from the rest of the world who DON'T use even latin
alphabet to write down their languages surely want to be able to see URL's
in their native writing system and not having to write in an alphabet
totally alien to them... and they for sure will cast their vote for
mantaining Opera with unicode support...
Matt
>
>> If we are, then I'd like to cast my vote for a version of Opera
>> *without* Unicode support please.
>>
> I guess not very much people outside the USA and the remnants of the
> british empire will cast a vote for that...
Perhaps better, would be an option so show either the Unicode, or the
ASCII euivalent (with the x--12 or whatever). But this doesn't address the
security issue for non-only-English speakers who use Unicode in the URL,
so we're sidestepping the problem for a few users, and need a better
solution anyway.
--
Matt
Brian L Johnson
>> If we are, then I'd like to cast my vote for a version of Opera
>> *without* Unicode support please.
>>
>
> I guess not very much people outside the USA and the remnants of the
> british empire will cast a vote for that... for only the people whose
> native language is english use only a tiny fraction of ISO-8859 and
> don't have even the slightiest desire to learn something else (neither
> languages nor writing systems).
That's true.
> where as 1 thousand 2 hundred chinese, the same amount of indians and
> some other millions from the rest of the world who DON'T use even latin
> alphabet to write down their languages surely want to be able to see
> URL's in their native writing system and not having to write in an
> alphabet totally alien to them... and they for sure will cast their vote
> for mantaining Opera with unicode support...
Even though the common language of the internet is, at the moment,
English, there's no doubt that each country wants to be able to use its
own writing system. I have no objection to that.
What I DO object to is the fact that a URL can be completely spoofed for
ALL languages and yet Opera Software doesn't see it as a vulnerability.
--
blj
Matthew Winn
> Steven V. Gunhouse:
>
> > How about a paradigm which says that URLs probably shouldn't mix western
> > and non-western characters?
>
> The problem is defining what is mixing and what is not.
That's (moderately) easy. As I said before, you do it by determining
which block each letter of the domain name is in, and then warning the
user if there are adjacent letters from different blocks. Something
like this:
.-------------------------------------------------------------.
| The site you are visiting has a mixture of character blocks |
| in its domain name. This may be used to spoof common sites. |
| [Perhaps insert example using http://www.[o]pera.com here.] |
| This site has letters from the ... and ... blocks. If you |
| can't see any reason why letters from all these blocks are |
| being used then the site may not be genuine. |
`-------------------------------------------------------------'
This won't be 100% reliable, of course. If I decide to set up a site
about the Apollo-Soyuz mission of 1975 then I might register a domain
name that switches from the Western European to the Cyrillic block in
the middle, and any browser following the "adjacent letters from
different blocks" algorithm will raise a warning.
But that's OK. The vulnerability here involves letter glyphs that are
visually similar and no computer will ever be able to handle that with
100% reliability. There's no choice but to ask the user to make the
final decision. If I go to a site and see that warning but I know
the site is about a joint US/Soviet space mission then I won't be
alarmed by the mixture of characters because I can reasonably expect
such a thing. But if I go to amazon.com and get the same warning I'm
certainly not expecting to find Cyrillic characters in the name, so
I'll be aware that there's something dodgy.
> http://www.op?ra.com/ is made up entirely of characters valid in
> Vietnamese, still it does look very much like Opera's home domain. Also,
> the domain http://www.?????.com/ also looks a lot like Opera's home
> domain, but is made up entirely of Cyrillic characters, so no mixing going
> on (of course, the "?" doesn't really look like "r", but at a quick glance
> it could fool a lot of people).
Well boo hoo. You're never going to achieve a perfect recognition of
this vulnerability. Can't be done. Ain't gonna happen. No way, no
how.
But that doesn't mean you shouldn't do the best you can.
Matthew Winn
> >
> > If we are, then I'd like to cast my vote for a version of Opera
> > *without* Unicode support please.
>
> I guess not very much people outside the USA and the remnants of the
> british empire will cast a vote for that... for only the people whose
> native language is english use only a tiny fraction of ISO-8859 and don't
> have even the slightiest desire to learn something else (neither languages
> nor writing systems).
Even in the Empire I wouldn't vote for an ASCII-only browser.
Standard English has many foreign words that retain their accents or
diacriticals, and what happens if I want to visit a site about the
Romanian town of Constanza and the site owner has decided to spell the
name properly in the domain instead of using the corrupted form I've
had to adopt here?
In addition, any solution to this vulnerability should work just as
well for the Russian user who visits a site with an unexpected Greek
omicron in it as it does for US users.
Peter Karlsson
> Are we saying now that because the URL is perfectly valid, it's NOT a
> vulnerability?
No, I'm just pointing out that it is very difficult to tell what is a
valid domain name from what is a "phishy" domain name. In a perfect world,
the domain registrar wouldn't allow people to register this kind of
domain, but I am afraid that is not something we can rely on.
> If we are, then I'd like to cast my vote for a version of Opera
> *without* Unicode support please.
A version entirely without Unicode support will not happen, but it might
not be a bad idea for an option to disable international domains. It
cannot be the only protection, though, because international domains must
be enabled by default and only the small part of the users that never will
use such a domain and know that they want to disable it are protected by
such a setting.
Rijk van Geijtenbeek
> What I DO object to is the fact that a URL can be completely spoofed for
> ALL languages and yet Opera Software doesn't see it as a vulnerability.
I think this thread makes it clear we see the problem, in any browser BTW,
but not the solution for this issue.
At the end of the day, spoofing, in one way or another, will still be
possible to trick those who don't pay close attention to appearances as
well as to logic. I'm afraid that some people will continue to click links
to sensitive sites in spoofed mail messages, which is the most logical
attack vector.
--
The Web is a procrastination apparatus: | Rijk van Geijtenbeek
It can absorb as much time as | Documentation & QA
is required to ensure that you | Opera Software ASA
won't get any real work done. - J.Nielsen
|http://my.opera.com/Rijk/journal
Brian L Johnson
> On Wed, 26 Jan 2005 08:00:48 -0000, Brian L Johnson wrote:
>
>> What I DO object to is the fact that a URL can be completely spoofed
>> for ALL languages and yet Opera Software doesn't see it as a
>> vulnerability.
>
> I think this thread makes it clear we see the problem, in any browser
> BTW, but not the solution for this issue.
Ah, but IE doesn't suffer from this problem, does it? ;)
> At the end of the day, spoofing, in one way or another, will still be
> possible to trick those who don't pay close attention to appearances as
> well as to logic. I'm afraid that some people will continue to click
> links to sensitive sites in spoofed mail messages, which is the most
> logical attack vector.
Have you taken the phishing test at
http://survey.mailfrontier.com/survey/quiztest.html ? I didn't get a
perfect 10/10 but at least I was on the safe side. <g>
But, regardless of your score, more importantly what we're talking about
here implies that you can't trust any link that you click on -- anywhere.
I mean, you have to click on that link to take you to that quiz, don't
you? Why should we now trust links like that? They could be pointing
anywhere, couldn't they? Fancy a zero-day exploit rammed into your
browser?
Or are we expected to memorize URLs and laboriously type them ourselves
into the URL bar? "aitch tee tee pee colon slash slash ess you are vee ee
why dot em ay eye ell eff... " I think not.
Rather, I think I'm going to be uninstalling all my 'internationalised'
fonts.
--
blj
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
wrote:
>Rijk van Geijtenbeek wrote:
>
>> On Wed, 26 Jan 2005 08:00:48 -0000, Brian L Johnson wrote:
>>
>>> What I DO object to is the fact that a URL can be completely spoofed
>>> for ALL languages and yet Opera Software doesn't see it as a
>>> vulnerability.
>>
>> I think this thread makes it clear we see the problem, in any browser
>> BTW, but not the solution for this issue.
>
>Ah, but IE doesn't suffer from this problem, does it? ;)
Only because MSIE does not _support_ international domain names in the first
place, unless you install a free plugin you can get from Verisign. If you
install that plugin you will have exactly the same problems as the other
clients.
This is an issue where it is not possible to use quick fixes. I would have
preferred that the IDNA standard specified a solution for the problem.
Unfortunately, it does not.
My current evaluation of the possible clientside solutions is that they are not
very practicable as they are likely to be either be full of holes, difficult to
understand for the user, or to cause severe irritation for non-English users
(e.g. Asian and most European nations).
IMO the best solution to this problem would be that the spoofers would not be
able to buy the domains at all. That requires that the registrars implement
limitations in what kind of names they will accept. The Norwegian registrar has
such limitations; the problem for the .com and some other domains is that they
are used internationally and implementing any policies are difficult.
I've been in contact with Verisign about this issue and they are aware of the
issue and are considering what, if anything, they are going to do.
Brian L Johnson
wrote:
> On Wed, 26 Jan 2005 11:31:50 -0000, "Brian L Johnson"
> <no.e...@address.invalid> wrote:
<snip>
>> Ah, but IE doesn't suffer from this problem, does it? ;)
>
> Only because MSIE does not _support_ international domain names in the
> first place, unless you install a free plugin you can get from Verisign.
> If you install that plugin you will have exactly the same problems asthe
> other clients.
Correct. Hence the winking smiley. <g>
At the moment, though, the fact that IE *doesn't* support IDNA is looking
like an advantage. ;)
> This is an issue where it is not possible to use quick fixes. I would
> have preferred that the IDNA standard specified a solution for the
> problem.
> Unfortunately, it does not.
True.
> My current evaluation of the possible clientside solutions is that they
> are not very practicable as they are likely to be either be full of
> holes, difficult to understand for the user, or to cause severe
> irritationfor non-English users (e.g. Asian and most European nations).
I can certainly see why you're reluctant to implement a solution which
could be, at best, a half-hearted one. Matthew Winn's solution
(Message-ID: <slrncveljh.5ak.o*@mwinn.powernet.co.uk>) is probably as good
as you could get.
> IMO the best solution to this problem would be that the spoofers would
> not be able to buy the domains at all. That requires that the registrars
> implement limitations in what kind of names they will accept.
Ouch! That would remove the automated nature of domain name
registration. The registrars would have to intelligently examine every
request for a domain name and vote it acceptable or not. That's a lot of
work.
> The Norwegian registrar has such limitations; the problem for the .com
> and some other domains is that they are used internationally and
> implementing any policies are difficult.
Absolutely.
> I've been in contact with Verisign about this issue and they are aware
> of the issue and are considering what, if anything, they are going to do.
Let's hope they come up with a workable solution. Soon.
--
blj
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
wrote:
>> IMO the best solution to this problem would be that the spoofers would
>> not be able to buy the domains at all. That requires that the registrars
>> implement limitations in what kind of names they will accept.
>
>Ouch! That would remove the automated nature of domain name
>registration. The registrars would have to intelligently examine every
>request for a domain name and vote it acceptable or not. That's a lot of
>work.
Not necessarily. It might be possible to have a system that refuses certain
kinds of names (of course, getting it right may be a problem, but it will be
earier to fix on the registrar side, than in a client) but leaves open the
possiblity of a manual (perhaps more expensive) registration of the ones that
are in the grey area.
In any case: I suspect that using the international domain names that can be
used for spoofing can probably be considered trademark infringement and the
arbitration system for domain names would probably hand them over to the
trademark owner in very short order. A few rounds of that, and either anti-spoof
name rules are implemented, or the corporations in question have bought all the
names.
Rijk van Geijtenbeek
> Rijk van Geijtenbeek wrote:
>
>> On Wed, 26 Jan 2005 08:00:48 -0000, Brian L Johnson wrote:
>>
>>> What I DO object to is the fact that a URL can be completely spoofed
>>> for ALL languages and yet Opera Software doesn't see it as a
>>> vulnerability.
>>
>> I think this thread makes it clear we see the problem, in any browser
>> BTW, but not the solution for this issue.
>
> Ah, but IE doesn't suffer from this problem, does it? ;)
Not yet. When it supports international addresses, it will.
>> At the end of the day, spoofing, in one way or another, will still be
>> possible to trick those who don't pay close attention to appearances as
>> well as to logic. I'm afraid that some people will continue to click
>> links to sensitive sites in spoofed mail messages, which is the most
>> logical attack vector.
>
> Have you taken the phishing test at
> http://survey.mailfrontier.com/survey/quiztest.html ? I didn't get a
> perfect 10/10 but at least I was on the safe side. <g>
I got 8 out of 10 right, and two 'nor sures'. It is a bit of guessing, and
I can't judge how difficult it would be for people who are actually
customers of those companies. I know which companies are supposed to send
me mail regularly, and I know when I've performed a transaction.
> But, regardless of your score, more importantly what we're talking about
> here implies that you can't trust any link that you click on -- anywhere.
If you start in a save place, there is really very little danger.
> I mean, you have to click on that link to take you to that quiz, don't
> you? Why should we now trust links like that? They could be pointing
> anywhere, couldn't they? Fancy a zero-day exploit rammed into your
> browser?
>
> Or are we expected to memorize URLs and laboriously type them ourselves
> into the URL bar? "aitch tee tee pee colon slash slash ess you are vee
> ee why dot em ay eye ell eff... " I think not.
>
> Rather, I think I'm going to be uninstalling all my 'internationalised'
> fonts.
Most fonts that come with Windows have at least support for cyrrilic
characters... You might not be left with much.
Brian L Johnson
>> Have you taken the phishing test at
>> http://survey.mailfrontier.com/survey/quiztest.html ? I didn't get a
>> perfect 10/10 but at least I was on the safe side. <g>
>
> I got 8 out of 10 right, and two 'nor sures'.
Same as me. <g>
>> But, regardless of your score, more importantly what we're talking
>> about here implies that you can't trust any link that you click on --
>> anywhere.
>
> If you start in a save place, there is really very little danger.
Aw, he trusts me! <blush>
--
blj
Brian L Johnson
>>> IMO the best solution to this problem would be that the spoofers would
>>> not be able to buy the domains at all. That requires that the
>>> registrars
>>> implement limitations in what kind of names they will accept.
>>
>> Ouch! That would remove the automated nature of domain name
>> registration. The registrars would have to intelligently examine every
>> request for a domain name and vote it acceptable or not. That's a lot
>> of work.
>
> Not necessarily. It might be possible to have a system that refuses
> certain kinds of names (of course, getting it right may be a problem,but
> it will be earier to fix on the registrar side, than in a client)but
> leaves open the possiblity of a manual (perhaps more expensive)
> registration of the ones that are in the grey area.
Ah, an opportunity for money! I think the registrars might go for that
one! :)
> In any case: I suspect that using the international domain names that
> can be used for spoofing can probably be considered trademark
> infringementand the arbitration system for domain names would probably
> hand them over to the
> trademark owner in very short order. A few rounds of that, and either
> anti-spoof name rules are implemented, or the corporations in question
> havebought all the names.
Trademark infringement may be a solution, yes, but the possibility of
being brought to court doesn't seem to bother the current crop of phishers
who impersonate EBay and PayPal and Amazon and Chase Manhatton and
Barclays and and...
--
blj
Matthew Winn
> At the moment, though, the fact that IE *doesn't* support IDNA is looking
> like an advantage. ;)
That makes telnet the most secure browser ever: it has never suffered
from spoofing attacks, cross-domain scripting vulnerabilities, or any
of the other assorted horrors that plague lesser browsers.
But that's not all. It supports mail and news as well, and all this
in a binary just a fraction the size of Opera.
Richard Grevers
<o*@matthewwinn.me.urk> wrote:
> On Wed, 26 Jan 2005 13:11:47 -0000, Brian L Johnson
> <no.e...@address.invalid> wrote:
>> At the moment, though, the fact that IE *doesn't* support IDNA is
>> looking
>> like an advantage. ;)
>
> That makes telnet the most secure browser ever: it has never suffered
> from spoofing attacks, cross-domain scripting vulnerabilities, or any
> of the other assorted horrors that plague lesser browsers.
>
> But that's not all. It supports mail and news as well, and all this
> in a binary just a fraction the size of Opera.
>
Nah - putty - the same stuff over a secure connection (my host won't allow
unencrypted telnet)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Richard Grevers
<ri...@operaremovethiz.com> wrote:
> On Wed, 26 Jan 2005 08:00:48 -0000, Brian L Johnson wrote:
>
>> What I DO object to is the fact that a URL can be completely spoofed
>> for ALL languages and yet Opera Software doesn't see it as a
>> vulnerability.
>
> I think this thread makes it clear we see the problem, in any browser
> BTW, but not the solution for this issue.
>
Well I favour a clear but non-intrusive solution such as changing the
background colour of the address field when a mixed-code url is
encountered (with a question mark or other icon at the right-hand end
which will pop up an explanation when clicked.)
Brian L Johnson
> Well I favour a clear but non-intrusive solution such as changing the
> background colour of the address field when a mixed-code url is
> encountered(with a question mark or other icon at the right-hand end
> which will pop up an explanation when clicked.)
Alas, that only warns against mixed-code URLs. As Peter pointed out,
http://www.opẹra.com/ is completely Vietnamese and http://www.орега.com/
is entirely legit Cyrillic.
--
blj
Richard Grevers
"Warn for internationalised domains which do not match their country" -
e.g. for any all-cyrillic domain which is outside .ru, .az, uz, ua, ga,
tm, tk etc. or for vietnamese outside .vn
So long as the warning is obvious and accessible but doesn't interrupt
workflow, that level of warning should be fine.
Brian L Johnson
> "Warn for internationalised domains which do not match their country"
I like it. <g>
--
blj
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
<newsr...@dramatic.co.nz> wrote:
>On Wed, 26 Jan 2005 19:41:42 -0000, Brian L Johnson
><no.e...@address.invalid> wrote:
>
>> Richard Grevers wrote:
>>
>>> Well I favour a clear but non-intrusive solution such as changing the
>>> background colour of the address field when a mixed-code url is
>>> encountered(with a question mark or other icon at the right-hand end
>>> which will pop up an explanation when clicked.)
>>
>> Alas, that only warns against mixed-code URLs. As Peter pointed out,
>> http://www.op?ra.com/ is completely Vietnamese and http://www.?????.com/
>> is entirely legit Cyrillic.
>>
>"Warn for internationalised domains which do not match their country" -
>e.g. for any all-cyrillic domain which is outside .ru, .az, uz, ua, ga,
>tm, tk etc. or for vietnamese outside .vn
>So long as the warning is obvious and accessible but doesn't interrupt
>workflow, that level of warning should be fine.
Sorry. Just a couple of problems: What about multiple language/multiple
characterset countries? My guess is that there will be spoof opportunities
there, too.
And what about the generic domains like .com, .net, .name etc. or domains that
have some sigificance in other countries (e.g .tv, .as (in Norway), .tm, .md) ?
The .coms may have fallen out of the sky, but the rule is still: If you want to
do business, you got to have a .com domain (at least to prevent anyone from
stealing your customers), and .name will probably as a matter of course offer
international names (if they don't already), and several other domains are being
actively marketed internationally.
Such a warning would still drive lots of people nuts unless (perhaps) it is
limited to national domains, and in that case the biggest "holes" would still be
open.
rja.ca...@excite.com
In fact, the Opera banner ads (yeah, I didn't pay yet this time) that
I've been getting lately have included one for software that analyses
network traffic - demonstrated by a hex dump in which something like
the words "ogin: root" and "ord: passw0rd" are helpfully highlighted in
red. I don't know if the software goes exactly that far, or if the ad
is still running.
I do know that the Google Groups version of alt.fan.harry-potter is
"sponsored" by Google ads about how you can get the next book for free,
which are almost certainly scamrous. And I don't know whether
www.dohthehumanity.com will see fit to include my textual description
of reading news stories about the Indian Ocean tsunami accompanied by
Google AdWords for swimwear and surfing lessons.
rja.ca...@excite.com
You don't have to implement it!
I'll still urge dividing the Internet into on the one hand Places I
Been When I Was Sober, and on the other Crazy Stuff. Probably
implemented through bookmarks. If I see a link anywhere that points to
somwehere inside www.opera.com , it'll be coloured friendly (I'm not
sure where the colour goes, maybe in background colour of the popup tip
when I point at the link) - preferably coloured as to which bookmark
folder it's in (each can have its own colour set, default is
institutional pastel green). If it's www.op...@gotcha.ha.ha.ha, it
will be coloured Crazy Stuff, and since I expect real links to Opera to
be friendly colour, it will give me pause.
But I don't have to implement it...
rja.ca...@excite.com
You don't have to implement it!
rja.ca...@excite.com
Peter Karlsson wrote:
> Brian L Johnson:
>
> > Are we saying now that because the URL is perfectly valid, it's NOT
a
> > vulnerability?
>
> No, I'm just pointing out that it is very difficult to tell what is a
> valid domain name from what is a "phishy" domain name. In a perfect
world,
> the domain registrar wouldn't allow people to register this kind of
> domain, but I am afraid that is not something we can rely on.
An analogy for this is names of racing horses. Come to think, I don't
know if I rightly understand that "international domains" have an ASCII
version (that doesn't necessarily look like anything) alongside the
"international" version, or if they stand alone. Likewise, horses
usually have an everyday name like Joey and a fantastical racing name
like, well, in a recent movie there was Seabiscuit.
The point is that racing names are intended to be unique in a central
register - like domain names - and now and again, someone tries to
register a name with a particular comic, sometimes sexual or coarse
hidden meaning. Usually the registrar stops this, but some of them get
through. I'm choosing to believe that a horse in New Zealand actually
was named Hoof Hearted. And won.
Some of them get through.
rja.ca...@excite.com
> Never mind Unicode URLs. What about www.amaz0n.com ?
Self-follow-up (anyone else still reading?), I've just seen
http://www.unicode.org/faq/security.html which indeed says, "Yeah, we
guess so, but you can do it in ASCII. Someone else should fix it, not
us."
Or words to that effect.
Andrew Brown
news:1107871839.7...@g14g2000cwa.googlegroups.com:
Well, yes. but the suggestion about scripts, if I have understood it, does
seem to offer helpful ways forward. It would allow rödakorset.se but
disallow -- or at least flag -- paypal.com with the Russian "r" which looks
like an English "p".
--
Andrew Brown
What I do: www.darwinwars.com
What I'm up to: www.thewormbook.com/helmintholog